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.
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 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
Securus Global is looking to expand its technical delivery team, so that as we grow, we can continue to deliver top-quality security assessments to our clients.
- Location: Sydney or Melbourne CBD
- Salary: Dependent upon experience.
- Work Type: Full Time
The Penetration Tester is a hands-on technical role, primarily involving:
- Performing penetration testing (web apps, networks, mobile apps, code reviews, you name it)
- Reviewing other technical deliverables, such as penetration testing work and client reports
- Presenting technical work to clients and be able to explain various security issues and why they’re important to both technical and non-technical audiences
- Contributing to the development of internal tools and methodologies
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.