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 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 JavaScript, Web Security
A recent PDF exploit has been running wild across the internet for the past few days. Not unlike many other Adobe Acrobat exploits, this one relies on the fact that Acrobat and Acrobat Reader ship with JavaScript enabled by default. Shame on you, Adobe.
What is interesting about this exploit is that you do not even need to open the PDF, simply viewing a file listing in Windows Explorer causes the exploit to execute. Thankfully, there is a simple fix – disable Adobe Acrobat’s JavaScript engine.
To disable JavaScript, Open Acrobat Reader and click on the Edit menu and select Preferences. In the Preferences window, select JavaScript from the left side and uncheck “Enable Acrobat JavaScript” Press OK and you’re done.
For those of you who are administrating a Windows domain network, it might be more difficult for you to do this on each and every PC. Instead, make your lives easier by using a Group Policy Object to push a registry change out to all your machines.
I have created a registry file that will disable JavaScript on Acrobat Reader. Since I don’t know which versions are installed on each of the machines in the domain, I played it safe by adding the reg keys for the 4 latest version of Acrobat Reader – 6.x, 7.x, 8.x and 9.x.
Download the registry file here
Bryan Migliorisi JavaScript Adobe, JavaScript
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 JavaScript, Web Security Adobe, JavaScript
Poor, or non existent, password policies are leaving too many people open to attack. In fact, there are many companies and websites who continue to require weak and insecure passwords. Yes, they require them.
I know that my bank does this. So does American Express and ING Direct. Try to enter a password with special 
characters. They wont let you. Try to enter a password more than 8 characters. They don’t allow it. It is frightening, to say the least. My financial data – my money – is only secured by a combination of letters and numbers up to 8 characters long.
My typical password is at least 10 characters long and is always a combination of lower case, upper case, numbers, and at least 2 special characters. I have been forced in many cases to use a much simpler password.
Combine that with the fact that most people use easily guessable passwords, such as their Read more…
Bryan Migliorisi Passwords Passwords, web application security
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