A look into how a virus can enter your computer
Hello everyone and welcome to another episode of "an actual post".
Today I'll write about one of the most common type of methods malware use to strike your PC; Overflows. This is a very complicated subject but I will do my best to keep it simple and not use too many technical terms but rather terms you're most likely familiar with or will be. So as usual, no prior computer science education needed.
There are many different ways for malware (computer viruses) to enter your system, but how would it manage to slip by any antivirus detection? Say that you have a brand new kitchen robot cooking food for you, and it gets an infection with a malware that is telling it to stab you with a kitchen knife. Any security software in this robot could easily tell that some new random program just told the robot to do something obviously bad and successfully stop it.
So to circumvent detection, malware can use different kinds of stack/buffer overflows in subroutines of other programs.
A subroutine is like a program inside a program, doing something that is commonly performed and can be called to do a specific job it is made for by the main program. To keep using our kitchen robot example, a subroutine of it could be to check if there are ingredients to cook a soup. This subroutine gets a list of things to check for; carrots, potatoes and onion, and at the end of this list there is an instruction to tell the main program the result of this investigation. This list is called a stack or buffer. Since it's basically just a stack of information. So our kitchen robot subroutine can look something like this:
When done, return this information to: These ingredients exist. (0x01)
Point 3 in this todo-list is called the return instruction, which will send the result of the ingredient investigation back to the main program that is in charge of cooking the meal. This main program is located in the robots memory while running, at a certain address, just like your home has a certain address. Every program running will have their own specific location and let's say that the address of the main program is called 0x01.
How it's abused - Buffer overflow
Now you can use this subroutine checklist for malice by injecting evil instructions instead of ingredient checking. Each ingredient on the list is only allowed to be of a certain size, which means the number of characters available for each point is limited, to let's say 20 characters. So a common tactic for malware, to avoid being caught by antivirus software, is to not execute the code themselves, but tell the native and harmless ingredient subroutine to check for something at the point before the return instruction that exceeds 20 characters. This can be just random text. Once 20 characters have been written, the following characters will be forced into the final point of the list - the return instruction. So let's say a malware infection tells the subroutine to do this: Check for 1111111111Kill owner (0x01)
What happens in the todo-list of the subrotine? This:
Check for 1111111111 (The 20 characters limitation is reached)
When done, return this information to: Kill owner (0x01) (The following instruction will be overwritten by the remaining characters the malware sent to the subroutine)
So the characters following "Check for 1111111111" which is "Kill owner (0x01)" will overwrite the following return instruction with malicious input to the main program at 0x01 to do instead of cooking food. And since the main program is not considered malicious, antivirus software will not react to this.
These kind of exploits are notoriously difficult to prevent. But there are a few ways. The two most prevalent ones in Windows is called DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization). DEP simply forbids any code from being run in the location of the ingredient subroutine, it may only transmit data back to other programs but never instructions to execute actions. ASLR makes it so that when programs are run, they are not assigned the same address every time, meaning that the main program isn't always located at 0x01 but could be at 0x49 or wherever, so that the malware return instruction back to 0x01 isn't necessarily where the main program is located and as such nothing will be executed since the instruction was sent to an empty or otherwise wrong address. There are however...
Ways to combat the ways to combat this
Malware is pretty much always a step ahead so of course you can pass these security measures. The most sneaky one being to not use any own code, but abuse other already present and neccessary functionality of the robot. So to bypass the DEP protection, malware can construct a chain of other harmless actions and turn it into its own end goal.
So let's say our robot also has other functions for cooking you food that it needs to be able to do: Walking (like for walking around the kitchen and serving food) which is located at address 0x02, Grabbing things (like kitchen tools) which is located at address 0x03, and Attach (to blend ingredients into pots or otherwise combine food with each other) which is located at address 0x04. These are all vital to the functionality of the robot and will also not be stopped by the antivirus or other security measures.
So what malware can do to escape the prevention of its own code being executed, it can simply change the return instructions to point at a different program instead of the main program and keep doing so to create a chain of events. Instead of telling Main program at 0x01 to walk up to the owner and kill them, the return instructions will instead point to 0x02 - the walking program, with information to initiate its own subroutine to walk up to the owner instead of garbage ingredient check data and then overwrite the return instruction away from the main program at 0x01 to:
When done, return this information to: Instructions for walking (0x02)
So the attacked ingredient check subroutine will instead of sending data back to the main cooking program simply send normal harmless instructions to the normal harmless Walking program at 0x02. That program will receive those instructions coupled with the next buffer overwriting of the return instruction address to point at 0x03: the Grabbing program. Which the malware instruct to grab the kitchen knife and then again overwrites the return address over to 0x04: the Attach program with instruction to attach the knife it now holds into the owner it has walked up to.
Individually these actions are harmless, but chained together it causes the robot to perform the otherwise illegal action of stabbing the owner without ever executing anything of its own code and as such bypasses the DEP protection.
In real life it will often be a chain that makes Windows use the command prompt to download and execute things from the internet that would otherwise be caught by security measures.
ASLR can also be bypassed in several ways, but that would have to be a whole separate post as this one is already getting quite long now.
Real life example: Equation Editor
One of the most popular native Windows programs to exploit today is the Equation Editor that Microsoft Office programs which allows you to write mathematical equations in a document. A subroutine in the Equation Editor that checks for and returns which font to use in the equation can be exploited by buffer overflows since it was written before DEP was implemented and is therefore vulnerable to executing malicious commands. The font information only supports 40 characters, so entering something longer than that can overwrite the return instructions to point at another location, such as the address of WinExec (which starts up programs), which will instead of a font name get instructions to execute Powershell and make it run a code snippet that downloads the complete malware. Since powershell ran that instruction, it has administrator rights and is whitelisted by security software due to it being a crucial Windows functionality.
All computers with Office programs older than 2018 are vulnerable to this exploit. It is not entirely known why Microsoft never patched this flaw in Equation Editor, but rumours has it that they have simply lost the original code and is therefore unable to rebuild it. Due to this major security flaw, Equation Editor was removed from Office programs by the end of 2017. But many computers around the world still uses Office programs from before 2018 and this attack vector is therefore still seen today.
That is all I had planned to write for this time. I hope it was informative and gave a glimpse into one of the countless of sneaky ways malware can get into your system. Thank you for reading!
theartofmadeline
2087
izzy806
andulkaphoto
baratheonpilled
ellievsbear
