[转]sqli雅虎

原文地址：http://www.sec-down.com/wordpress/?p=494
Today I will blog about a SQL Injection vulnerability that were escalated to Remote Code Execution, Escalated to Root Privilege on one of Yahoo servers.

The story started while searching in below domain: http://innovationjockeys.yahoo.net/

while intercepting the POST requests, I found below request that graped my attention with the possibility of SQL Injection.

http://innovationjockeys.yahoo.net/tictac_chk_req.php
POST:
f_id=9631

I started some manual checks and it seems a SQL Injection is flying over there!
Shooting it with SQLMap, I got below POC as a confirmation of a Vulnerability!

http://innovationjockeys.yahoo.net/tictac_chk_req.php
POST:
f_id=-9631′ OR (2777=2777)#

Available Databases:
[*] information_schema
[*] innovation******* #Hiding dbnames for Yahoo privacy.
[*] web****

Good, now I’ve a SQL Injection and I can read data as well,

Now, How about finding the admin panel, extracting the administrator Username and Password, login to the administrator panel, trying to find a RCE!

1- Admin panel found on: http://innovationjockeys.yahoo.net/admin/

2- I found the Administrator Password stored in the database and it was encoded as Base64 :D
[img]http://dl2.iteye.com/upload/attachment/0101/6304/52ef8c23-892c-313e-a11c-92fa94b86100.png[/img]
Good, I’ve decoded the Administrator Password, Logged in to the Admin panel.

Now the next step is to find a place to upload files so I can trigger a Remote Code Execution!

That said, I’ve found a upload page, but after uploading a file with “phpinfo();” function as a content,
I found that my uploaded file was named as: page_d03b042780c5071521366edc01[b][color=blue]e52d3d.xrds+xml[/color][/b]

instead of being page_d03b042780c5071521366edc01e52d3d.php ?!

[img]http://dl2.iteye.com/upload/attachment/0101/6309/8b71b62d-2454-3adf-a2f3-a2b3863275aa.png[/img]

hmmmm, I then tried to intercept the uploading request to find out the problem, and I found below info:

Screenshot from 2014-09-05 05:59:33Yea, now the reason is clear! it’s due to the “Content-Type” Header!

I tried the same request again, but this time I’ve alternatively renamed the [color=blue][b]“Content-Type” Header to be “application/php”[/b][/color] instead, and Here we Go :D

[img]http://dl2.iteye.com/upload/attachment/0101/6307/b56a4fa3-ac20-363d-a0b3-3c27a3c7b179.png[/img]

Now I’ve triggered the SQLI and the RCE, the last part remains is the Root access on the server,

However, the server kernel were latest updated on 2012! and I had the opportunity to root it with a Local root exploit vulnerability in that non-patched kernel!