Tuesday, March 28, 2017

Monday tech: Stored procedures and functions SQL Injection, Oracle code execution and mitigation

Hi everyone
Sometimes you do a penetration test of a 2-tier application – a fat\thick client application.
A 2-tier thick client application is an app that connects directly to the database, without any server side code that implements business logic and proxies requests to the DB.
Any 2-tier application is a fat\thick client app, not every fat\thick client app is a 2-tier app, as thick client apps can connect to a regular server (using web services for example).

In 2-tier apps, all of the business logic is implemented in the DB level, including access control (authentication, authorization) and stored procedures\functions inside the DB.
This stored code is written in SQL and can be executed inside a select statement (function) or with an execute command (procedure).
In SQL Server this is called Transact-SQL, and Oracle DB this is called PL\SQL.

Then you execute a penetration test and test a 2-tier app, you test permissions, unauthorized data access and data manipulation and other authorization-based vulnerabilities.
What can you possible test with SQL Injection when you already have direct DB access with your own hardened DB user that enables you to execute only certain select and other SQL statements?

Apparently, stored SQL procedures\functions can create and execute dynamic SQL statements with string manipulation and as a result, can also be vulnerable to SQL Injection.
In Oracle DB you use an Execute Immediate command, and in Microsoft SQL Server you simply use exec, execute or sp_executesql with a string.
For example:

Execute immediate 'select * from table';

EXECUTE sp_executesql ‘select * from table’;

Exec ‘select * from table’;

Execute ‘select * from table’;

If you concatenate strings that arrives from the outside as a parameter, you get an stored procedure\function SQL injection:

Oracle Function: (procedures also present)
Function func(param as varchar2) returns varchar2
     Execute immediate 'select * from table where column =''' || param || '''';

MS SQL procedure: (functions also present)
CREATE PROCEDURE proc @Param Varchar(500)

     exec 'select * from table where column =''' + Param + '''';

This can be exploited by calling the vulnerable function\procedure with a payload inside the parameter:

Select * from dual where 0 >= (select count(my.func('aaa''; execute system.cool_func(''cool_param'')--')) from dual)--

Execute proc ‘aaa’’; exec master..xp_cmdshell ‘’ping’’--‘;--

So why is this helpful for 2-tier apps? You can execute any SQL within your sandboxed hardend SQL connection anyway, why would you want to execute SQL inside a stored procedure or function?
Elevation of privileges – that’s why.

Some functions and procedures can elevate their privileges in order to execute code that requires elevated or even admin permissions.
In MS SQL there is a command that is called execute as that allows you to change the current code section’s permissions, and elevate the permissions if needed.

This is how a vulnerable SQL Injection stored procedure with elevated privileges (the famous SA user) looks like:
Package my


Procedure func(param as varchar2) returns varchar2



     Execute as 'sa';

     Exec ('select * from table where column =''' + param + '''');




In oracle there is also an option to inherit (or revoke) privileges from the procedure package’s owner, that can be a high-privileges user publishing a procedure to low privileged users.

Privilege elevation in stored procedures\functions is not a vulnerability, but if it is not necessary it should be treated as a vulnerability,  and when stored functions\procedures SQL Injection is involved, it becomes critical.

But this is not the only exploitation of stored code SQLi, the is another (theoretical) usage of stored functions SQL injection which is Remode Code execution.

In most DBs if you try to end the current (usually SELECT SQL command) with a semicolon in order to start a new command, for example to modify (UPDATE) or delete information, you will be stopped at the DB connection driver level. If you try this for example in Oracle DB:
http://www.hackedsite.com/page.aspx?paramter=’ or 1=1--;update sensitive table set value=’malicious value’--
This will generate an “illegal character” error in the Oracle driver itself. The driver does not allow Oracle DB to receive more than one command at a time, and will stop any attempt to end the current command and start a new one.

So how can you still end the current command and start a new command in Oracle DB in order to – for example – execute an Update or Delete operation?
You need to find a SQL injection in an Oracle stored function that uses dynamic SQL building (“EXECUTE IMMEDIATE’), trigger this function in your SQL injection, and then perform a second SQL injection to this function. Why will this be helpful? Because dynamic SQL building in stored functions does allow execution of multiple commands with semicolons.

So all you really have to do is to find a vulnerable function that builds dynamic SQL with string concatenation, for example a function that looks like this:
Function func(param as varchar2) returns varchar2
     Execute immediate 'select * from table where column =
''' || param || '''';

Mind that you specifically need a function, because a function can be activated within different parts of an SQL statement, unlike stored procedure that needs to be activated with a dedicate “execute” command.

So how would a successful double SQL injection RCE attack would look like? Here is an example:

http://www.hackedsite.com/page.aspx?paramter=’ or 1=func(‘aaa’’; update sensitive table set value=’’malicious value’’--‘)--
Note that in the first SQL injection we activate the func vulnerable function, and then we send a second SQL injection payload that contains a semicolon character, and enables us to end the current SQL command in the stored function, and start a new command – in this case an example of an update command the compromises the integrity of the information, not only the confidentiality as in a regular SQL Injection attack.

So, in conclusion: In order to find Oracle double SQL Injection RCE exploits you need to search for stored functions that builds dynamic SQL in a non-secured manner (you can search all_source system table that contains all the stored functions and procedures code), and then trigger this function in order to execute a second SQL Injection and gain a RCE capabilities.
It is important to notice that this technique is mostly theoretical and I have never encountered such a real case in the wild, because SQL Injection is becoming less and less common, and because finding this kind of double SQL Injection is hard and time consuming, and in SQL Injection in penetration tests, you’ll probably pull out some sensitive information as a PoC and just stop there, without ever testing for RCE capabilities.

If you do encounter SQL Injection in Oracle DB, it will be very cool if you can test it for RCE.

Saturday, March 25, 2017

Cyber Updates - 25/03

Hey all,
Here are this week's cyber updates:

(1) For those of you who haven’t noticed, last week WikiLeaks has disclosed several exploits allegedly used by the CIA. A thorough analysis of the exploits has revealed a vulnerability (CVE-2017-3881) in Cisco devices, allowing remote unauthenticated users to execute code on numerous Cisco devices.
While the vulnerability exists in the Cluster Management Protocol, Cisco devices in their default configuration are also vulnerable (even if no cluster configuration was set).
According to Cisco, the vulnerability exists due to the combination of two factors:
The failure to restrict the use of CMP-specific Telnet options only to internal, local communications between cluster members and instead accept and process such options over any Telnet connection to an affected device, and
The incorrect processing of malformed CMP-specific Telnet options.
To date, Cisco has yet to issue a patch, thus causing numerous Cisco devices (listening on the Telnet protocol) to remain vulnerable.
Organizations that use Cisco devices are urgently requested to block Telnet access to all Cisco devices.

Here are all the details:

(2) A hacking group, known as the “Turkish Crime Family”, have claimed to hack numerous iCloud accounts. The group has threatened Apple that they will wipe more than 200 million accounts if their ransom demand is not paid by April 7th. 
Apple has claimed that there was no evidence of their system being hacked, but couldn’t rule out that 3rd party websites were hacked and that users have reused their passwords for their Apple ID.

In any case, it is advised to change your Apple ID password as a precaution.

Here are all the details:

(3) Google Chrome has begun distrusting Symantec Extended Validation certificates after the company was caught improperly issuing EV certificates.
The EV status of Symantec CA will no longer be recognized by the Chrome browser for at least a year, until Symantec fixes its certificate issuance processes so that it can be trusted again.
Whether Google wants to make the internet safer, or wants to push clients into using their own CA, clients would definitely think twice in the near future before issuing an EV certificate from Symantec.

Here are all the details:

Stay tuned for more updates,

Dan Gurfinkel
Head of Offensive Security & Response Unit

Monday, March 20, 2017

Monday tech: Bypassing Google ReCaptcha 2.0

Hi everyone
Last week I talked about cracking regular CAPTCHAs, but the world is moving on to a more user friendly mechanisms, so this week I want to discuss Google ReCAPTCHA 2.0 bypassing.

2 and a half years ago at December 2014, Google made a (yet another) revolution, this time in the world of CAPTCHA. Till then, everyone used the deformed-letters CAPTCHAs classic method as pretty much the only common way to tell humans and bots apart. This (as well as audio-CAPTCHAs) was the only common way. Google used it in ReCAPTCHA version 1.0.

But Google knows a lot about us, our identity and surf habits, and they decided to use this information in order to create a No-CAPTCHA ReCAPTCHA risk analysis engine, which calculates multiple factors such as user behavior attributes, location, threshold, identity attributes (for signed-in Google accounts), browsing history and others, in order to decide whether to let the user continue without solving any challenge, or to show a visual or audio challenge. This ultimately uses Google.com cookies for both logged in and unauthenticated users.
This engine is risk based and therefor bots and bypass it with some degree of success. Bots can also bypass poor classic CAPTCHAs using OCR (optical character recognition), but the big question was: is Google’s ReCAPTCHA 2.0 is less secured?
As soon as Google published the new mechanism, hackers and researchers started testing it and finding multiple ways to bypass it.
For example:

This research uses both multiple tools including valid cookie creation, deep learning, reverse image search. Deep learning and artificial intelligence for solving reCAPTCHA 2.0 are algorithms that automatically identify an image’s content. There are multiple services that allows you to do it, one even ironically include Google’s own services in the Google reverse image search technique: You take the ReCAPTCHA 2.0 image and send it to Google in order to get keywords describing the image, titles from pages containing the image, higher resolution images and translation of non-English pages to English.
Recently a new similar technique was published, that uses Google voice recognition engine in order to bypass the audio CAPTCHA of ReCAPTCHA 2.0:

So the bottom line: Is ReCAPTCHA 2.0 more human friendly? Definitely. But is it more secured than regular CAPTCHA? Depending on the exact implantation, but if you compare it to ReCAPTCHA 1.0 - probably not.
But as in many cases, you need to find the balance between usability and security, and since the regular malformed characters CAPTCHAs are not usable, ReCAPTCHA 2.0 is a reasonable solution we can safely recommend. The future of bot-humans separation is rapidly moving to risk-based algorithms, and Google and also Facebook lead the way.

Google keeps learning from the new bypassing techniques that are published from time to time, and they keep improving their algorithms.
But even if Google will solve the latest ReCAPTCHA bypassing techniques, people will still want to bypass CAPTCHAs and ReCAPTCHA 2.0 specifically, and still offer payment to bypass it.
In if there is a demand, someone will fill in this demand.
Here is a ReCAPTCHA bypass service that offers 1000 CAPTCHAs bypass for as little as 1.2-3$, that has no patch. Why? Because the CAPTCHAs are actually solved by humans.
And there’s no solution for humans-based solving services.

Have a great week

Gil Cohen
gilc@comsecglobal.com | www.comsecglobal.com