I got a Facebook mail from a friend today titled “Look at this!” with a link to fbstarter.com.
The site itself, looks just like FaceBook (even the code view and CSS – screenshot here) – but the site itself didn’t seem to offer much except for a login. I put in dummy information and was redirected to the real Facebook site with this message:
screenshot here.
It’s good to know that Facebook is already on top of it.
When I asked my friend how he came to find / be infected with the exploit (my initial that was a rogue app) he replied: “Link from a friend on Facebook.” My guess is that the site logs in as you and send a message to all your friends to infect more people (he told me he looked through his sent mail and apparently it’s been sending emails out 15-16 at a time).
What’s interesting about this exploit is that there really isn’t any XSS or CSRF involved – Facebook didn’t do anything wrong – it’s just plain social engineering, a site dresses itself up to look like Facebook and asks you to log-in.
I went ahead and archived the fbstarter.com site as I’m sure it’ll be taken down soon:
http://insecureweb.com/files/fbstarter/ (doesn’t include images)
If you are infected – change all your passwords immediately. Although it’s unlikely the perpetrators can access your other sites many people use the same passwords or deviations of the same password for many sites. It would be in your best interest to change all your passwords regardless whether they’re the same or not (at the very least a clear conscious).
In addition, consider upgrading to Firefox 3 if you haven’t, which attempts to block web forgery attempts (after they are reported – see what happens when I try to visit fbaction.net a similar forgery site).
A whois on the owner of the domain shows our friends in Russia as usual:
Ad / Name Boris Soroka
Adres Stavropolskaya str. d.18 kv.164 Moscow Moscow 109386
Tel +7.4957851102
Faks
E-posta vy@seostudio.at
Guncelleme / Updated
Mauvis Ledford Social Engineering exploits, facebook, Social Engineering
Update 05-27-2009: A web developer at AOL is investigating these issues and in the meantime this post has been temporary disabled. It’ll return for educational purposes when the issues are resolved.
Mauvis Ledford JavaScript, Web Security
At work, a client recently contacted us about some random ads that were popping up on their site - interestingly enough through Adobe Acrobat. While I’m on a mac and didn’t experience the popups firsthand, I did pinpoint the problem to come from a hidden iframe located on the page (The client is a news organization and the iframes were being added to the bottom of each news article – so either they suffered an SQL injection or the attacker got into their platform somehow.) It turns out the code was doing something more malicious then just displaying ads. Read more…
Mauvis Ledford JavaScript, Web Security Adobe, JavaScript
In the previous post, Bryan showed you how to prevent a JSON payload to be rendered across domains by simply adding a string of text at the beginning of the payload that either 1) invalidates it (script tags are only allowed to pull in valid JavaScript before they do anything) or 2) creates an infinite loop so the rest of your script never executes.
More issues
While this is a good way to effectively protect an attacker from pulling information they’re not supposed to access, what about pushing information or executing commands via POST / *GET? In this case it doesn’t really matter if the attacker can access the HTTP response or not – the attackers request has already executed and the response (success or failure) is relatively unimportant. Any potential damage has already been done. Read more…
Mauvis Ledford Web Security JavaScript, web application security
Ajax requests suffer from the same Cross Site Request Forgery attack vectors as normal pages. Many developers assume that a given ajax request will only take place on their site, and therefor skip out on the security. Not true.
Google found out the hard way when security researcher Jeremiah Grossman uncovered a flaw in the way Gmail implemented its contact list ajax requests. When the browser loaded Gmail, it would make a request to Gmail and load a users contacts, among other things. Gmail returned the contacts as an array of JavaScript objects. Read more…
Bryan Migliorisi JavaScript, Web Security JavaScript, LinkedIn
HyperText Transfer Protocol, or HTTP, is the protocol of the web. It is what transports data from client to server and back. The HTTP specification defines several HTTP methods for transferring different types of data. Most of the methods defined are used for proxys and specialty applications. HTTP GET and POST are the two major methods in use on the web today. Read more…
Bryan Migliorisi Web Security
When writing a web application, many times developers will focus more on features and usability than anything else Security is often an afterthought. Usually, security is only a concern once a vulnerability has been not only discovered, but exploited. As developers, designers and software architects, we must ensure that the security of our application is rock solid straight from conception. This is often easier said than done. Read more…
Bryan Migliorisi Web Security introduction, web application security