Recent discussions we have been having with security teams has been revolving around how internal security can work better with the development function within their organisation. As organisations move towards an environment that enables fast innovation, security is having to think of more creative ways to keep up. With a few clicks DevOps can build and release multiple iterations of an application on new infrastructure a couple times a day. This means security teams have had to find a way to ensure applications are secure without compromising the speed at which improvements can be made. We have been working with these teams to help ensure that security is built into the process and SecOps and DevOps realise how much they have in common. Continue reading
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.
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 libsqlite3.dylib:
The open function is defined as: Continue reading
Update: Below is a list of people who solved the CTF. Congrats folks!
- Dixie Flatline
- Cernica Ionut
- 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 Path Traversal. 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 trick.
To bypass these restrictions and successfully achieve Remote Code Execution chaining through the aforementioned LFI vulnerability, one can use one of the built-in PHP Wrappers 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:
All is not lost and there are some other tricks out there which allows you to overcome this fix and still exploit Local File Include (LFI) vulnerabilities. For this reason, we thought it would be beneficial for the community to come up with a CTF challenge followed by a write-up on the tricks which are not entirely spread out on the Interwebs.
My friend and Securus Global co-worker Márcio challenged me to try the CTF challenge that he came up with recently. The challenge aims to present a not widely known technique used to bypass some common file upload restrictions imposed on PHP applications. Restrictions, that prevent unauthorized upload of files to the web server using web application.
Here is the link to the challenge: http://220.127.116.11
I’ll spoil the fun a little bit and tempt you to try it out: The challenge is all about cute Pandas. ☺
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 (CVE-2016-2107) 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.
In 1998 Daniel Bleichenbacher first demonstrated a practical adaptive chosen-ciphertext attack. Four years later in 2002 Serge Vaudenay presented the very first practical padding oracle attack. Since that time notable vulnerabilities belonging to this category were also discovered, e.g. CVE-2013-0169 (Lucky13) and CVE-2014-3566 (POODLE), 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 MITRE states:
“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:
- MITRE CAPEC-463 – Padding Oracle Crypto Attack
- Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1
- Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS…
- Practical Padding Oracle Attacks
- Making sure crypto stays insecure
- Padding oracles and the decline of CBC-mode cipher suites
By Norman Yue (LinkedIn)
For those of you paying attention to mailing lists early last night, you may have noticed a curious email come through, regarding a “Truly scary” SSL3.0 vulnerability about to drop – and drop it did today.
The vulnerability, known as POODLE, allows attackers to partially decipher bits of plaintext, such as session cookies, in conjunction with a man-in-the-middle attack where an attacker can modify traffic. The really scary part (imo) is on Page 3 of the whitepaper:
The expected overall effort is 256 SSL 3.0 requests per byte.
This is amazingly low, meaning that depending on the circumstances of exploitation, your typical web app session cookie can be broken in minutes. Continue reading
By Julian Berton (LinkedIn)
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). Continue reading
Following the slew of private celebrity photos leaked earlier this week, both end-users and organisations are understandably concerned. Invariably, user confidence in the security of online services, and the confidentiality of any data stored, has been shaken by such leaks.
This is especially worrying for organisations, as more and more enterprise services move onto remotely hosted cloud platforms, which are now home to the corporate crown jewels (emails, commercially sensitive information, intellectual property etc).
The same security issues that appear to have caused the recent iCloud breaches typically affect these cloud platforms. From a security perspective, using a cloud system is effectively outsourcing and therefore should be treated as diligently as any other outsourcing arrangement.
According to Apple, the recent celebrity photo compromise occurred due to a “very targeted attack on user names, passwords and security questions” – in other words, social engineering password resets. Continue reading