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:
As our technology improves and horizons widen, so too do our everyday objects make progress. It’s an undisputable fact! How far back in human civilisation was a person able to unplug their book from a wall socket to charge their cigarette instead? Our lives are becoming more and more convenient every day.
Or are they? Are we really becoming smarter, better people from buying e-watches, e-toasters, e-thermostats? Or are we just trying to prove our progress as a species to ourselves by buying needlessly complicated gadgets? After all, everyone wants to live in The Future, and The Future can’t be The Future unless it looks like how it looked on The Jetsons. I’m not writing this to mock those who say humanity as a whole has improved, I agree with the sentiment; our quality of life now is as diamonds are to stones compared to ten, fifty, one hundred years back.
What concerns me is our, dare I say, reliance on gadgets that we think facilitate our daily lives. Things like fans that turn off at certain times and fridges that let you order food from them facilitate our lives the way crying in the ocean contributes to rising sea levels. The problem isn’t even that they make us lazy and apathetic, or distanced from how things were done before, the problem is that they can be extremely dangerous, and offer little to no functional pro to their perilous con.
About a month ago, Dyn Inc, a DNS provider for big names like Airbnb, Amazon, and Paypal, suffered and had to restart all of its servers because of a powerful denial-of-service attack. The Wall Street Journal, Twitter, and the Government of Sweden had to restart their websites, shutting them down for several hours. This attack, wherein a computer sends junk requests to a server with the intention to clog it up and prevent it from functioning, was done not by a group of highly sophisticated super-computers, but by a tonne of cameras and toasters.
Mirai, the malware responsible, infected the things that people never even thought of protecting.Owners of “Internet of things” objects such as smart fridges and webcams that connect to home routers usually don’t bother changing the default password, and often forget to install additional security patches after they first buy the device. This makes the CPU on a toaster the easiest access point to the rest of the home and beyond.
The biggest problem though is that there is no solution. Companies will almost never bother to write and install fortresses of code on things like smart watches because it reduces functionality and costs more with almost nothing to show for it. This means that “Internet of things” items will always be the weakest point of entry for hackers. Changing the default password and always updating patches will just breed smarter hackers. The only real resolution is to save oneself the hassle and not buy the things in the first place, which is also a very unlikely option.
All in all, if you take one thing away from this article, it’s to go update your DVR right now, and hope it isn’t already infected.
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.
I recently wrote a post explaining in brief about the dangers of SQL injections. I ended the post explaining how it was possible to run commands through a search bar in order to access and control a web application’s database. I decided that it would be better if I went a little more in-depth and wrote out what a typical SQL injection attack can look like against an unprotected database.
So, as I wrote in the previous post, let’s pretend that I am a proud owner of a craft supplies store, for arts-and-crafts and fun little projects to do with the kids. My craft store uses PHP and MySQL to access its database of items. In my previous post, I explained the basic way SQL injections are run. Essentially, adding a comment in the right place will allow a hacker to secretly hide commands for PHP to carry out. If you aren’t sure how it works, the basics are all there.
I gave an example of a command to make the database wait a certain amount of seconds before giving a response, which sounds pretty useless. Why waste time making your own hacking process slower? The reason behind it is there is a valid form of SQL injection called a “blind injection”, where one would use SQL injection commands without expecting to get any visible output. What I mean is, for example, to test what kind of RDBMS (relational database management system) software the web app uses. MySQL has a sleep function called SLEEP(), another software may use something like waitForDelay(). By testing out the different functions between different software, a hacker can get a better understanding of what they’re dealing with. Another thing someone could do would be to ask to receive data from a table that they aren’t sure exists, along with a delay. If there is a delay but no output, the hacker will know that the table exists, but the output is hidden somehow.
Let’s say a hacker has happened on my website and wants to steal the passwords that I have stored on it. They can show those passwords by what is called a union. A union is the sandwiching of two tables one under the other, provided they have the same number of columns. The hacker assumes when they type in to search for “popsicle sticks” that the table outputted has three columns, one for the name, price, and quantity of the item. They can test this hypothesis by entering the SQL query
SELECT ? FROM ? WHERE ? LIKE ‘%popsicle stick%‘ UNION (SELECT 1,2,3 FROM dual);— %’;
where the UNION function should output the numbers 1, 2, and 3 as separate columns from the “dual” table. The “dual” table is a blank hypothetical table used for testing in MySQL, which the hacker knows is the software used thanks to the previous injection.
If the result is the numbers 1, 2, and 3 printed out successfully at the bottom of the table, the hacker’s in business. They now know that they can output data to the table, which is world-endingly bad for the creator of the website (me). MySQL has an information schema called information_schema.tables that contains information about the different tables in the program. The hacker can access this by making the SQL query
SELECT ? FROM ? WHERE ? LIKE ‘%popsicle stick%‘ UNION (SELECT TABLE_NAME, TABLE_SCHEMA, 3 FROM information_schema.tables);— %’;
which will output the table name, what kind of table it is, and the number 3, because the number of columns has to be the same always.
The hacker will scroll through the many different table names and find a table that I created called “users”, which is where I could keep all of my different user data, maybe, we’ll see (yes, of course, don’t you worry). The hacker doesn’t want to simply union this new table onto the current one because there may be a different number of columns than 3. They would instead write an SQL query of something like this
SELECT ? FROM ? WHERE ? LIKE ‘%popsicle stick%‘ UNION (SELECT COLUMN_NAME, 2, 3 FROM information_schema.columns WHERE TABLE_NAME = ‘users’);— %’;
which will output the different column names from that table.
From the columns, the hacker will find a column named “userPasswords”, which they can output with an SQL query, and then dump onto the internet.
This was just one way in which a hacker can use SQL injections to gain access to personal information on unprotected sites. It’s quite a bit like cracking a puzzle, and just like doing puzzles, along with most other intellectual things, a robot can most likely do it better. This is why, as a side note, always remember to have some sort of spam protection, so that your website isn’t bombarded with thousands of SQL hack attempts.
A while back, I made a post talking about a Linkedin password dump that let hackers gain access to Mark Zuckerberg’s twitter account. We don’t know how it is that hackers got their hands on the millions of Linkedin passwords, but it got me thinking of a certain type of attack that is much more common than it should be, and one that you should take care of avoiding if you run a web application. This attack is commonly known as an SQL injection (often pronounced “sequel injection”), and it uses something as harmless as your search bar to access the web application’s database.
SQL stands for Structured Query Language and is essentially how most programs talk to databases. It was developed in the prehistoric era of web-computing of 1974 and is actually very good at its job despite its age. It’s a very simple language to use and works very well with different other languages, such as PHP. PHP is an incredibly powerful and intuitive programming language, but unfortunately not the safest. It is one of the most widely used programming languages for web application, with Facebook, Yahoo, and Wikipedia all being at one point coded in it, however, it does not come with any built-in security, and hackers can easily access web applications that are badly built to get information you definitely would not want them to have.
Here’s how it works. A typical SQL query looks something like this:
SELECT ? FROM ? WHERE ? LIKE ‘QUERY‘;
Let me explain what it is I just typed out. Let’s pretend that I own a badly made online store for craft supplies. If I wanted to see the store’s selection of popsicle sticks, I would use its search bar to search for popsicle sticks, and it would give me a result of the name of the item (popsicle stick), the price of the item (12.99$), and the quantity of the item (500). I type in the search query that PHP sends to the site’s database as an SQL query where it selects and item (I don’t know what, hence the question mark) from a table, (again, don’t know what table this will be) where the column (another mystery) is like my query. Hence, I get a result. I can also type in a term like “opsicle stic” to get the result I want which means that there are wildcards on the side making the SQL query look something like this:
SELECT ? FROM ? WHERE ? LIKE ‘%POPSICLE STICK%‘;
As a hacker who doesn’t have access to the back-end code, I can only manipulate what’s in the quotation marks. So, what would happen if I entered just a quotation mark as my search query? If the website isn’t coded against it, the SQL query will look something like this:
SELECT ? FROM ? WHERE ? LIKE ‘%‘%’;
The program assumes the quotation we entered as the query is the ending quotation of the query, and doesn’t know what to do with the last three symbols. This will return an error, even though a product in a craft supplies shop can have a quotation mark in its name, for example, if it was named something like Burt’s Pipe Cleaners. Here’s how a hacker can abuse it. If you add a semicolon, and then a comment sign (two dashes in MySQL, for example) to indicate a comment in the query, it becomes:
SELECT ? FROM ? WHERE ? LIKE ‘%‘;— %’;
Which will ask the database for simply a wildcard, meaning everything. A hacker now can input commands into PHP by using this trick (which, again, can be prevented relatively easily) to access sensitive info. Here’s an example, let’s say the hacker wanted to have a timer on the response a website gives out. If they were trying to access a site that they know uses MySQL, for example, they can make a query of
popsicle stick’ AND 1 = SLEEP(2);–
to make an SQL query of
SELECT ? FROM ? WHERE ? LIKE ‘%popsicle stick%‘AND 1 = SLEEP(2);— %’;
which will make the server wait two seconds for every query found.
Hopefully, this helped you understand just how easy an SQL injection really can be. Just remember that hackers don’t usually go after big targets, it’s much easier to catch a smaller fish that doesn’t care about it’s web app security as much, which could be you.
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.