MWR have long been interested in SAP security. It’s very clear from talking to our clients, and to the attendees of our regular security briefings, that SAP security issues are at the forefront of their agenda. Given that SAP systems are the core operational system of many businesses, where even the smallest level of compromise can have devastating effects, this comes as no surprise. What does come as a surprise is how many organisations, clients and practitioners we speak to, don’t really understand just how easy it can be for an attacker to compromise a SAP system (often remotely) to devastating effect.
Fear, Uncertainty and Doubt (i.e., Scare Mongering) is not something MWR believe in or a tactic that we employ. However, when trying to raise awareness of SAP insecurity issues and champion the message, we have been subjected to accusations of such by those with opposing agendas. Therefore, when ERP-SCAN gave their very interesting presentation at the RSA conference this year2 that revisited an informative white paper released in 2011 and provided updated statistics with regard to the state of SAP security, we felt that the message that MWR had been preaching was somewhat validated.
The findings from the research conducted by ERP-SCAN research make for very interesting reading and re-enforce the message that MWR has delivered at security conferences such as CRESTCon, BSides, Sec-T, DeepSec and T2. However, to (badly) paraphrase a popular movie, we aren’t heading for a disaster of biblical proportions, fire and brimstone is not coming down from the sky, there won’t be forty years of darkness, no earthquakes, volcanoes or dead rising from the grave! Most of the clients we have worked with on securing their SAP implementations haven’t been as exposed as the owners of the systems in the research presented. There is a limit to how far you can go (legally) to prove the results and therefore the conclusions made cannot be truly accurate (when honouring the laws of the land). For example, just because a server banner is returned when probing a system that is associated with a vulnerable piece of software, does not mean it is vulnerable. The only way to be 100% sure, would be to exploit the suspected vulnerability. However, the results really do make for very interesting reading. Do read the paper and the presentation.
It is important to note, before we dive in, that SAP are making great efforts publically to appear to be making security a priority. They have implemented an internal SDLC process, hold security summits for internal teams and are investing in automatic and manual security assessments of new and old software versions. All of these efforts are to be commended. However, there are many reasons why SAP security is such an issue and no one individual can really be blamed (sorry, it can’t ALL be SAP’s fault!) SAP systems can incorporate many different modules (ERP,ECC, CRM, PLM, SCM, SR, …), that are installed on multiple operating systems (UNIX, HP-UX, Linux and Windows, etc.), that in turn rely on many different back-end databases (DB2, Sybase ASE, Oracle, MS SQL, MaxDB and Informix). There are also many different versions/application stacks (SAP Netweaver 7.1 ABAP AS, 7.2 ABAP/Java AS, 7.3 ABAP/Java AS, …). Basically, SAP systems often consist of very complex architectures and employ a myriad of integration choices in order to offer interoperability with enterprise systems. This has led to a situation whereby a SAPdeployment can expose an incomprehensibly massive attack surface through which an organisation can be compromised.
SAP is hard to secure because the security of numerous components needs to be understood. This means a wide variety of skills in different areas of security are required. To compound this,SAP uses what is called an “Instance Profile”, which is basically a text file that can contain over a thousand configuration parameters defining password and authentication policies, system trace levels and logging options, etc.. It is not an easy task to get right!
SAP systems also have resident vulnerabilities, just like any other software. SAP publishes security notes that are akin to Microsoft Security Bulletins, Red Hat Security Announcement or Oracle Critical Patch Updates and/or Security Alerts, etc.. In 2011, SAP published an average of 65 notes every month. That is more than Microsoft, Oracle or Cisco! The results of the research conducted by ERP-SCAN show that the number of vulnerabilities per year is reducing, but worryingly the criticality of the discovered/reported issues is increasing. With SAP boasting more than 180,000 customers worldwide and reportedly 74% of Forbes 500 running SAP, it certainly constitutes a tempting technology for attackers to consider.
The research showed that ERP-SCAN profiled SAP systems on the Internet and also used research performed as part of the Internet Census performed by the Carna Botnet to collate data. A crafted search using the Google search engine identified 695 unique SAP servers on the Internet. The Shodan search engine was also used to identify 3,741 different SAP systems. Additionally, the “Internet Census” data when inspected revealed 3,326 SAP systems, and a port scan executed across the Internet found 5,000 SAP routers listening for incoming connections. That is quite an Internet footprint!
Many of the systems discovered on the Internet were also reportedly found to be running vulnerable services and/or old and out of date versions of SAP software. In addition, it was found that systems could be exposed to attack from unauthenticated attackers and/or authenticated attackers (who could gain access using default well known username/password combinations). In MWR’s experience, once a foothold on a SAP system is obtained, it is often trivial to leverage and abuse standard SAP functionality to achieve full compromise.
It is obvious from the results that these sources can be used by attackers to quickly identify organisations’ Internet-accessible SAP systems. However, in MWR’s experience, other sources can be just as useful for identifying organisations who have deployed SAP systems and importantly, expose dangerous and often abused SAP protocols to their Local Area Networks. Users on a LAN often have Internet access and can send and receive electronic mail. If their systems can be compromised and used as a beach head – which is a very popular means of attack today (drive-by/water-hole/phishing) – they can be used to compromise internal SAPsystems. Technologies such as WinShuttle are used to ‘connect’ desktop applications such as Excel, allowing them to process and consume data from SAP systems via the Remote Function Call interface. The product site contains a detailed and lengthy client list that can easily be used to identify potential targets. In MWR’s experience, users of such products often don’t often realise they are even using a SAP system. The product from WinShuttle certainly isn’t the only such technology, or web site that contains such a client list.
Interest in SAP platform security has been growing exponentially in recent years – not just from the Information Security community, but also from other sources that do not have your best interests at heart. MWR have developed a number of tools and scripts to aid security practitioners in auditing SAP systems. The tools have become very popular, and communications are received from many sources requesting support with their use (as well as providing very valuable feedback helping us make much more effective and useful tools). It has been enlightening to realise how many security practitioners are now beginning to audit SAP systems for their clients.
So, whilst the results of ERP-SCAN research show a worrying number of potentially vulnerableSAP systems online and exposed to attack, there are many more out there behind closed doors, battening down the hatches, raising the drawbridge and watching very closely who is knocking at their door.
Perhaps with the media attention on SAP and more pressure being placed on the company to be seen to be making efforts to address their insecurities, as well as individuals and groups in the Information Security community developing tool sets, services and capabilities to help organisations secure their systems, maybe, just maybe, in a few years we’ll see less worrying results from research that won’t be worth commenting on!