Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

6/22/2016
11:30 AM
Chris Wysopal
Chris Wysopal
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Bug Poachers: A New Breed of Cybercriminal

As if security researchers don't have enough to worry about, we now have to contend with extortionists who take advantage of the well-established fact that applications are a ripe target for exploitation.

Security researchers walk a fine line between white hat and black hat activities. Sometimes despite being on the right side of the line, the legal side of the line, they still find themselves facing criminal charges. Consider the case of Justin Shafer: he found a security hole in a dentist office’s servers, and reported the incident to the company.

While some companies would have paid Shafer a ‘bug bounty,” he was unfortunate enough to find a hole at a company that doesn’t understand what security researchers actually do. By reporting the hole, he basically implicated himself as a cybercriminal and now he is facing criminal charges for “exceeding authorized access.”

As if security researchers didn’t have enough reason to worry about being seen as criminals, we now have bug poachers confusing matters even further. According to information from IBM, bug poachers have hit at least 30 companies. Bug poachers breach a company’s infrastructure, typically using a SQL injection aimed at a vulnerability in a company’s website. Once inside, they steal data, but here is where the twist comes in. Unlike typical black hatters, instead of selling the data, bug poachers extort their victims—telling the company they must pay to get information on how they were breached.

The bug poachers argue that they are doing companies a service. They are making companies aware of potentially harmful vulnerabilities in their systems. The vulnerabilities they exploit are publically known and have patches. They would be security researchers if they would stop once they pointed out the vulnerability. But they’re not because of their actions after a flaw is found.

Researchers publish their findings after the company has had a chance to fix the vulnerability. They most certainly do not request funds for information or threaten to actively exfiltrate data. Poachers, on the other hand, are extortionists taking advantage of a well-established yet often unrecognized fact: applications are inherently insecure.

Why Poachers Are Taking Advantage

Software isn’t designed with cybercriminals in mind; it is designed and composed with functionality as the main goal. As a result, we have design flaws, the use of vulnerable open source components, idiosyncrasies in programming languages and other insecure coding practices contributing to a large number of vulnerabilities. Research from Veracode has shown that 70% of all applications have at least one vulnerability in the OWASP Top 10 upon first scan.

Black Hat’s CISO Summit Aug 2 offers executive-level insights into technologies & issues security execs need to keep pace with the speed of business. Click to register.

This astronomical number of vulnerabilities leaves us dependent on the kindness of security researchers to help us find vulnerabilities before they are exploited. And that’s why so many companies have enacted bug bounty programs. Instead of punishing researchers for finding and responsibly disclosing vulnerabilities, bug bounty programs reward researchers for their work. This way, these talented individuals are not tempted to use their skills to make money in illegal ways—and there are plenty of illegal activities they could chose to do instead of responsibly disclosing vulnerabilities.

Stopping the Problem at the Source

But companies shouldn’t depend on the kindness of strangers (security researchers). Instead they need to take responsibility for their software and do the best they can to find vulnerabilities before applications are in production. Yet, according to the biennial Global Information Security Workforce Study published by (ISC)2, 30% of companies never scan for vulnerabilities in their software. No wonder we are seeing so many breaches, ransomware attacks, and now bug poaching. The proliferation of vulnerable software is making it too easy for cybercriminals to be successful. It is too lucrative of an opportunity for many talented hackers to ignore.

What can be done? The first action companies can take is to assess software for vulnerabilities during the development stage of the software lifecycle. But the software lifecycle doesn’t end at the development stage, and neither should security efforts. A shifting security landscape means new vulnerabilities are found all the time, and if a development team uses third-party and open-source components in their engineering efforts—and most do—it is possible to have a complete secure development process and still end up with vulnerabilities. This is why protecting applications in production is just as important as eliminating vulnerabilities to begin with.

A bug bounty program can go a long way toward attracting the right kind of probing into a company’s applications. And security researchers have done a lot to help companies fix vulnerabilities before the world finds out about them. But as this new wave of black hat hackers known as bug poachers demonstrates, there are still too many creative and talented hackers out there who are more than comfortable occupying the gray and sometimes black space of cybercrime. Let’s not make their job too easy. 

Related Content:

 

Chris Wysopal is Chief Technology Officer at Veracode. He oversees technology strategy and information security. Prior to co-founding Veracode in 2006, Chris was vice president of research and development at security consultancy @stake, which was acquired by Symantec. In the ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16632
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
CVE-2021-32073
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
CVE-2021-33033
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
CVE-2021-33034
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
CVE-2019-25044
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.