Phishing, scamming and cross-site scripting (XSS) attacks were first used to steal passwords from web-based mail and banking resources.
And from the beginnings of small offences, a new generation of hackers have appeared to trick people to steal money. Launched on bigger scales each time, profits are gaining.
When analysing attacks, we can see they are not technologically mature.
Current vectors of fraud include:
- Trojan: A trojan can be installed on your computer and monitor for access to banking and payment websites, and it will then log and pass on your passwords to a third party.
- DNS: Redirection of the real domain name to an ‘evil’ IP address by hijacking dns servers utilising host redirects and cache posioning. Some major ISP’s have already been hit by this attack.
- URL/HTML tricks: These are used to hide the ‘evil’ domain in the browser. Hackers are ready and willing to pay $40 for an SSL certificate to dupe hundreds of people.
- Confidence attack: Most scams don’t even bother to imitate a real website, they rely on simple confidence tricks and ask for your credit card without any mis-direction.
Future developments would be Cross Site Scripting 2.0.
XSS 2.0?
The description of “Web 2.0″ came from the O’Reilly Web 2.0 Conference, to describe new web technologies and concepts, the founding basis being the use of Advanced Javascript and XML (AJAX).
Often pointed out, AJAX is cool in terms of functionality but will be really difficult to control.
Short summary about XSS 1.1:
XSS is a web attack targeting the client side.
The aim is to create a url which, when clicked on will merge website code from a third party with the one visited. The implications usually involve sending form information to third parties, stealing ‘cookies’ and exploiting browser vulnerabilities to install viruses and spyware.
Transmission is usually via e-mail, but more recently Instant Messenging has been used.
There are two important features of this attack. An attacker can use the genuine website, even through SSL. This attack is also platform independent, browser independent and therefore, ideal to maximise the success and exposure of an attack.
XSS 2.0
If you have ever played around with Google maps you will understand the capabilities of AJAX.
So, we were quite impressed, and at the same time nervous when we found the following AJAX script: www.robrohan.com.
Not only does it act as a keylogger, it’s also a mouse logger… and even more important, you can remotely alter the data entered on the form.
Password-only authentication hasn’t been safe for a while, with remote keylogging you can be fairly sure they’re not safe anywhere anymore. Authorisation using coordinate-click procedures can also be nullified.
And if you are use RSA SecurID card you might have another issue, the remote attacker could change the data that you entered without you seeing it. This is in effect, a remote Man in the Middle attack.
When you are browsing a “secure website” with an SSL connection, your browser currently does not tell you if it has made a second secure connection to another website. Attackers could use this behaviour to perform this man in the middle attack to control what your browser has sent to the website, and what the website sends to your browser… Scared yet?
In other applications, I guess this technology also will be used for click-through marketing purposes to track your movements on a website. Sort of like Cookies 2.0.
Here some scenarios to think about the risk involved:
- An XSS has been found in a online bank website
- A 0-day is launched and millions of people recieve spoofed phishing e-mails, but this time pointing the users’ to the real website for the bank, with the valid ssl certificate
- When logging on all their credentials are uploaded to a third party. It just so happened the bank recently implemented a new security feature. You now get one of these pictures to click on, to make sure you’re not a ‘bot’. We also upload the pictures and can replay the action on our screen
- The password prompt asks you for your 1st, 3rd and last number of your password. Realising you have made several mistakes when entering the password and we know your entire password
- Or, you’re lucky enough not to have a password, but one of these really safe RSA SecurID cards. We just changed the account number before the transfer, and you won’t even notice, as I can change the data that you just live on the real website.
Thought you were secure?
Thought SSL connection’s were good enough?
Will you be able to detect a such advanced attack ?
Get Safe Online was launched last year and pointed out security issues which were 2 years old… so, when is “Get Safe Online 2.0″ coming online?
So, how can the attack be mitigated against?
- Browser’s should not allow connections to secondary websites, even if the connections are SSL
- AJAX and JS function that possibly present a security risk should be disabled by default enabled only on demand
- Enforcement of URL checking and detection a possible XSS attack (we believe IE7 is making some headway with this, we’re yet to see the results)
- Code audits. After all, safe code is secure code. You are welcome to ask some questions to our technical team