This quiz is automatically created to help you get started. It will be created only once.
Just two days ago I received three different Facebook messages from three different people about a minute apart. Already intrigued at my newfound popularity I looked at them and found that each message was exactly the same: a link to an image file. The similarities of the messages continued in that they were sent from very mild acquaintances, ones who I’ve spoken to only a couple times, but who I’ve added as friends on social media just to be nice. Obviously, this was not some sort of practical joke as, for two of them, this was the very first Facebook message they’ve ever sent to me.
Fifteen minutes later they made a public post announcing to all of their friends to disregard any messages they may have sent and that they were not sent with their intention. They, we can conclude, fell unfortunate victim to hackers were most likely trying to replicate the Myspace Samy worm fiasco using an image file as the payload.
Have you ever wondered what the point was of your email not showing any image file from new senders and forcing you to whitelist every single new person that wanted to contact you? It wasn’t to save your face in the event of an unflattering or offensive picture. An image file, which logically shouldn’t hold any scripts on it, can still leak personal information into the wrong hands if one was to open it.
First off, it’s important to remember that the more content an email client loads, the wider the area of vulnerability, the more chance there is of a malicious party gaining access to your information. For example, in October of last year, Talos found a vulnerability in JPEG 2000 that allows a cyber criminal to run arbitrary code when a picture is opened. The full details are at this link but essentially when the OpenJpeg library, used by many popular PDF renderers, parses records in a JPEG 2000 file, it is possible to force it to make an array-out-of-bounds error. This error, if abused enough times, allows the attacker to execute arbitrary code on the machine, which can include shutting it down or opening files on the drive.
Apart from this, if the image file has to be downloaded, it has to be done from a web server. Because your machine makes a request to download the image file, the web server is able to see a number of things. The first is your email address, which not only confirms to the hacker its existence but that it is used frequently as well. The second is your IP address and your email client, giving the hacker your general geographic location as well as your internet service provider and workplace.
The last way, which is what the Facebook worm did to my colleagues, is simply a double extension. A person looking at a file named img34e66p3528(and so one for another twenty random characters).jpg.exe will not realise the .exe extension makes it an executable file, not an image. Clicking on the link no doubt showed some image, but it also allowed a script to take over one’s Facebook account and re-send the worm to a new batch of victims. For those curious, a friend who opened it on an iPhone showed me the image, and here’s what it looks like:
Today I’m going to be writing about one the most, if not the most, common yet dangerous vulnerabilities that hackers can take advantage of, called cross-site scripting. Cross-site scripting is similar to SQL injections in that it takes advantage of the fact that a developer wasn’t one hundred percent careful when creating their web application. Basically, it is the injection of malicious code into a website through its user input fields.
Since cross-site scripting attacks rely on the host website in order to harm its users, it can be said that there are two broad types of attacks: Persistent Scripts and Non-Persistent Scripts. Non-Persistent Scripts only run once and are usually done for test purposes to see whether or not a vulnerability exists. Persistent Scripts, however, are the ones that actually do the damage. If someone was to write a persistent script on your website’s comment section, it would be completely invisible, and it can do anything from stealing cookie information in order to gain access to a user’s account, to setting a worm in a user’s MySpace account, which would make any other MySpace user add the first as a friend, and then bring the worm over to their own account, resulting in a user gaining millions of friends overnight. The latter really happened, and the perpetrator got three years probation and a twenty thousand dollars fine. Just goes to show the importance of being careful as a security professional (or criminal).
Last week I wrote an article explaining virtual machines and containers, and the pros and cons of the two. Today I want to focus specifically on containers and container security. Because containers share resources with the host and other containers on the host, they offer security risks that are not seen with virtual machines.
Application containers run on the same kernel as their host, meaning if the kernel is accessed through the container, it will affect every other container on the host, as well as the host itself. Virtual machines do not have this problem, since every individual VM, as well as their hypervisor, all have distinct kernels from the host and each other.
Containers Docker, the most commonly used container engine, does not have users be namespaced by default, meaning a process will act the same way inside a container as its host. The problem is that a user with, for example, root privileges in a container will have those same privileges on the host, meaning a harmful process may potentially be injected into a container, and then escape into the host to compromise the machine.
Containers do offer a security benefit that is not seen on VMs, which is that they usually have a smaller vulnerability surface. What I mean by that is this: when you’re running a VM, you’re essentially working on a completely different machine with potentially a different operating system and library/binary files. And as any computer, it’s going to have fluff that isn’t always useful; code that’s just sitting there, waiting to be taken advantage of maliciously. With containers, the only dependencies that are used are the ones that are given in the container’s Dockerfile, restricting the amount of possible points of entry that a hacker can use.
All-in-all, although container technology does have its share of vulnerabilities, it’s important to remember that the cons of container security are very much outweighed by the pros of container functionality, and it’s good to know that containers seem to be progressing in a way that will help bring the IT field to its fullest potential.
In most areas of computing, the programmer will, at one point, have to test out the code they made. For small, isolated programs that only affect a specific part of a computer or OS, this can be done relatively easily without any fear. However, if a program is very large or important, or if hundreds of programs need to be tested simultaneously, risks to the host OS or machine may arise. The way one circumvents a problem like this is by setting up a new test environment for the program to run in that is isolated from the rest of the software so that no irreversible harm can come to it. There are main options for setting up a test environment.
There are main options for setting up a test environment. The first is by creating a virtual machine. A virtual machine is an isolated environment that is essentially its own operating system. Usually one would use Linux to set one up, and it will run as almost another instance of your computer. Several virtual machines can be set up using organisers, or “hypervisors”, and each instance has its own binary and library files. Only some files are allocated to the process, allowing the process to run independently from the rest of the system.
The problem with virtual machines, however, is that each instance takes up a lot of resources, more than is usually needed for the task. Code tested in one virtual machine may also not always translate perfectly into another OS. That is why the most popular form of isolated environments is called a container. Containers don’t require their own OS, several containers will run on the same engine. This way, they still give all the perks of an isolated environment, without the resource load, making them perfect for running hundreds or thousands of programs simultaneously. The most popular form of containers right now is the Docker engine, which runs on Linux systems. If you ever need to create a space where you need to test a piece of software that may be volatile or you think may contain a virus, it’s always good to set up a docker container so that nothing becomes compromised.
A good security professional has a list of tools that they know they can always rely on and a list of strategies they know they can always follow. A good security professional also knows the common things to look for when tasked with ensuring that a computer or web app is secure. They can either spend years compiling data and common mistakes from trial-and-error experiences, or they can use a premade list, like DISA STIG.
The DISA STIG viewer (Defence Information Systems Agency Security Technical Implementation Guide) is a list of security vulnerabilities created by the US government agency DISA to help combat security threats. You can download the viewer hereand the correct STIG’s for your operating system here. You can use it to follow along with me, or just look at my screenshots.
First off, open the viewer.
Not much to see right now, first, we have to load the STIG by clicking File and Import STIG.
Now your viewer will look something like this:
This page isn’t actually all that useful to us, so go ahead and click Checklist and then Create Checklist – Selected STIG
This may look a little daunting, but it’s actually really simple. Down the middle is the full list of every common vulnerability for the operating system you chose. They can be divided by how dangerous they are by clicking the CAT I, CAT II, CAT III tabs. CAT I is the most dangerous, CAT III the least. All you have to do is select an item, click the Check Content tab on the right side, and follow the instructions. If it turns out to be a “finding” also known as a vulnerability, click the “Open” radio button on the right side, next to Status, and write down some information in the Finding Details and Comments sections if you want. Now just go through each one (or download a program to do it for you), and start tackling each “Open” finding one by one.
And that’s about it, click around to find out some more administrative/bureaucratic stuff, and when you’re finished with the list, save or export it.
Over the past couple of months, I’ve gone through every tool Burp Suite has to offer. Well, almost. After teaching you how to use the Spider, the Intruder, and all the rest, there are only two more tools left. They’re both quite simple, so I’ll just squish both into one post.
Burp Decoder works a little bit like Google Translate. It’s a very simple tool that you can use to encode and decode different types of data. It is different, however, from another set of terms security professionals use, which is decryption and encryption.
Encoding data involves turning one commonly used type of data into another commonly used type of data. There are standards which are available to anyone. It’s essentially translating between languages. Dictionaries are available anywhere, and if I wanted to ask my Polish neighbour “How’s it going?” in Polish, I would tell them the same thing as if I booked a flight to Poland and asked someone there. Encoding has a practical use, but not a security-oriented one. If I had a USB that contained data in ASCII hexadecimal form that I needed to configure with a PC that uses binary, I could easily encode the ASCII hex into binary.
This is different from an encryption, the method of translation of which is known only to a select few. This is the point, so that only people who are allowed to see it should be able to.
So, in order to encode or decode data, simply paste the text into the Decoder. You have two options. If you know what the data is, for example, if you know that a certain part of a web application is using Base64, you can select ‘Decode’ on the right, and decode it as Base64. Burp will then create a second box with the data in our human language. The other way around, if you wanted to take a word and translate that into HTML, simply select the ‘Encode’ option and encode it as such.
Burp Comparer lets you make a comparison between two different pieces of data. Let’s say you wanted to brute-force your way into a login screen. You use Burp Intruder and two sets of data (one for the username and one for the password, for example) to repeatedly fuzz the site and see what kinds of responses you got. This is, by the way, something I also teach how to do on the site. Anyway, you got your results back, and you see that two responses have two different “status” values.
You don’t know what this means, so you right click both and send both to the Comparer. Select them, and then at the bottom right, select the “Words” option. Now you have a side-by-side view of both responses so that you can easily identify the discrepancy.
For most of the websites we use, we do so under the impression that we have some sort of amount of safety. We hope that a password protected login screen will keep the bad guys out. Unfortunately, this isn’t entirely the case. One of the many ways hackers can access your account is called “Session ID Hijacking”. Essentially, when you log into your Facebook or Ebay account, the server spits out a random combination of characters which is called your “Session ID”, the point of which is to differentiate you between other users, and the page you’re currently on from other pages. It’s the computer version of “Welcome Mr Smith, enjoy your stay.” If a hacker can get their hands on the right session ID, they would be able to bypass the entire verification process and hop straight into “Welcome Mr Smith”, and have access to all of your data with relative ease. Each session ID is supposed to be randomised so that no one could guess one. This is where Burp’s Sequencer tool comes in.
The Sequencer is used to test the overall “randomness” of a variable that an application’s server provides. Not only that, but it also runs a bunch of different tests to check how easily a variable can be guessed. This is used most commonly for session IDs because these are usually the most important things to keep random on a website, however, things like cookies may also be susceptible.
So, the first step to using the sequencer is to find the page you want to test, either through the Spider or by clicking around manually. Send a request to the page and get a response back. On a login screen, this would mean entering any username-password combo just to get an answer from the site. Right-click the response and press “Send to Sequencer”
Go to the ‘Sequencer’ tab. Don’t bother fiddling with all of the different options and menus, what you want to direct your attention to is the “Token Location within Response” section in the “Live Capture” subtab. Here is where you’ll want to select what it is that you want to test for randomness. If Burp hasn’t already found it for you in the “Cookies” or “For Field” drop-down boxes, you can manually select in by clicking “Configure”, selecting it like so and clicking “OK”.
Now click “Start Live Capture”. Burp will send request tokens to the server and document its responses. It may be a little slow, but if you aren’t in a rush wait it out until it makes twenty thousand requests so you can make a good analysis. The sequencer gives you lots of different analyses, you can look at the individual tests by clicking through the tabs, but Burp does give you an overall summary on the first page. Take note that the Sequencer only gives you the information, but it doesn’t actually tell you what to do with it.
Burp Suite is an incredibly powerful security tool, and part of what makes it that powerful is its relative simplicity. Its more powerful tools such as the Spider or Intruder are quite intuitive, and it’s filled with a load of smaller, simple tools that make a security analyst’s job much easier. These tools may be a little bit limited or one-sided in their design, but that just makes them better for the job they’re doing. Scissors are no use for cutting trees, but we don’t use them for that anyway. One of these tools is the Repeater.
The Repeater is used to manually change small bits of code in the requests you send to the web application you’re testing, without actually waiting for them to load through a browser. Say you have a login page that you’re testing for vulnerabilities. The Repeater will let you quickly make changes to the page request code, which is important if you know what you’re doing and what results you’re expecting. To use the Repeater, get Burp up and running, turn Intercept to ON, and go to the web page you want to test, let’s assume it is a login page, and simply enter any two username and password values. We are expecting you to get these wrong. The point is for Burp to intercept what the request you’re sending out looks like. And before we move on, please make sure that you’re either working with a local version of a website that won’t affect the real thing or with the conspicuous consent of the site owners, otherwise, all of this is illegal. Anyway, find the request you want in the Target tab and Site Map subtab, right click, and press ‘Send to Repeater’.
Now go to the Repeater tab and you should see two spaces, one called Request, and the other called Response. Request is what you’re editing, and Response is what the website spits out back at you. From here you can change anything you want about the request in any form, from the raw data to hexadecimal values. Just press go and you’ll see how the website would react. With premium, you can even render what the code looks like. Notice that in your browser, the website hasn’t changed. From here it’s up to you and your prior HTML knowledge to start picking at the site.
Following celebrity news is a lot like watching a bad horror movie. You’re constantly wondering why every decision they make is just so stupid. Whether we’re watching Friday the 13th or TMZ, we always end up yelling “No! Stop!” at our screens. We lift our chins up boldly and proclaim “I’d never do such a thing!”. That, or we shrug our shoulders and mumble “Can’t be helped” if something random and extraordinary happens to them. That’s pretty much what I did when a month ago a huge LinkedIn password dump led to hackers gaining access to thousands of Twitter accounts, including Mark Zuckerberg’s, not that he uses his much anyway.
What I’m saying is we think our passwords are very secure, or maybe just secure enough, until it’s too late. This particular hack happened because people tend to use the same password everywhere, or at the very least the passwords are very similar. In the case of Mark Zuckerberg, I can only imagine his LinkedIn and Twitter passwords to be Faceb00kRul3z. This is not the only way to gain access to someone’s account, however. A very common way is to get a very powerful computer to enter every possible character it can in the hopes that it’ll get a match. Burp Suite is a very powerful tool for doing this, just remember to only use it with the consent of the site owner and without malice.
The first thing you’ll want to do is load up Burp Suite (assuming you have it set up already).
Then, go to the web application you want to break into. Click around on it, or use Burp Spider until you have enough information on the site or have found the page you want to enter. As an example, I’ll use DVWA, which is a free open-source web app made specifically to have its vulnerabilities exploited.
What you want to do now is just enter anything into both fields and click login. The point right now is not to guess the password, but to show Burp what the response to your invalid input is. Now open your Burp window, open up the Target tab and the Site Map subtab, and find the page and request that your invalid login attempt is in. Right-click on the request and click ‘Send to Intruder’.
Now Burp Intruder can work with the web page. Go to the Intruder tab and the Positions subtab. You should see the request script, with bits bolded in. That’s Burp letting you know where it found a login textbox or a cookie that it thinks you can work with. Find the pieces of text that you want to fuzz and use the ‘Clear’ button on the right to clear the pieces of text you want to leave alone. Above all the code there’s a drop-down bar that asks you what attack type you want.
There are four attack types: Sniper is used when you only have one piece of code you want to break into (called a position), so it throws data at it (called a payload) one by one. Battering Ram works with several positions and inserts the same payload into them all at once. Pitchfork uses several sets of payloads where it enters the different payloads into different positions at the same time. For example, if you had two positions and two payload sets, it would enter the first payload from the first set into the first position and the first payload from the second set into the second position, then the second payload from the first set into the first position and the second payload from the second set into the second position, and so on. Cluster Bomb sets the same payload into one position while running through every payload in another, then sets the second payload into the first position while running through every payload, then the third, until it finds a match. This is what we want to use since we don’t know what usernames work with what passwords, so select that.
Now go into the Payloads subtab. The Payload Options section is where you’ll enter the payloads that you want to be used. Either enter them by hand, or copy and paste them, or if you have the premium version, load them from the Add From List drop-down box, where Burp already prepared some for you. You can change what set you’re editing in the drop-down option in the Payload Sets section. After you’ve got all of that done
After you’ve got all of that done, you’re ready to fuzz, just press Start Attack in the top right corner of the window and your login attempts will show up on the screen. A status of 302 means your login was invalid, a status of 200 means you broke in.
And that’s it, now you just wait and hope for the best. You may have noticed that most of the passwords are quite similar, which would make a malicious hacker’s job much easier. If you can, change your password to something a little more complex, you’ll save yourself a world of regret later.