It’s nothing new to say that every moment hundreds of thousands requests with malicious payloads are hitting web servers around the world with bad intentions. Probably you’ve seen it many times in many different forms. I would like to take a deeper look at some of them: webshells.
These attacks are really common nowadays because of the nature of the Internet. Millions of web servers seems to be attractive targets for attackers. When you think about the role of the web servers in the organizations then the attractiveness of such targets is even greater.
Intro - before you start testing your luck
Over the years the Internet has changed. Web servers are not only responsible for displaying simple private or business websites. Development of languages such as JavaScript, PHP, Python or Ruby have already begun to play a significant role in business applications, online shops, internet entertainment, blogs or others. Those applications are often created using off the shelf products accessible to the rest of the world which results in numerous vulnerabilities. Who didn’t hear for instance about another vulnerability in Wordpress or phpBB recently? Such popular web applications have become the main target for the groups trying to build their botnets or spread malware. When another 0-day is published, the attackers try to obtain access to victim machines on a large scale. They start massive scanning for vulnerabilities as long and wide the Internet is. Some of attacks aimed at the web servers, can be more severe if web server become a gateway to the internal infrastructure - more on that later.
First act - try and you might get lucky today
I’m going to present three different examples how attackers try to bypass security measures and upload webshells on target systems - including RFI (Remote File Inclusion) and SQL injection.
Hiding webshell code inside the well-known file format
Below is a log entry presenting an attempt to execute code using RFI vulnerability.
1 2 3 4 | |
Many of the common RFI exploit scripts, as well as attack payloads sent by hackers append the ? symbol to the included (malicious) URL. In order to avoid the issues with developer supplied strings appended to the URL by the application. It is similar to SQL injection utilizing comment specifiers (--, ;-- or #) at the end of their payloads.
Attacker tried to trick the web application to include a JPG file from the remote server. Is it really a JPG image? Let’s take a closer look:
1 2 3 4 5 6 | |
As you can see above, it’s not an image at all - although it contains a valid GIF file header. Trustwave has an interesting blog post that provides more details on how attackers can hide malicious code in the image files. Let’s analyze the beginning of the PHP code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | |
Class pBot defines an array with all the config information. Probably server and port fields caught your attention as it provides information about C&C that potential bot will be trying to communicate to. Before we check what is behind the irc.malink.biz, I would like to know something more about domain malink.biz itself. Using Passivetotal service we can check the history of that domain and actual whois records.
Owner from USA with all personal data available?! Is this what you would expect from suspicious domain? Maybe a homepage will give us some answers…
nothingsecure…OK, now it seems to be more logical :) Info from IRC is also giving clear answer about intentions:
Ok, so let’s take another step forward and focus on irc.malink.biz.
1 2 3 4 | |
They care about failover ;)
To sum up geo - server in Paris received a crafted request from host in Madrid with a link to the domain sxxxxxxo.no (Columbus, OH) to download a file byroe.jpg with embedded webshell. Inside of the file, we found IRC server irc.malink.biz which resolves to more than one IP - load balancing DNS records using round robin method (Germany, UK, Canada).
How does it look like ? :)
Virustotal confirms AV detection rates seems not too bad. At this point, it’s worth to mention that it’s NOT good to upload any files to VT as a first step of the analysis. Start with OSINT research. For example, before you upload the file, check if file’s hash is not already stored in VT database. Sharing potentially malicious files (remember that VT database is public!) might warn an attacker and give him a chance react quickly.
Images are not the only way how attackers try to bypass the WAF.
Hiding webshell using code obfuscation
The attackers might try to hide their intentions by encoding and compressing the malicious code. This allow to bypass some of the filters and signatures used by WAFs. Another RFI attack:
1 2 3 | |
Content of the suspicious file:
1
| |
This is a typical example of obfuscated PHP code. It will be passed to the eval() function for execution, but before that it needs to be:
- base64 decoded
- ROT13
- inflated
There is also a more troublesome version of this. Imagine multiple layers of obfuscated code using the same functions as presented before. Obtaining the original code requires repeated decoding, so manual work with the PHP interpreter ceases to be comfortable. In case you stumble upon such sample then I suggest to use phpdecoder.
Here’s the code after deobfuscation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | |
First part of the code is sending email confirmation about infection to [email protected]. After that there is a code responsible for command execution on infected system and printing output on the page. “Production” example found on the Internet:
As you can see an attacker uploaded a few more “add-ons” like Mailer-1.php, Mailer-2.php, 1337w0rm.php etc.
Again I use VirusTotal to check AV detection ratio:
This time not so good - most of AV engines did not recognize file as suspicious.
Delivering webshell using SQL Injection
Take a closer look at the following example:
1
| |
First of all attacker needs a SQL Injection vulnerability. Next a specially crafted request will inject PHP code which will be saved on the server.
Explanation:
1
| |
This is a simple webshell that will be used to execute commands on the web server. Depending on the SQL injection vulnerability attacker needs to place it in appropriate column. In this example the table has three columns. Code will be placed in the second one with others set to NULL.
1
| |
This SQL command allows attacker to write the webshell code to an arbitrary file.
1
| |
Path where webshell will be stored. Important thing to note is that attacker needs to find directory on the server with write access e.g. temporary folders. In addition to that crooks have to find a way to force application to execute webshell script in this case this can be achieved via LFI. Following example includes all the above dependencies.
After executing the SQL query the webshell file is created. Now the attacker can interact with the webshell by simply sending a HTTP GET request and defining the following URL:
1
| |
The directory listing of /var/www will be returned by the server. Et voilà!
At the end, check how VirusTotal looks for that simple one-line webshell:
Perfectly invisible ;)
If you would like to read or watch more, take a look at article on greensql or YouTube movie.
With three brief examples we’ve just scratched the surface of this interesting topic. There are many other different ways to place and execute arbitrary code on a remote server and interact with OS. In the second part I’d like to focus on a case which shows how dangerous webshells can be for a business infrastructure and describe methods to protect against them.