Monday, September 14, 2009

Distributed Brute Force Attacks Against Yahoo

Submitted by Ryan Barnett 09/14/2009

As 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.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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
Cookie: B=ffetg09557ar5&b=3&s=od; cna=zwISA2sCdzgBAS+RbUtyRRes; Y=%2e
Content-Type: application/x-www-form-urlencoded
Content-Length: 296

Notice 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 -

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) -


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/1.0
Get HTTP/1.0
Get HTTP/1.0
Get HTTP/1.0
GET!.._69_&p=weezer HTTP/1.0

The attackers used a three dimensional scanning methodology as described below -
  1. 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.
  2. 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.
  3. 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.
*Diagonal, vertical, horizontal and three dimensional brute force scanning terminology is taken from a forthcoming book by Robert "Rsnake" Hanson.

Defensive Takeaways
  1. 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.
  2. 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.
  3. Every web application must have some form of anti-automation capability in order to identify when clients are sending these requests.

Thursday, September 10, 2009

Identifying Anomalous Behavior

Submitted by Ryan Barnett 09/10/2009

A quick test for you - can you tell what is abnormal about this web application request transaction that was captured by the WASC Distributed Open Proxy Honeypots Project?
User-Agent: User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv: Gecko/2009042316 Firefox/3.0.10
Accept-Language: zh-cn
Accept: */*
Cookie: dedifa=3984320578.43783.3716814272.929907673, BIGipCookie=0000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000, ASPSESSIONIDCSCBAQDQ=KMBPKNLCKCHMOMJAOPDPEPDF, pmaCookieVer=4, phpMyAdmin=98kdlkphdefb4lr6g5q9pke4if6gh0hg, pma_fontsize=82%25, session-id=00710064d8f2a4412ad4aeff56e96a2d, 802db0210e6b5f898c3d7fb3f82e11c0=-, _WealthCity_session=BAh7BzoPc2Vzc2lvbl9pZCIlN2NiMjM4MDM1Njk5ZDRlZTllMTY
ae29, SQMSESSID=8dddae5eis8o9l2g6aul2o3ip4, JSESSIONID=678dcb81bdc1ce2e82346199c86d, SERVERID=A, CMSSESSID3aab33f1=96d98c3e54be906ecdf12195ada689a6, Compaq-HMMD=3BE1E1BD3B3B4AFED8970001A6AACE4862D267BC50C270927260D36E, _sm_au_d=1, SOrder=DatePr%2DDOWN%2D0%2D0%2D0%2D0, SRecInPage=30, ASPSESSIONIDCCRBACRC=DFEPKLMCAJDOEIPMMHNKMMCA, PHPSESSID=cf753ceefc14a51281818d11471552d4, _bz_session=BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsY
XNo%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D--1eb7a63eabc98dec0e0f418633d652fb97f5a8db, _session_id=8e87b0524f883f7c820ec6a136f7438b, SATSATSQID=goZXTx8HbQ5eBfjGevkYJ5-Lv-M8ChUHe-NfvvDycOHkc8CTM2SrJ4F_Y_IPU6Sc, ARPT=ZXJIWKS10.32.254.104CKMWW, SESSdab19e82e1f9a681ee73346d3e7a575e=fbc279a6c6c2e66cac0a6aba173bb261, vb_session=77e75d1912c7b6d796dae865fb95149a, BAIDUID=2A880F37E13E5EB37286E3EFF5BF43AA:FG=1
Proxy-Connection: Keep-Alive
Two anomalous items of interest in this request -

1) Bogus User-Agent payload
Specifically the string "User-Agent" actually appears at the beginning of the header payload. This looks like a botched script that tried to spoof the User-Agent data.

Defensive recommendation - look for this string in the User-Agent field and tag the request as an automated client that is spoofing request header data.

2) Number of diverse SessionIDs
The number of SessionID related cookies in this request is certianly larger than normal. Also note that there are SessionIDs for different web application technologies -

ASPSESSIONID - for ASP web apps
JSESSIONID - for Java web apps
PHPSESSID - for PHP web apps

What are the odds that this website is running all three of those web technologies? Pretty slim...

My take is that the scripted client is just populating bogus SessionID data for a bunch of different apps with the hopes that this would pass basic filters that force a SessionID name to exist but don't have knowledge of valid/active values. The most likely candidate is a SPAM bot that is looking to post data to blogs, forums, etc...

Defensive recommendations -

A. Count the number of SessionIDs/Cookies submitted. If it is too large, then alert as appropriate.

B. Look for SessionIDs/Cookie names that do not match your web application technology.

There are numerous other methods to identify anomalous web application activity. Security applications that are able to automatically generate web application learning and profiling (such as web application firewalls and web fraud systems) and correlate data from application users are able to identify deviations from the norm. These are complex systems that have advanced logic components to identify anomalous traffic such as that which is presented here.