Key Lessons From Verizon’s ‘2016 Data Breach Investigations Report’

Verizon 2016 DBIR

The annual Data Breach Investigations Report (DBIR) is out and reinforces the value of well-established cybersecurity practices. The good folks at Verizon have once again published one of the most respected annual reports in the security industry.

The report sets itself apart with the authors intentionally avoiding unreliable “survey” data and instead striving to communicate what is actually happening across the cybersecurity breach landscape. The perception of security typically differs greatly from reality, so this analysis provides some of the most relevant lessons for the field.

Report data is aggregated from real incidents that the company’s professional security services have examined in supporting customers. A large number of security partners also contribute data for this highly respected report. Although this analysis is not comprehensive, it does provide a unique and highly valuable viewpoint, anchored in real incident response data.

Many of the findings support long-standing opinions on the greatest cybersecurity weaknesses and best practices. Which is to say, I found nothing too surprising, and the report reinforces the current directions for good advice.

Key Report Findings

  • Human weaknesses
    30% of phishing messages were opened by their intended victims.
    12% of those targets took the next step to open the malicious attachment or web link.
  • Ransomware rises
    39% of crimeware incidents were ransomware.
  • Money for data
    95% of data breaches were motivated by financial gain.
  • Attackers sprint, defenders crawl
    93% of data breaches were compromised in minutes.
    83% of victims took more than a week to detect breaches.
  • Most of the risk lies in a few vulnerabilities
    85% of successful traffic was attributed to the top 10 CVE vulnerabilities. Although difficult to quantify and validate, top vulnerabilities should be prioritized.

Key Lessons to Apply

  • Train users. Users with permissions and trust are still the weakest link. Phishing continues to be highly effective for attackers to leverage poorly trained users to give them access.
  • Protect financially valuable data from confidentiality, integrity, and availability attacks. Expect attacks, and be prepared to respond and recover.
  • Speed up detection capabilities. Defenders must keep pace with attackers. When preventive controls fail, it is imperative to quickly detect the exploit and maneuver to minimize its overall impact.
  • Patch top vulnerabilities in operating systems, applications, and firmware. Patch quickly or suffer. It is a race; treat it as such. Prioritize the work based upon severity ranking. Serious vulnerabilities should not languish for months or years!

This is just a quick review. The report contains much more information and insights.
I recommend reading the Executive Summary or the full Report.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Key Lessons From Verizon’s ‘2016 Data Breach Investigations Report’ appeared first on McAfee.

Server-Side Request Forgery Takes Advantage of Vulnerable App Servers

Server-side request forgery is an attack in which an attacker can force a vulnerable server to trigger malicious requests to third-party servers and or to internal resources. This vulnerability can then be leveraged to launch specific attacks such as a cross-site port attack, service enumeration, and various other attacks.

This ability makes server-side request forgery potentially dangerous because a vulnerable server can be leveraged as a proxy and can attack other public resources and local infrastructure.

20160506 SSRF 1

Some common vulnerabilities related to server-side request forgery:

  • URL redirection
  • Remote file inclusion
  • SQL injection
  • Frame injection
  • Link injection
  • XML external entity

 

What can an attacker do using this vulnerability?

An attacker who has identified this vulnerability can leverage it for further attacks, including:

  • Port-scan internal hosts on the intranet protected by the firewall.
  • Attack internal applications.
  • Access local web server files using the file handler “file:///c:/windows/system32/.”
  • Enumerate services.

Attackers can use other options such as mailto://, gopher://, etc. But these depend on how the request is handled by the server and the parser.

 

Port scanning

Server-side request forgery can take advantage of port scanning.

Scanning local interface:

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:80

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:443

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:21

Based upon the difference in responses, attackers can infer open and closed ports. Similarly, one can scan other resources.

This process can also be automated with Burp’s Intruder feature by setting the payload position as:

GET /Vulnerablepage.php?VulnParameter=http://127.0.0.1:§§ HTTP/1.1

Next set the “payload set” as “numbers,” “ports” from “0-65535,” and start the attack. Remember to uncheck payload encoding.

 

Testing server-side request forgery

Normally any input field that accepts a URL is an ideal candidate for this attack. However, we have seen that applications with random parameters from which nothing can be inferred were also vulnerable to this attack. Thus it is always a good practice to check for this vulnerability on suspicious parameters because we do not know how the parameters are handled by the server.

20160506 SSRF 2

 

Creating a proof of concept

The following steps will help a penetration tester develop a proof of concept.

  • Identity a potential input field in the application to test this vulnerability.
  • Start Netcat on a server (with server name “servertest,” for example) with the following command
    • (nc –l –v port no)
  • Once the server is running, enter the following payload in the vulnerable input http://servertest:portno/testSSRF
    • Use a unique directory such as /testSSRF to ensure that the request is triggered from our vulnerable server.
  • If the server is vulnerable, it will establish the connection and the Netcat listener will display the details about the connection as shown in the following screen capture.

20160506 SSRF 3 

Tools

Burp’s collaborator feature comes in very handy when testing this vulnerability. It can help initially identify this issue, which can then be manually verified by the preceding technique.

The collaborator sends payloads to the affected application that are crafted to initiate connections with the collaborator server. Burp then continuously monitors the collaborator server to ensure if any request has initiated a connection.

 

Recommendations

  • Do not trust user data, and perform data validation.
  • Harden application servers, and ensure that unnecessary ports and services are not open and running.
  • Implement a whitelist policy for allowed hosts and services.

 

References

https://portswigger.net/burp/help/collaborator.html

http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html

https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#

The post Server-Side Request Forgery Takes Advantage of Vulnerable App Servers appeared first on McAfee.

Adobe Releases Security Updates for Flash Player

Original release date: May 12, 2016

Adobe has released security updates to address vulnerabilities in Flash Player. Exploitation of some of these vulnerabilities may allow a remote attacker to take control of an affected system.

US-CERT encourages users and administrators to review Adobe Security Bulletins APSB16-15  and apply the necessary updates.


This product is provided subject to this Notification and this Privacy & Use policy.