Tuesday, July 25, 2006

What WAS true, is no longer

Ryan Barnett brought something really interesting to my attention about Oreilly's JavaScript: The Definitive Guide as it relates to my Black Hat talk about JavaScript Malware. Remember my demos will not use any of what we would call "vulnerabilities" or "exploits" (No Bofos). Just the clever use of native JavaScript.

In 20.1, the following text:
"For example, client-side JavaScript does not provide any way to read, write, create, delete, or list files or directories on the client computer. Since there is no File object, and no file access functions, a JavaScript program obviously cannot delete a user's data, or plant viruses on the user's system, for example."
Without resorting to exploits, this remains more or less true, but has become a sort of red herring. Since much of our confidential information (CC's, tax/medical records, email, bank info, etc) is now on a website somewhere. What difference does it really make if you can't access files on my OS? The valuable data is on a public web server where JavaScript CAN access it.
"Similarly, client-side JavaScript has no networking primitives of any type. A JavaScript program can load URLs and send HTML form data to web servers and CGI scripts, but it cannot establish a direct connection to any other hosts on the network. "
WRONG. JavaScript can easily force a web browser to establish (HTTP/HTTPS) connections to any host the client can reach. Non (HTTP/HTTPS) connections are a bit trickier and browser dependent, but well within the realm of possibility. In fact without using JavaScript someone has already demonstrated a method to do just that. Mozilla/Firefox have today have certain protections again connections may to port 22 for instance, but that can be circumvented as well. That topic is for another time.
"This means, for example, that a JavaScript program cannot use a client's machine as a attack platform from which to attempt to crack passwords on other machines. (This would be a particularly dangerous possibility if the JavaScript program has been loaded from the Internet, through a firewall, and then could attempt to break into the intranet protected by the firewall.)"
Again, no longer true, if it ever was. Last year in my Phishing with Superbait talk I demonstrated how JavaScript Malware could completely control the web browser and be used as an attack platform. What new this year is I'll be demonstrated precisely how this can be done internally through the firewall.
"But other information should not be public. This includes your email address, for example, which should not be released unless you choose to do so by sending an email message or authorizing an automated email message to be sent under your name."
Sorta still true. If you use a non web based email address, then your email address is harder to get, but not exactly impossible to find. If you are using web-mail, like most of us, then your email address is accessible.
"Similarly, your browsing history (what sites you've already visited) and the contents of your bookmarks list should remain private. Because your browsing history and bookmarks say a lot about your interests, this is information that direct marketers and others would pay good money for, so that they can more effectively target sales pitches to you."
Your bookmarks are safe (without an exploit), your browsing history, not so much.
"We don't want a JavaScript program to be able to start examining data behind our corporate firewall or to upload our passwords file to its web server, for example."
What we want is one thing, what's possible is quite another.

2 comments:

Anonymous said...

Excellent article, i enjoyed reading the PDF about XSS, a good read and in-depth analysis of the subject.

Jeremiah Grossman said...

Thank you, much appreciated.