Software Security
Security Training
Security Certification
Internet Storm Center
Cyber Security Graduate School
Security Awareness Training
ICS/SCADA
Penetration Testing
Cyber Defense Foundations
IT Audit
Computer ForensicsDetails
Affected Software: BlackEnergy C&C
Fixed in Version: Not Patched
Issue Type: Authentication Bypass and SQL Injection
Original Code: Found Here
Details
A couple of interesting bugs here. As Abe astutely pointed out, pretty much all of the PHP at the end of the code sample is vulnerable to SQL injection. Veteran Spot the Vuln readers can easily spot the tainted $_POST and $_GET parameters being passed directly into dynamically built SQL statements. This obviously results in compromise of the backend database and the application. I've highlighted the SQL injection points in the code sample below. The injection points are fairly obvious.
Now, onto the more interesting bug. In order to reach the code paths that are vulnerable to SQL injection, we must first "login" to the application. The "login" routine is contained in lines 11-25.
Later in the code, $logined is checked before allowing the user to reach the vulnerable code paths. That code can be found on lines 79-96. So let's work backwards here. We see obvious SQL injection bugs in several places, but this code paths can only be reached if the $logined variable is true (line 95). The value for the $logined variable is controlled by the following else statement:
Looking at the code above, we see that the application is taking the value for a Cookie named "logined" and assigning that value to variable $logined. The application then checks to see if $logined is equal to the password for the registered user ($logined === $pass). If $logined === $pass, then the application sets the $logined value to true. In this example, the developer missed a critical case. The client (browser) is free to tamper any part of the HTTP request, including the COOKIE values sent to the application. All we need to do is issue a HTTP request with a cookie of: logined = true; <- - any value for the logined cookie will work.
If we pass Cookie: logined = true; in our HTTP request, our tainted cookie value will be assigned to the $logined variable. You can see this in line 20 of the code sample. Although we will fail the $logined === $pass check, the application fails to clear the $logined variable value so our tainted value remains. Later in the code, $logined is checked... if it is true the application assumes we are logged in and gives us access to the vulnerable code paths. We can now exploit the SQL injection vulnerabilities and extract the real $pass value because in order for the comparison to be done, the value must have been stored in cleartext in the database.
There you go, authentication bypass + SQL injection for Blackenergy C&C :)
Post a Comment
* Indicates a required field.