The time is came to publish the first release of unDLP. This journey was scattered of obstacles coming from the old and venerated Perl gods ! But that’s not all, hold on, the famous TLS protocol made me sweated more than once … bloody block size limitation …
Well, before I get into the main topic, here is a small reminder about the reasons that pushed me to develop unDLP.
As you probably already know, industrial spying cost millions of dollars to companies every year through data exfiltration, data stealing, etc. In order to protect themselves against this bane, companies invested into DLP technologies, allowing to protect sensitive information from hackers and malicious employees. A few existing solutions allow bypassing such security measures. However, none of them are flawless, discrete, or efficient enough to guarantee success. That is why unDLP was born.
To resume in a few words, unDLP aim to discreetly exfiltrate information via multiple covert channel. At the moment, only one has been implemented, HTTPS.
unDLP follow a standard client / server architecture, providing various types of features. Let’s take a look at them.
At the present time, only the HTTPS exfiltration method has been implemented. This engine is straightforward, the client will successively send POST requests, containing the data to exfiltrate, to the server. On the other side, the server will bufferize the incoming information till the transfer is done then it will save them on the file system.
By the same token, the protocol created for the file transfer allows the server to handle multiple files at the same time, ensuring that no collision occurs during the sending.
The client provides the possibility to specify multiple files to send. However, due to the fact that the multi-threading is discouraged with Perl and that forking doesn’t seem to work properly, the files are dequeued when the previous job is done. I will try to find a solution in order to affords a true multi-upload system but at least, for now, we don’t have to restart the client for each file … It’s better than nothing
The transfer speed is adjustable in order to avoid detection. Indeed, it could be suspect to see 1 POST request by second targeted the same domain name during 1 or 2 minutes !
For the same purpose, unDLP provides the possibility to change the size of the data blocks transferred. However, in view of the TLS limitation, it is not possible to increase this parameter above a given ceiling.
Even if data encryption is not necessary when using HTTPS, this functionality has been implemented in prevision of the upcoming exfiltration methods.
At first, I implemented an asymmetric encryption but I quickly switched, due to performance issues, to a symmetric scheme. For the same purpose, I choose to use the AES with CTR mode. It is not the safest way to perform encryption nevertheless, it is enough to counter MITM monitoring.
Note: I discourage to use encryption when using the HTTPS exfiltration method due to TLS block size limitation that force to reduce the chunks of data, which terribly affect the transfer speed and could take ages to handle a large file.
usage: unDLP.pl -f [FILE, ...] -d DESTINATION -m [HTTPS] [--e PASSWORD] [--size SIZE] [--delay DELAY] [--help|h] -f: File to transfer. -d: Destination. -m: Exfiltration method. --e: Set the encryption password. --size: Set the transfer size. --delay: Set the transfer speed (in second). --help|h: Display the helper.
usage: server.pl [--e PASSWORD] [--help|h] --e: Set the decryption password. --help|h: Display the helper.
Note: It is important to note that even if the server is started with a decryption password, it is still possible to handle raw data.
- Improve the multi-upload system
- DNS exfiltration
- RTCP exfiltration
- [and other type of exfiltration]
Pull requests for new features, bug fixes, and suggestions are welcome !
P.S: keep in mind to respect the Perl::Critic::Freenode policies.
I hope that you enjoyed this article.