I was reviewing the logs over at our WASC Distributed Open Proxy Honeypot Project and I noticed some interesting traffic. It looks as though Spammers are using the Twitter API to post their messages to their fake accounts. While the news of Spammers doing this is not new, the WASC honeypots are able to take a different vantage point and correlate account data.
Here is one example Spam posting transaction:
| Request Headers |
| POST http://twitter.com/statuses/update.xml HTTP/1.1Authorization: Basic Sm9oblRNYWxtOm5rdGpjcjEyMw== X-Twitter-Client-URL: http://yusuke.homeip.net/twitter4j/en/twitter4j-2.0.8.xml Accept-Encoding: gzip User-Agent: twitter4j http://yusuke.homeip.net/twitter4j/ /2.0.8 X-Twitter-Client-Version: 2.0.8 Content-Type: application/x-www-form-urlencoded Content-Length: 161 Host: twitter.com Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Proxy-Connection: keep-alive |
| Request Body |
| status=%40ldegelund+why+not+offer+work-from-home+projects++to+your+readers+by+th \ is+terrific+service+-+http%3A%2F%2Fproj.li%2FaOGdjN+Good+Luck%21&source=Twitter4 \ J |
Notice the Authorization request header as the Twitter API requires basic authentication. The decoded user credentials are (format is username:password):
JohnTMalm:nktjcr123
Now, looking at this one transaction in isolation doesn't yield much interesting data. What is interesting, however, is that I then did a search for all transactions to Twitter's API for June 21, 2010 and I found many more transactions all from different client IP addresses. I extracted out all of the unique Authorization headers and decoded them:
JohnTMalm:nktjcr123NicholeFBethune:nktjcr123LindaCTomas:nktjcr123ElsieJJanu:nktjcr123PhyllisLMoor:nktjcr123CynthiaLMille:nktjcr123JaniceRKnudson:nktjcr123harli_lona:nktjcr123MaryCShahh:nktjcr123DorothyRFrame:nktjcr123jeffpadams:nktjcr123AmyMSiege:nktjcr123LynJLaw:nktjcr123SteveMWesle:nktjcr123
Notice anything interesting? They all have the exact same password. Since the password isn't one of the typical dictionary ones where it may be possible to have some users actually use the same password, we can only conclude that all of the accounts are controlled by the same person(s).
Recommendation for web sites
When new accounts are being created, check the new password against some form of hash tracking list to see how many users have that same password. If the password is widely used, then it can either be denied or placed on some form of fraud watch list.
If you check out the twitter pages of these fake accounts, you will see that they all have profile pictures of women (even though some of the account names seem male). This may be an attempt to try and disarm readers and entice them to click on the job/tool related links.
I checked out one of the links. The first URL shortener resolved to a second URL shortener and then onto the final site - DoNanza
$ wget http://proj.li/d62dIW--2010-06-21 14:18:45-- http://proj.li/d62dIWResolving proj.li... 74.55.224.85Connecting to proj.li|74.55.224.85|:80... connected.HTTP request sent, awaiting response... 301 Moved PermanentlyLocation: http://bit.ly/d62dIW [following]--2010-06-21 14:18:45-- http://bit.ly/d62dIWResolving bit.ly... 128.121.254.201, 128.121.254.205, 168.143.173.13, ...Connecting to bit.ly|128.121.254.201|:80... connected.HTTP request sent, awaiting response... 301 MovedLocation: https://www.donanza.com/publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb#uexox [following]--2010-06-21 14:18:45-- https://www.donanza.com/publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpbResolving www.donanza.com... 74.55.224.82Connecting to www.donanza.com|74.55.224.82|:443... connected.HTTP request sent, awaiting response... 200 OKLength: unspecified [text/html]Saving to: `publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb'[ <=> ] 11,236 --.-K/s in 0.1s2010-06-21 14:18:46 (99.4 KB/s) - `publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb' saved [11236]
It seems as though the purpose of these Spam links/accounts is to do some affiliate or click schemes.
3 comments:
Comparing salted values after the fact is impossible if you salt your hashes per record. I certainly think it's a good idea; just slightly difficult to implement.
What would you specify as a threshold for different user accounts with the same password? I know that Twitter blacklists some passwords, but do they have any complexity requirements? I think that this would cause an awful lot of false positives, especially since most of the users that are signing up for these websites are using the weakest password they can get away with based on the site's password complexity requirements, if any.
Hey Ryan, I like the idea of performing some form of analysis on the stored password hashes to determine if there are many accounts sharing the same passwords however couldn't denying the creation of the account reveal something pretty important to an attacker? Lots of other accounts use the same password. :-) I guess it all depends on how you present the error though. Interesting idea.
Post a Comment