Why you should never trust PoC exploits on GitHub
Jason could feel his skin tingle as the muscles tensed up in his fingers. As he stared at the console, he realized he stumbled upon a potential vulnerability in the logging system of the API he was testing.
He vividly remembers reading about the vulnerability. It was all over the news last year. While Russia amassed troops at the Ukrainian border and the COVID-19 Omicron variant was surging around the planet, the Apache foundation was disclosing a vulnerability affecting millions of users, throwing the tech industry into a frenzy responding to the new threat.
Jason never thought he would find it lurking in the bowels of a popular API a year later. But here it was. And the bounty for this bug was going to be great. He just needed to put together a proof of concept (PoC) to demonstrate the vulnerability before he could submit it and cash in on his work.
A quick search on Google for an exploit yielded tons of results. So much noise as every self-professed “cybersecurity expert” seemed to have written something about it. But within all that noise was a positive signal his eyes gravitated towards… a GitHub repository with working exploit code.
His heart raced as he clicked on the link that took him to the repo. He skimmed through the README and realized it was a fully built exploit that spun up a local LDAP server and constructed a payload that would trigger remote code execution on the target system when run.
It was everything he needed to prove the exploitability of the API server.
He cloned the repo. Intense concentration exuded from his face as he slightly bit his lip, reading through the docs to figure out the exact command to run. A few keystrokes later… he saw it in action. His PoC worked, and he received a connection from the API server.
Unbeknownst to him, it worked too well. For far across the globe in the shadows of the night, a new command and control server also received a connection… a reverse shell directly from Jason’s computer.
Jason didn’t know it yet, but the repo he cloned had trojan source embedded in it. A supporting library imported by the PoC exploit itself contained malicious code hidden in plain sight that connected back to the owners of the repo. So while Jason was testing a vulnerability thanks to a library dependency for logging, he got exploited by a… well… a library dependency of the PoC.
He got pwned.
The moral of the story? Never run code from GitHub that you don’t fully understand. Especially exploit code.
Then again, you shouldn’t trust code blindly from anywhere or anyone. You should always make sure you understand what it does first. From StackOverflow to ChatGPT, I don’t care if it’s your best friend or some friendly AI… verify what you plan to run.
Let me show you why.
The greatest oracle of proof of concept exploits… GitHub
Over the years, GitHub has become one of the greatest resources for sample code. Security professionals share their PoC exploits worldwide and leverage the platform to help others gain access to their work. It’s an excellent way for researchers like us to collaborate, share ideas, and discover new vulnerabilities in software.
But despite this noble cause, it has also become a playground for malicious actors. From shady repo owners overstating their skillset in order to attract “investors” to bots scouring GitHub repositories for misconfigured credentials… malicious actors have been leveraging the platform in many ways.
The underlying problem is that it can be difficult to accurately assess whether code is truly authoritative and trustworthy or not.
And the bad guys know this.
The plague of malicious CVE proof of concept (PoC) exploits on GitHub
In October of 2022, some researchers from the Leiden Institute of Advanced Computer Science at Leiden University released a paper titled “How security professionals are being attacked: A study of malicious CVE proof of concept exploits in GitHub.” In it, they showcase how in their investigation of proof of concept (PoC) exploits demonstrating impact against known vulnerabilities reported as CVEs between 2017 and 2021 on GitHub, more than 10% of the repositories showed symptoms of malicious intent.
In other words, 10% of the PoC exploits were themselves potentially malicious.
And that tracks. Earlier last year, Bleeping Computer wrote an article about how there were several fake windows exploits on GitHub that actually contained Cobalt Strike, an agent that allows for a persistent remote connection on a target. They were explicitly targeting the infosec community and trying to install a beacon on the security professional’s system by infecting it from within the PoC exploit.
So what’s the solution?
It’s an unfortunate reality that bad threat actors will always try to use the goodness of the security community to act as a watering hole for their attacks. We need to accept it. Just like we had to learn to accept that we have to live with COVID in our day-to-day lives. Staying safe comes from using common sense and following basic hygiene rules.
Only run untrusted code after first understanding what it does. That’s just good advice all around. However, we can do better than that.
When looking for proof of concept (PoC) exploits, start by using exploit-db, the Exploit Database. While it could be better, it is a more reputable repository of exploits maintained by Offensive Security, the information security training company that brings you things like the OSCP and OSED certifications, as well as Kali Linux.
The Exploit Database is a CVE compliant archive of public exploits and corresponding vulnerable software that has been developed for use by penetration testers and vulnerability researchers. It is one source of truth you can rely on when looking for valid exploits. And they provide attribution of any PoC code; so if the original source was a GitHub repo they will tell you and link to it… so you can have more confidence it’s been reviewed.
And it has a great CLI tool that makes searching the Exploit Database a breeze, called searchsploit.
Of course, even these PoCs should be run in an isolated sandbox environment. In this day and age of virtualization, there is no reason to run untrusted code from within your main desktop. Run it virtualized. Then monitor the virtualized networking for suspicious traffic that isn’t between you and the target. Even better, use ephemeral resources (throw away VMs or containers) that can be destroyed as soon as the PoC has completed its run. Consider running those in the cloud through Linode, AWS, Azure etc…
If a PoC is a binary, run it through an open-source intelligence tool like VirusTotal. It will analyze the binary and check it against known threats and malware. Even if you have built it from the source, the binaries may hold known bad patterns that can be detected. Scanning it with something like VirusTotal can be a great help.
And finally, never trust a PoC exploit when the author does not have a solid reputation in the community. If you don’t know who wrote it, don’t run it. Verify the source code before running it or read through everything to ensure that no malicious calls are being made as part of the execution.
Over time, you will begin to build an arsenal of PoC exploits. It gets exciting when you can start WRITING your own instead of relying on others to do it.
Conclusion
Security professionals must always be aware of malicious threats lurking on the internet. Keeping up with security best practices and following these tips can help ensure that you don’t get caught up in a malicious attack through the use of an untrustworthy PoC exploit. Always take necessary precautions before executing any code from any source, even if it comes from reputable sources.
Above all, realize that Ronald Regan’s thinking that we can “trust, but verify” is backward. Trust nothing. Verify everything.
It’s just safer that way.
Agree? Disagree? Want to read more stuff like this? Sign up for my free newsletter here, and be notified when new content is released, and chats go live.
The post Why you should never trust PoC exploits on GitHub appeared first on Dana Epp's Blog.
*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/why-you-should-never-trust-poc-exploits-on-github
