During a black-box penetration test we encountered a Java web application which presented us with a login screen. Even though we managed to bypass the authentication mechanism, there was not much we could do. The attack surface was still pretty small, there were only a few things we could tamper with.
1. Identifying the entry point
In the login page I noticed a hidden POST parameter that was being sent for every login request:
<input type="hidden" name="com.ibm.faces.PARAM" value="rO0..." />
The famous Base64 rO0 (ac ed in HEX) confirmed us that we were dealing with a Base64 encoded Java serialized object. The Java object was actually an unencrypted JSF ViewState. Since deserialization vulnerabilities are notorious for their trickiness, I started messing with it.
There are a good number of situations when we find ourselves abusing the LLMNR and NBT-NS protocols on an infrastructure penetration test, more specifically on an Active Directory setup. These 2 protocols are enabled by default on most of the Windows operating systems. What are they doing is they facilitate the communication between network machines when searching for a DNS hostname regardless if it’s a share, a server or a web hostname.
The overview picture of the attack vector:
- the victim is looking for a non-existing hostname
- the DNS server cannot resolve the request
- we reply and resolve the hostname resolution query
- we ask the victim for authentication
In a recent penetration testing project we encountered a situation where in order to prove exploitability and possible damage we had to exfiltrate data from an isolated server using an OS command injection time based attack.
The scope of the project was an API. During the testing process we identified an interesting GET request that received 2 parameters: the first a string and the other one ID number.
By fuzzing the string parameter, at first, it looked like we had a potential SQL injection, based on the way it handled single quotes. Trying this attack vector didn’t seem successful, but when we sent the ` sleep 10` command and the HTTP response returned 10 seconds later, we knew we had something. Our first thought was that this was game over for the application, we managed to get a Remote Code Execution on the API server.
JSONP injection is a lesser known but quite widespread and dangerous vulnerability and it surfaced in the last years due to the high rate of adoption of JSON, web APIs and the urging need for cross-domain communications.
What is JSONP?
Assuming everybody knows what JSON is, let’s talk a little about JSONP. JSONP comes from JSON with Padding and it was created in order to bypass common restrictions such as Same-origin Policy which is enforced for XMLHttpRequest (AJAX requests).
Let’s take an example. Our online banking application, http://verysecurebank.ro, has implemented an API call that returns the current user’s transactions.
An HTTP request to the http://verysecurebank.ro/getAccountTransactions endpoint presents us with the transactions, JSON formatted:
If our reports application, accessible at http://reports.verysecurebank.ro wants to get the transaction details, an AJAX call to the page won’t be possible, due to Same-origin Policy being in effect (different host).
Note: even if it might be obvious, it’s worth mentioning that when including a script cross-domain, it will run in the context of the including application, not in the source’s context.
Adding a callback to the API response, wrapped around the JSON formatted data, allows us to load the API response between script tags and get its content by defining our own callback function to handle it.
There are various cases when during an IT/ security assurance projects there are specific requirements to rely on penetration testing projects/ reports completed by a third party.
However, not always, the IT security auditors have the necessary information to assess the quality of the penetration testing projects (focusing on planning, projects delivery and reporting).
And I address here the IT security assurance projects having in scope IT systems and finalizing with an Independent Auditor Report (IT Audit Opinion) and not audits focused on processes (like ISO audits) or on specific IT controls relevant for specific objectives (like ISAE 3402 IT/ Security assurance projects).
IT/ Security auditing standards
In order to have a consistent and objective assessment of third party reports, an IT security auditor must refer to the auditing standards he is using for performing his engagement.
And if we consider the IT audit standards available on the market, we must look at ISACA framework. There are also other standards applicable to various industries or specific objectives, focused on management systems, like ISO standards, but ISACA’s are the only ones of general nature which can be used cross-platforms, industries, etc. And as support for this, I performed some quick Internet searches and found mostly the same views.
For example, in one of its papers, NIST recognizes the entities enumerated below as addressing the IT auditing within their standards, further states that all of them taken essentially the same position concerning audits involving information systems and continues focusing on ISACA’s CobIT.
- The American Institute of Certified Public Accountants (AICPA) in several Statements on Auditing Standards (SASs);
- Institute of Internal Auditors Association (IIA) in its Standards for the Professional Practice of Internal Auditing;
- Information Systems Audit and Control Association (ISACA) in its “ITAF™: A Professional Practices Framework for IS Audit/Assurance”
- S. General Accounting Office (GAO) in its Government Auditing Standards and Title 2, Accounting.