There are many options available for the knowledgeable attacker. In this video, you’ll learn about memory vulnerabilities, directory traversal, improper error handling, API attacks, and resource exhaustion.
<< Previous Video: Race Conditions Next: Rogue Access Points and Evil Twins >>
If an attacker can manipulate the memory of a device, then they can control it to do almost anything. However, finding a vulnerability and memory and being able to manipulate it in a way that gives you that advantage can be very difficult.
One type of memory vulnerability that often ends with the system crashing or the application failing is a memory leak. In a normal application, memory is allocated for storage or for calculations and when that memory is no longer in use it’s returned back to the system. With a memory leak, that memory is never returned back to the system and the application continues to use more and more and more memory until eventually it uses all of the available memory, and ultimately that crashes either the application or the operating system it’s running on.
If an attacker is looking for a way to create a denial of service to bring down a system, a memory leak would be a very good choice. When applications are using memory, they’re storing information into a section of that memory. And then when they want to reference that information again, they simply point to that area of memory. If an attacker can make an application point to a null section of memory where nothing exists rather than the part of memory where the application data might exist, that’s called a null pointer dereference. And if you’re pointing to nothing in memory, it very commonly causes the application to crash. They’ll probably be debug information on the screen and this could cause the denial of service the attacker has been hoping for.
Another way that attackers like to manipulate memory is with an overflow. An integer overflow is where a large number might be placed into a smaller section of memory, which means that that extra space has to go somewhere, and usually it goes into an area of memory that’s overflowed. Applications should not work in this way. Application developers should make sure they’re not storing information into smaller areas and causing some of that information to overflow into other parts of memory. It’s very difficult to find an integer overflow situation like this that is something that is repeatable by an attacker, but if an attacker can find an overflow that can be duplicated and it’s one that allows them to manipulate the system in a way that’s advantageous to them, this makes for a very powerful attack.
Another vulnerability that might give a way for attackers to move around your file system is a directory traversal attack. This allows attackers to read from different parts of a server, even areas of a server where normally they should not have access. Let’s look for example, in this particular drive. This is my C drive of my Windows machine, and I’m running a web server on this. This area in the lighter color are the folders that are used in that web server. People who are accessing the web server should not have access to these other folders that are on my system. Folders like the Windows operating system folder, for example.
But there are vulnerabilities that you can find. For example, in certain versions of web server that might allow people to browse outside the scope of the web server software. Or there might be vulnerabilities in the software that you’re running on that web server that would allow attackers to move outside the scope of the web server file system. And sometimes a web server misconfiguration might allow an attacker to use the two dots and a slash be able to move backwards through the file system.
So in this particular case, there’s a web server and they’re trying to access show.asp which would be in the root of this particular web server. And then they’re moving backwards through the file system twice. So they would move up to the inet pub, and then finally the root of the entire C drive. Then they’re going to access the Windows folder and view the system.ini file. By using this type of directory traversal, they were able to break out of the web server and view files that were in my Windows folder.
We all know that eventually the systems that we’re using are going to have some type of error associated with them. It might be in the operating system or the application or some other component of what’s running on that device. When that error occurs, there’s probably going to be messages on the screen. These messages might have information about the error, might have a code associated with it, and it may show a little too much information about the underlying system it’s running on.
You should make sure that your error messages are showing just enough information so that people understand what the error might be and they might be able to report that to someone else. But you want to be sure to avoid information, such as the network you’re connected to, maybe a dump of memory or stack traces or even database dumps. If you’re showing that as part of an error message, an attacker may be able to use those details to learn more about the underlying system. Fortunately, this is a relatively easy issue to fix as long as you have control of the development process for that application.
In earlier videos, we talked about the danger of invalid input going into a system and what the results might be of the data coming out. All applications we’re using will have some type of input. We may have to put in usernames or passwords or we may have to input information into a spreadsheet or a word processing document. The data that’s being input by the users is going to be evaluated and acted on by the application. So the application developers need to make sure that the data that’s being input is not malicious or trying to circumvent any security mechanisms within the system itself.
For example, having a very specific string of input into a field might allow someone access to an entire database of information. Or it might cause a denial of service and cause the application or the operating system to fail completely. It may be difficult for attackers to find these instances where this type of input might cause these issues, but as soon as they’re able to identify that in a vulnerable application they will take advantage of it.
When an attacker tries to manipulate the application programming interface of an application, that’s considered an API attack. They’re trying to manipulate that API so that they can gain additional access or gain access to data that would not normally be available to them. And in some cases, they can manipulate the API to bring down the application or the system, creating a denial of service. In a traditional application that we would run from our browser, we would have an HTTP GET command. This might be a very complex GET command that’s sent to the web server. The web server interprets that command, sends information on the back into the database that is then going to respond, and the web server will give us an HTTP response.
An API based application is usually something running from a mobile phone, for example. And instead of sending an HTTP GET, there will be many, many different application programming interface requests being sent to the server. The server is going to perform similar functions on the back end to talk to the database server, and then the responses to those API requests are going to be a series of API responses which will be interpreted by the application running on the mobile device.
A resource exhaustion is a denial of service attack that can often be done by a single device over low bandwidths. It’s a type of attack that uses up the available resources on a device so that the application or the service that’s being used by it is no longer accessible by others. Here is a historically well known resource exhaustion. It’s a zip bomb. It is a very small zip file which is a compressed file, a 42 kilobytes in size, which is very, very small. But if you were to uncompress this file, it would uncompress to a 4.5 petabyte, that’s 4,500 terabytes, file size. You can imagine unzipping this on a traditional computer. It would very quickly use all available storage space.
This is such a well-known resource exhaustion that most antivirus software will immediately identify this and prevent it from running. A network based resource exhaustion would be a DHCP starvation where an attacker is starting to flood a network with what seems to be many new devices hitting the network that will need IP address requests.
The attackers usually running from a single device, but is sending these requests with multiple Mac addresses to make it seem as if there are many, many machines on the network and it will very quickly use up all of the available IP addresses that might be inside the DHCP pool. This means that anyone else who tries to connect to this network will not receive an IP address because they have all been used by this resource exhaustion. There are configurations that can be made to switch that can limit the number of requests made for DHCP addresses and that might limit the scope or at least the time frame that somebody might have to be able to perform a DHCP starvation.