During a previous engagement Securus Global was asked to review a desktop application that used a local SQLite3 database to store a list of blacklisted URLs. As expected the database file was encrypted and not much that could be done with the database.
). It is used heavily in our Mobile App Penetration Tests so the team decided to take a further look at the application and managed to trace the “requests” to
Keep in mind that the same approach will work for libsqlite3.so. Also note that this has not been tested in a Windows environment.
Our goal at the time was to discover the SQL queries performed by the application and try to acquire some useful information, we started to look into two specific functions in
The open function is defined as:
Update: Below is a list of people who solved the CTF. Congrats folks!
Dario D. Goddin
This post is the second part of the
Bypassing PHP Null Byte injection protections
blogpost. If you want to try the CTF first before going through the write up, head to the link first. Otherwise, keep on reading :)
The main trick described in this write-up relies on the fact that a
Local File Include
(LFI) vulnerability is exploitable but with some restrictions imposed by the code. Among these restrictions, there is some active filtering on
. Name;u, an image file extension (.png) is always appended to the successfully uploaded files. In addition, the server is running an up to date version of PHP which is not vulnerable to the well known
Null Byte Injection
To bypass these restrictions and successfully achieve Remote Code Execution chaining through the aforementioned LFI vulnerability, one can use one of the built-in
as described in detail on the next section of this write-up.
When visiting the URL of the vulnerable application one can see that it is a web app for uploading pictures:
Following the normal application flow first, I tried to understand how the application behaves and how the uploaded files are being parsed by the code with some simple tests:
So what is a UDF? It is a way to extend MySQL with a new function that works like a native (built-in) MySQL function; i.e., by using a UDF you can create native code to be executed on the server from inside MySQL. To do this you need to write a library (shared object in Linux, or DLL in Windows), put it into a system directory, then create the functions in MySQL. Usually people write UDFs using C/C++, but you can really use any language you want since you are creating a shared object. This has the advantage of being simple to write while also being highly portable. The real benefit is that you don’t need to access or modify the source code of MySQL, and after the UDF is installed you can update the DBMS without the need to make any changes to your code (i.e., it is transparent).
The very fact this article came to be implies the answer – yes, they are. Readers who are interested in knowing the rationale behind this statement are encouraged to continue reading.
The main motivation behind writing this article was a padding oracle vulnerability (
) found on May 2016 in a popular OpenSSL cryptographic toolkit. Authors of this article decided that it is a great occasion to revisit this area and to refresh information about the padding oracles.
first demonstrated a practical
adaptive chosen-ciphertext attack
. Four years later in 2002
presented the very first practical
padding oracle attack
. Since that time notable vulnerabilities belonging to this category were also discovered, e.g.
, to name the most recognized ones.
After some time, some people even started to believe that this type of attack is
no longer a problem
(i.e. no longer considered a threat in real-life). Despite this and similar opinions, we can observe that new padding oracle vulnerabilities are continuously discovered by security researchers and 14 years after the first practical attack was presented, they still pose a very real security threat.
What is padding oracle? What can happen if someone finds this vulnerability in my application and will be able to exploit it? How can I test, identify and avoid this type of attack? Let’s address these and other questions in the following sections.
First things first. Let’s refresh on what the padding oracle attack is. The definition according to
“An attacker is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext.
In addition to performing decryption, an attacker is also able to produce valid ciphertexts
(i.e., perform encryption) by using the padding oracle, all without knowing the encryption key”.
For readers who would like to refresh information about the padding oracles, please refer to the following materials:
By Julian Berton (
Recently, I presented a lightning talk at Ruxcon 2014, on a cross-site scripting issue we discovered on a client engagement, and two interesting ways in which we could bypass the WAF present (as well as Firefox’s cross-site scripting filter).
The cross-site scripting issue we found was fairly standard at first, with an initial URI like the following:
This generates a page like the screenshot below, with the reference number pulled from a vulnerable parameter in a URI, with the “jquery.query.get()” function.
By Andy Yang
(A little bit of background on this post – one of my colleagues, Norman Yue, posted something about the Internet being on fire to LinkedIn yesterday, regarding the bash bug. This blog post tries to explain a bit more about why exactly this is such a big issue, and also provides a proof-of-concept exploitation).
Firstly, the vulnerability itself. The
actual vulnerability itself
is amusing and unique, but otherwise, isn’t the magical everything-is-owned vulnerability that everyone makes it out to be. To paraphrase, if you are able to set an environment variable through the Bash shell, you can execute commands.
The interesting part is that this vulnerability may have existed for more than 20 years, in an application which is part of pretty much every Unix system since a long time ago. The vulnerable versions start from cpe:/a:gnu:bash:1.14.0 to cpe:/a:gnu:bash:4.3, which covers pretty much every Unix-based operating system available today (and by extension, a tremendous chunk of the Internet).