Our applications can be the weakest links in our security armor. In this video, you’ll learn about privilege escalation, directory traversal, and more.
An injection attack is a very common way to attack an application because an attacker can easily add additional malicious code to input that is going to a server or a client device. Normally, this injection attack would be stopped by the application. But occasionally, you’ll find an application that does not provide the proper checks of any input going into the application. And this is a perfect place for an attacker to put their own malicious code.
A very common type of injection attack is a SQL injection, but there are other types that can include HTML, XML, LDAP, and other data types. A similar application attack is one called a buffer overflow. With a buffer overflow, you’re adding information into a particular area of memory reserved for a variable, but you’re putting more information than that variable can hold. And the extra data overflows into the buffer of memory that is next to this variable.
This is another attack that is enabled because the application itself is not doing any type of checks for input into the app. This means the attacker can add much more information to the input and the application will improperly allow that information to be written into memory. Fortunately, this is a relatively difficult exploit for an attacker to discover. There are many different variables.
Memory works in different ways depending on the application and use. And very often, this simply crashes the application instead of providing any functional use for the attacker. But if the attacker does find a buffer overflow that they can repeatedly use and has consistent results, then they may have a very powerful attack against this application. Some applications will allow an attacker to gather information from the network directly or from a victim’s computer and replay that information to the server to gain additional access to the application.
This is referred to as a replay attack. With a replay attack, the biggest challenge for the attacker is finding the information that they can use to replay back to the server. Sometimes this can be captured directly from the network using a network tap or ARP poisoning, or simply putting malware on the victim’s computer. Once the attacker has a username and password hash or they have a session ID, they can use that to replay against the server to gain access.
In some situations, this is two different attack types that are being used together. You might use an on- path attack to gather information from the network, and then use the replay attack to send that information to the server. When a user logs into an application, they are often provided permissions that are appropriate for their role.
A user would not commonly be granted administrator rights or higher level permissions by simply logging into the application. But of course, an attacker is looking for these elevated rights and permissions. And if there is a known vulnerability in this application or a bug that they can take advantage of, they may be able to get privilege escalation.
We obviously want to limit the individuals that would have this level of access. So this is something we would commonly see from a system administrator, but we certainly don’t want to have an attacker with this elevated level of access. This is a relatively common attack type. And obviously, you would want to quickly patch any vulnerabilities that would allow an attacker to perform a privilege escalation, although the best case from an attacker’s perspective for a privilege escalation is to get administrator access.
But it’s possible that the attacker could perform a horizontal privilege escalation. With this type of privilege escalation, the attacker isn’t moving to an administrator access, but instead is moving from user A access to access that user B would normally have. To block a privilege escalation, your first step is to close any vulnerabilities that might be on the system by patching the application.
Then you might want to update your antivirus or anti-malware, especially with the signatures so that they can look for known attacks that might focus on this type of privilege escalation. Some operating systems are equipped with data execution prevention, which limits what areas of memory a particular executable can run. This might also be able to block certain exploits because those exploits are not running in an area of memory specifically allocated for the application.
And along those same lines, many operating systems can randomize where data may be stored within memory when the application is running. This means that each time the application runs, data may be located in a different location, which makes it more difficult for an attacker to find a vulnerability. Here’s an example of a privilege escalation vulnerability.
This is CVE 2023-29336. This is a Win32k Elevation of Privilege Vulnerability and it was announced in May of 2023. This vulnerability affected the win32k Kernel driver in server 2008, 2008 R2, 2012, 2012 R2, and 2016, and it also affected Windows 10. If an attacker was able to take advantage of this vulnerability, they would be granted system privileges in the Windows operating system, and system privileges are the highest level of privilege you can have in the Windows operating system.
Another application attack is the cross-site request attack. Cross-site requests are things that occur normally when you visit a website. For example, if you visit professormesser.com, your browser is going to load a page, and on that page is text that comes from the professormesser.com web server. Your browser might also load a video that is loaded from YouTube, and it might also have pictures and other information that might come from Instagram.
All of this loads into a single screen, and from the user’s perspective, it looks like all of this information is coming from one server when in reality, all of this information on the screen is being loaded from different servers. This is a normal process that occurs when you visit almost any website. You’ll also notice that this information on the screen is being loaded from all of these different servers, but there’s no authentication requirement.
So when this page is loaded on the professormesser.com website, even though it includes YouTube and Instagram information, you don’t have to include your YouTube username and password or your Instagram credentials. If we were to look into the code of what’s really running when you visit a website, you’ll see that it’s separated into two different types of code. Some code will run on the web server itself, and some code will run on the client side.
The client side code that runs inside of your browser is commonly HTML or JavaScript. This is rendering all of the information inside of your browser in a way that the website administrator originally authored. There are also processes occurring on the server side or the web server side itself that the browser doesn’t see. This may be the web server accepting a request from the user and processing that request with HTML and PHP.
It could be transferring funds from one account to the other behind the scenes or posting information onto YouTube. This is something the server does only on its side and your browser is not involved with any part of that process. The attackers, of course, know that some of these processes are happening on the client and some of these processes are happening on the server. And they can create attacks that take advantage of this difference between the client side and the server side.
Many of these attack types consist of cross-site request forgeries. This is sometimes referred to as a one-click attack or session writing. This is abbreviated as XZF or CSRF. We often refer to this as sea surf. This attack exists because you’ve logged into a website and now that website trusts your browser.
The attacker also knows that your browser is trusted and they’re hoping to have your browser make requests on their behalf to a server that is already trusted. For example, if you’re already logged into Facebook, the attacker may be able to create code that would cause your browser to begin posting status information on your Facebook account. Many web-based applications recognize the danger of this type of forgery and they’ve already built anti-forgery techniques into the application itself.
One way to provide this type of anti forgery is to use a cryptographic token that is used whenever a request is made by the client. This way the web server knows that not only have you authenticated properly, but you’re presenting the correct token to use for this particular transaction. Here’s the way that an attacker might take advantage of a cross-site request forgery.
We have, in this example an attacker, a website visitor, and this website visitor has already authenticated to the bank’s web server. The first step is the attacker is going to create a funds transfer request, but it needs to get that request into the hands of the bank site visitor so they might send a hyperlink to a user to have them click on it. Perhaps it’s included with an email or it’s included as a message that’s sent separately to the user.
If the victim is logged into the bank and they click one of those malicious links, there may be information sent to the web server that causes that victim’s account to transfer information and money to the attacker’s account. This all happens behind the scenes and it’s very common for the victim to not even realize that this transfer has taken place because they happen to click on one of those malicious links. A directory traversal is not necessarily an application vulnerability, but it is a vulnerability associated with a web server configuration.
This misconfiguration allows an attacker to read or write files to a web server that are normally outside the scope of the website’s directory. For example, if you looked at all of the different folders that were installed on a Windows computer, you would see folders for Windows that included program files, the Windows directory, the users directory, and others. Everything that’s in gray are directories that normally would not be accessible by the web server running on this Windows machine.
A user visiting the website should only be able to see and write to files that may be located in the dub dub dub root directory of that server. But if this web server is not configured properly, it’s possible for an attacker to gain access to other parts of this system. Sometimes the web server is configured properly, but it’s a software vulnerability within the web server software that allows an attacker to use a specially crafted attack to gain access to these other directories. And of course, there might be an application running on this web server that could allow an attacker to write to other parts of this file system that are not part of the web server itself.
Here’s an example of a line that is in a web server log that shows a user performing a GET request for a specific web page on that server. And you can see that the URL says it’s looking for ….example.com/show.asp. And you can see there are additional parameters in this URL that include ../../windows/system.ini.
The ../ is very indicative of a directory traversal because that is the command that allows you to move backwards one directory in that particular file system. So if you happen to see someone trying to use ../ whenever they’re accessing files on a web server, they’re probably checking to see if this server is susceptible to a directory traversal.