I often talk about cross-site scripting (XSS), and that’s partly because I think it’s a pretty interesting type of vulnerability that many developers tend to overlook. It can be quite dangerous, but can also be quite misunderstood. For one thing, the name can be misleading: exploiting XSS does not always involve scripting, and the proliferation of web technologies has taken XSS issues beyond the browser.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

The big news of the week, emanating from Toorcon 12, is the release of Firesheep. This tool makes SideJacking – that is, “hijacking an engaged Web session with a remote service by intercepting and using the credentials that identified the user/victim to that specific server” – painfully simple for anybody to use. How easy? Well, let’s see… you download and install Firefox… and then you download and install the Firesheep extension to Firefox… and then you restart Firefox and run the tool to start hijacking sessions… that’s it! Simple enough for ya?

SideJacking is not a new concept, nor is the existence of tools. Robert Graham of Errata Security made a bit of a splash with his tool Hamster back at Black Hat 2007 (also see “Wi-Fi SideJacking opens eyes at BlackHat“). And, really, the concept of intercepting and hijacking sessions is even older than that. Poor session management continues to be on the OWASP Top 10 list, as does the lack of adequate transport layer protection (that is, SSL/TLS for web sites).

Read the rest of this entry »

Damn Vulnerable Web App (DVWA) has released an updated version (v1.04) of their PHP/mySQL web application that is intended to be attacked. It’s intended to be run on a local (closed) network as a learning tool for exploits and vulnerabilities. As it sits now, it pretty much contains a lot of the basics – brute force, command execution, file inclusion, SQL injection, and XSS.

Read the rest of this entry »

With Windows holding 89.6% of the global market share, it is a very large target. This is one of the reasons Windows is targeted so much by malicious attacks. Not very hard when you’re such a big target. So, what if you could change that and make your Windows machine/server appear as something else, even to the most notable of sniffing tools (Nmap, P0f, Ettercap, etc.)? Well, you can.

Read the rest of this entry »

I’m sure if you’ve been paying attention to any of the tech/geek news blogs you’ve seen the attention given to the “COMPROMISING ELECTROMAGNETIC EMANATIONS OF WIRED KEYBOARDS” article. So you already know the buzz, and are probably all running out to build Faraday cages around your offices or workstations. But there really isn’t anything terribly new or ground breaking here. It’s simply a further spin on an old trick.

Anyone who can remember back might recall a little something about “TEMPEST“. It’s the codename given to compromising emanations (CE). This research dates all the way back to 1985 when the security risks of emanations from computer monitors was analyzed.

By no means do I want to take away from the research and proof of concept that Martin Vuagnoux and Sylvain Pasini have put together. I simply want to focus on the fact that a lot of us, especially those young in the tech and security fields, are forgetting some of the roots. We’ve already pointed out some other old-school hacks that are still relevant today. So while everyone is hardening their systems for super stealth ultra-sensitive attacks against their systems, let’s not forget where we came from, and proper education of old-school attacks deserves some attention as well.

The example I used to segue into this might not be the most stellar example of outdated attacks, as with technology growing, it might even become more of a common-day attack. But the fact that this goes way back, and technology is only making it easier goes to show – things that we think are out of reach today, aren’t  far from reach in the not-so-distant future.

So what do you think? What other areas of our past or even present do you think won’t hold any grounds for security in the not-so-distant future? What old-school hacks are still present today that many might be overlooking? Let us know in the comments…