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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
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-2014-7298
Published: 2014-10-24
adsetgroups in Centrify Server Suite 2008 through 2014.1 and Centrify DirectControl 3.x through 4.2.0 on Linux and UNIX allows local users to read arbitrary files with root privileges by leveraging improperly protected setuid functionality.

CVE-2014-8346
Published: 2014-10-24
The Remote Controls feature on Samsung mobile devices does not validate the source of lock-code data received over a network, which makes it easier for remote attackers to cause a denial of service (screen locking with an arbitrary code) by triggering unexpected Find My Mobile network traffic.

CVE-2014-0619
Published: 2014-10-23
Untrusted search path vulnerability in Hamster Free ZIP Archiver 2.0.1.7 allows local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse dwmapi.dll that is located in the current working directory.

CVE-2014-2230
Published: 2014-10-23
Open redirect vulnerability in the header function in adclick.php in OpenX 2.8.10 and earlier allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the (1) dest parameter to adclick.php or (2) _maxdest parameter to ck.php.

CVE-2014-7281
Published: 2014-10-23
Cross-site request forgery (CSRF) vulnerability in Shenzhen Tenda Technology Tenda A32 Router with firmware 5.07.53_CN allows remote attackers to hijack the authentication of administrators for requests that reboot the device via a request to goform/SysToolReboot.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.