Submitted by Ryan Barnett 09/14/2009As part of the WASC Distributed Open Proxy Honeypot Project (DOPHP), we have been able to track some pretty extensive distributed brute force attacks against Yahoo end-user email accounts. Valid email accounts and/or obtaining valid account credentials are a huge commodity for SPAMMERS. Identifying valid accounts is important as it allows them to only send SPAM messages to real accounts and they can also be able to sell lists of valid accounts to other SPAMMERS. Taking this a step further, if the SPAMMERS are able to enumerate valid credentials for an account (username and password) they can then hijack the account and use it for SPAMMING.
Normal Web Login
This methodology is not new and Yahoo is obviously aware of these attacks aim at their Yahoo mail web login interface page. This login page looks like this -
When a client clicks submit, the request looks similar to the following -
POST /config/login? HTTP/1.1Notice the in the post payload that the application is tracking how many "tries" have been attempted. This is useful for throttling automated attacks and once a client goes over a limit, Yahoo then presents the user with an added CAPTCHA challenge -
Host: login.yahoo.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.yahoo.com/
Cookie: B=ffetg09557ar5&b=3&s=od; cna=zwISA2sCdzgBAS+RbUtyRRes; Y=%2e
Content-Type: application/x-www-form-urlencoded
Content-Length: 296
.tries=1&.src=&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&.partner=&.u=007ofj55asupi&.v=0&
.challenge=hKhk9.OX5y0EOqJ3c4yxAH_rSrx5&.yplus=&.emailCode=&pkg=&stepid=&.ev=&hasMsgr=0&.chkP=Y&.done=http%3A%2F%2Fmy.yahoo.com&.pd=_ver%3D0%26c%3D%26ivt%3D%26sg%3D&login=foo&passwd=bar&.save=Sign+In
Also notice that the login page is presenting the end user with a generic error message indicating that the credentials were not correct but it does not inform the user whether it was the login or password that was wrong. All of this type of anti-automation defense is good. The problem is - is Yahoo applying this type of defense consistently throughout their entire infrastructure? Are there any ways for the SPAMMERS to find a backdoor? Unfortunately, yes.
Web Services App
The WASC DOPHP has identified a large scale distributed brute force attack against what seems to be a web services authentication systems aimed at ISP or partner web applications. The authentication application is named "/config/isp_verify_user". Google links for the "isp_verify_user" app are here. One thing you will notice in looking at these results is that there is an incredibly large number of Yahoo authentication subdomains that are hosting this application and are able to authenticate clients. If you click on one of the links, you will see that the response data returned in the browser is terse. It is simply 1 line of data such as this -
ERROR:210:Required fields missing (expected l,p)
The format of this data is obviously not intended for end users, but it more tailored for parsing by web service applications. It very well could be that many front-end web applications are validating the credentials submitted by clients to these isp_verify_user app. This particular error message is returned when a client does not submit the l (login) and p (password) parameters.
If a client sends a request for a login/username that does not exist, the app will return a message of -
ERROR:102:Invalid Login
Remember the generic error message presented on the normal login web page? Not here - it is easy for a SPAMMER to automate sending requests and cycling through various login names to identify if/when they hit on a valid Yahoo account name. When this happens, the application gives a different Invalid Password error message -
ERROR:101:Invalid Password
Note that this application does not implement any of the same CAPTCHA mechanisms that the standard login page does. This means that the attackers have an unimpeded avenue of testing login credentials. If the client sends the correct credentials, they will receive a message similar to the following (where username is the data submitted in the "l" parameter) -
OK:0:username
With this information, the SPAMMERS can then log into the enumerated email account and abuse it as they wish.
Scanning Methodology
Here is small snippet of some of the transactions that were captured -
Get http://l33.login.scd.yahoo.com/config/isp_verify_user?l=kneeling@ort.rogers.com&p=qwerty HTTP/1.0The attackers used a three dimensional scanning methodology as described below -
Get http://l06.member.kr3.yahoo.com/config/isp_verify_user?l=kneading@ort.rogers.com&p=000000 HTTP/1.0
Get http://69.147.112.199/config/isp_verify_user?l=kitbags@ort.rogers.com&p=333333 HTTP/1.0
Get http://217.12.8.235/config/isp_verify_user?l=kirk@ort.rogers.com&p=yankees HTTP/1.0
GET http://69.147.112.217/config/isp_verify_user?l=__miracle&p=weezer HTTP/1.0
GET http://69.147.112.202/config/isp_verify_user?l=123#@!.._69_&p=weezer HTTP/1.0
GET http://68.142.241.129/config/isp_verify_user?l=__lance_&p=weezer HTTP/1.0
GET http://202.86.7.115/config/isp_verify_user?l=__kitty__69__&p=weezer HTTP/1.0
- Distributing the scanning traffic through multiple open proxy systems. This changes the source IP address as seen by the target web application so basic tracking/throttling is more challenging.
- Distributing the traffic across different Yahoo subdomains. The advantage to this is that even if some form of failed authentication tracking is taking place, it is more difficult to synchronize this data across all systems.
- Diagonal scanning - submitting different username/password combinations on each request. This is instead of vertical scanning which is choosing 1 username and cycling through passwords or horizontal scanning which is choosing 1 common password and cycling through userenames.
Defensive Takeaways
- Implement proper ACLs against all web services apps. In this case, the isp_verify_user app was clearly not intended for direct client usage however there are no ACLs that prevent an end user from accessing them.
- Need to identify any rogue web application authentication interfaces. This is a big problem for organizations that are either newly deploying distributed web services apps or those who have newly acquired a business partner.
- Every web application must have some form of anti-automation capability in order to identify when clients are sending these requests.
