Application Security
6/17/2014
03:50 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Scope Of SAP Bugs Still Plagues Enterprises

As SAP closes its 3,000th security vulnerability, ERP experts expound on the dangers of these vulns and enterprises' continued head-in-the-sand attitude about them.

On the occasion of SAP recently closing its 3,000th vulnerability, experts in the niche field of enterprise resource planning (ERP) security report that, though SAP vulnerability numbers may be dipping, the risk of SAP exploits is actually on the rise. The severity of security notes released by SAP have increased in importance, these experts say, and most enterprises still don't realize the true scale of the risks they face from criminals seeking to exploit some of their most mission-critical systems and data.

"If you're an attacker, why would you lose time trying to break into a file server or web application or a wireless access point if you can go directly to the systems that fully store their most sensitive data, and you have really low chances of being detected?" says Mariano Nunez, CEO of Onapsis.

Last week, security researchers with ERPScan released a report to mark the occasion of SAP's patching of its 3,000th vulnerability. Among its conclusions, the report indicated that the number of vulnerabilities in SAP products within enterprises is usually much higher in proportion to other software portfolio assets than security practitioners think. According to ERPScan, SAP vulnerabilities account for 5% of all vulnerabilities ever published on the Internet.

Meanwhile, ERPScan notes that, though SAP's secure development lifecycle is improving and the numbers of security updates it releases per year are on a downward trend, the numbers themselves may indicate more improvement than really exists. Part of the issue is that not all SAP vulnerabilities have CVEs attached to them, because many smaller patches are hidden within Service Packs.

"While the number of vulnerabilities closed by SAP Security Notes per year is decreasing, SAP moves a lot of vulnerabilities to Service Packs, leaving in security notes only highly critical issues and the issues which were found by external researchers," says Alexander Polyakov, CTO of ERPScan. "So, in previous years, only about 10% of monthly published vulnerabilities were found by external researchers, but now up to 60 to 70 are found by them in more recent updates."

Nunez agrees that SAP's outreach to customers about code security is improving, and he says that the shift four years ago to a monthly security patch cycle was key for helping customers plan their updates. But he also warns customers to understand that, because more security fixes are hidden in service packs, the security notes that do come out now are proportionally more important than in years past. "If they're highlighting specific notes that you should pay attention to, then they're probably more sensitive or more critical than what you used to get before."

Additionally, he says that SAP customers may be lulled into a false sense of security by the company itself through some of the updating tools it offers to customers.

"To give you an idea, there is a tool called RSECNOTE that is an SAP program you can run in your SAP environment to find unpatched vulnerabilities, but that will only tell you the notes or patches that are critical and easy to implement," Nunez says. "In real life, that is actually telling you about less than 20% of the patches that you're actually missing."

This kind of issue contributes to what both Polyakov and Nunez agree to be an oblivious attitude that enterprises hold about the scope of their SAP vulnerability risks. In particular, some of the top risks organizations face with SAP revolve around configuration vulnerabilities, because SAP is so customizable. Slight configuration tweaks are difficult to carry out, because they could break important business processes.

"At the very least, you have to reboot the system to reconfigure it. For example, to close a vulnerability in the authentication protocol of the SAP Software Deployment service, the new versions of client and server software have to be installed, and it can sometimes be quite challenging," Polyakov says. "It is harder to monitor, check, and control than simply apply patches, which usually close only typical issues, such as XSS or Directory Traversal."

One customer Nunez helped found that it was justifiably worried about breaking systems due to configuration tweaks -- just a minute of downtime could cost the company $22 million, according to its estimates. There's no easy answer to that problem, but he suggests that organizations start by identifying its most valuable SAP systems and then conducting a security assessment of its biggest configuration and patchable vulnerabilities.

"Prioritize them based on risk, probability, and impact to the business, and make a top 10 or top 20 list of issues to start raising the bar against potential attackers," he says. "Because one thing we see is people are still exposed to vulnerabilities that may be five or 10 years old with public exploits available."

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Christian Bryant
50%
50%
Christian Bryant,
User Rank: Ninja
6/18/2014 | 1:24:35 PM
Re: Key Takeaway
@Robert McDougal

Good point.  In fact, while I'm not a huge fan of every new language that's out there, I will say that the new language affords an opportunity to re-architect and ideally code securely.  I actually had high hopes for OpenERP, but we'll see how it does as Odoo...

I think you just hit on a market challenge there, Robert!  Takers?
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
6/18/2014 | 12:44:49 PM
Re: Key Takeaway
The main issue here is that SAP was conceived in a time before the importance of secure coding was universally accepted.  Specifically, SAP ERP first debuted in 1973.  Even thought there was an architecture change in 2004, if the SAP programmers are like the programmers I have run across they didn't completely change the flow of the program, they simply used the same information flow for the new platform.  By doing so, they brought along with them any of the vulnerabilites present in the existing software.

If someone came to market today with and ERP system with all the SAP bells and whistles written from the ground up with security in mind, they could make a major push.
Christian Bryant
50%
50%
Christian Bryant,
User Rank: Ninja
6/18/2014 | 2:49:55 AM
Key Takeaway
To commit your enterprise to a monolithic, commercial program is to commit to its vulnerabilities.  The key takeaway from the SAP story is that security and long-term maintenance capacity through intelligent configuration management should guide the infrastructure plan for your company.  Do you really want to write downtime into your infrastructure as a revenue killer if you already know that will prevent the easy installation of vital security patches?  Architecture must be informed by the security prospects of the applications that comprise it and the ease with which patches and updates can be applied.  DevOps through an agile lens might aid in better application choices when seen from this perspective.

What's interesting about SAP is the manner of security risks it has presented over the years.  Because SAP is designed to connect to numerous external systems, integration and centralization of information under this beast is on one hand an enterprise dream come true, and on another a cyber criminal's dream realized, too.  Through exploitation of the RFC library, ubiquitous in SAP, hackers enjoyed access to logon information, called function names, parameters information and content, tables information and content, client and server information, and more (Blackhat Europe 2007).

Tools like sapyto, a framework for SAP penetration tests, shipped with plugins for take advantage of these RFC vulnerabilities.  With access to SAP, criminals had access to EVERYTHING.  Security as part of an architecture requirement means more than identifying firewall and patch needs.  It informs the designer to NOT let the enterprise system exist such that criminals CAN take the entire enterprise because of a monolithic application's weaknesses.  We need to design better than that.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
DevOpsí Impact on Application Security
DevOpsí Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, itís a ďdevelopers are from Mars, systems engineers are from VenusĒ situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3587
Published: 2014-08-22
Integer overflow in the cdf_read_property_info function in cdf.c in file through 5.19, as used in the Fileinfo component in PHP before 5.4.32 and 5.5.x before 5.5.16, allows remote attackers to cause a denial of service (application crash) via a crafted CDF file. NOTE: this vulnerability exists bec...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.