Why was the blog "Using metasploit to Search for vulnerable SAP Systems" removed

[ceedee666]

Hi all,

recently there was a blog post by Lars Fasel on using metasploit to search for vulnerable SAP systems on the internet. However, this blog post has been removed, most likely by a moderator.
For me it's not clear why this has happened. There was no disclosure of an 0-day vulnerability. Instead, the blog highlighted how common it is to mistakenly expose service of a SAP system on the internet. In my opinion this kind of information should be widely available so administrators can take the necessary steps to solve these security issues. Or even better be aware of them and don't make the mistake in the first place. However, instead of publishing this information it is removed from SCN. This feels like trying to establish some security by obscurity, which clearly doesn't work!

Any other opinions on this? Am I totally wrong with my interpretation?

Best,

Christian

[Former Member]

This time it was not me.. 🙂

I was only sent a copy of the blog when some discussion about it started between the moderators.

The author apparently agreed that it would encourage the wrong sort of behaviour and content on SAP's own site (the blog itself was not very critical realy) so removed it.

Black market versions might still be abailable in google cache anyway if you are interested in the content.

Best person to answer would probably be himself.

Cheers,

Julius

[Former Member]

Hello,

while I would have liked to see the discussions this article would have raised, I also agree with the moderators to some extent. In the end this is a forum owned by SAP. Although in this particular case, it's not SAP's fault that their customers (recklessly?) expose their systems. However, I am skeptical that the blog post would have changed anything. As long as auditors don't search for technical vulnerabilities, nothing will change. In my personal experience security has no priority until something happens or an audit fails.

The article was intentionally kept very trivial. All that was demonstrated was how to use a script for a search engine (ShodanHQ) that indexes the http server headers and use that output as input for another script that tests common SAP related web services.

Even somebody that has never seen Metasploit, should be able to replicate the results within 1-2 hours of reading some basic tutorials like these: Metasploit Unleashed,  SAP Pentesting using Metasploit. Alternatively the same can be accomplished with a few lines of Python using this library

I assume it's OK to post the results here. It won't be as visible as a blog post, but it may still get some traction.

-------------

HTTP return codes:

200: resource available and did not require any authentication

307: forwarded to another URL. most of the time this will be forwarded to the corresponding https URL.

401: resource available but requires authentication

403: access restricted

500: internal server error

In total we had 2327 IP addresses that ran a web server on port 80 which had "SAP NetWeaver" in its server header. Again, this was a simple search, nothing tricked out or filtered or whatever to clean it up or to add more systems. The table below lists the occurrences of the services and the HTTP codes.

SICF Service	200	307	401	403	500
webgui	452	340	10	307	152
RFC using SOAP Runtime	5	336	328	442	158
ALE using SOAP Runtime	2	337	308	469	158

452 systems with an exposed webgui over HTTP!!! 5 systems even had predefined credentials in their RFC SOAP services!

---------

That the webgui is exposed to that extent shows a lack of awareness, a lack of a good comprehensive security concept and carelessness. There is just so much wrong on so many levels...

Best regards,

Lars

[Former Member]

You would expect with all the publications on SAP security (from a technical perspective), awareness within companies would grow and they give this the attention it needs. However, somehow you still see a lot of companies struggling to get their environments properly secured.

Factors that will not help is the lack of available expertise - often SAP security consultants are still SAP authorization consultants -, and the complexity of implementing a proper security design: securing an (existing) environment properly without hampering business processes is quite a challenge and requires diverse skills to be able to oversee all consequences.

I think it is good that these posts on technical security keep appearing on forums and in blogs. Hopefully, it will convince people / companies to give this the priority it deserves.

[ceedee666]

Hi Julius,

thanks for the clarification.

Christian

[ceedee666]

Hi Lars,

it is also my experience that security is generally a very low priority in SAP implementation projects. This is exactly the reason why I like your blog that showed and explained some very basic mistakes.

As an example take the systems that expose WebUI over HTTP. I would expect this happens due to the following reasons. Some functional consultant or developer needs to solve a problem in a project. To solve this problem some SICF service need to be activated. Without an understanding of the possible security risks these services are activated without some expert in the security area involved. This results in the the problematic situation you have described (WebUI or other service being exposed over HTTP). It's also clear to me, that some additional errors need to happen (e.g. firewall configuration etc.) for the system being exposed on the internet.

The point I'm trying to make is that more consultants and developers should be aware of the security implications of some of their actions. This would IMHO help to significantly improve. The more people are aware of the risks, the higher the probability is that someone thinks twice before performing a critical action. I don't think security can be achieved by just pointing at security consultants and/or auditors. These guys are just a part of the whole puzzle.

In summary, this is what I liked about your blog post and why I think it is a pity it is gone. It was a nice introduction for the non-experts in the security area.

Christian

[Colleen]

Hi Lars

It looks like Christian posted his comment before me but it's similar experience for me...

you are right - quite a few SAP Security consultants come from authorisation only background and, event then, struggle with securing the application layer with the objects (think RFC connections and system users with SAP_ALL).

What does not help either is sales/business development teams selling clients project implementations and ignoring security from the costing or requirements. It's seen as a Basis task and that's about it. Security becomes a built to budget or leave as vanilla as possible.

Most convincing comes when the auditors are skilled enough to identify the issues and make recommendations. But then management will see the $$$ required to fix it and baulk at the amount. This progresses to the equivalent of an insurance policy - unless there has been a violation/attack they don't see the need to invest in proper security.

Regards

Colleen

[Former Member]

As a response to the original post, security is a continuous process of improvement, you may be at a level where certain aspects may appear lax and vulnerable. At the same time there are users and investigators who are at a level in UI over internet where they can dilute your best effort. So please do not be in a haste to benchmark a security solution, rather continuously challenge it.

At the time of development - a developer definitely needs a near free hand to prepare a code, yet as we Tp the code to Test systems, the security needs to be tightened to a real life delivery scenario.

But I agree the integration scenarios with RFC or TCPI protocols need to be critically tested from all known angles.

Regards

[Former Member]

There are good points being raised in this thread; and I think the need for better security of SAP systems and auditing of security specific configurations is well known…. by those of us on this thread.

The bigger question for me from this thread is how do we raise the awareness to the developers/admins who enabled the WebUI over HTTP, and for the auditor who didn’t know to look for that? My take away from Lars’ original post was that identifying these issues is easy to do with various solutions (full disclosure; I work for a vender of such a solution, check my profile for details); yet it is not being done.

Part of the problem is a gap in responsibilities; the Basis team is responsible for maintaining the systems and keeping them running, the developers with providing the business with the functionality they need. Neither team (in most organizations I work with) has been given the responsibility of ensuring the security and soundness against cyber-attacks of those systems. The typical security team on the other hand has no SAP expertise (and are not likely to be reading this thread, unfortunately) and so seldom get any kind of report on the state of an SAP system and when they do are unable to understand the report.

How do we bridge that gap? Education is the approach that I am taking; and educating both sides of the isle (so to speak). Helping demystify SAP systems for traditional InfoSec teams and providing them with the knowledge and tools (be it commercial or free like Metasploit or Bizploit) helps those teams bring SAP systems into their existing vulnerability management programs that they already have in place for the rest of the business systems. For the SAP teams, showing them that their SAP systems can be vulnerable to more than just SoD type abuses; but from cyber-attack at the framework layer. And that applying security to SAP systems doesn’t have to be a negative activity but can ensure the integrity of their systems.

I’d love to hear from others where they see the gap or disconnect and their ideas of how we can bridge that gap and raise the security awareness around SAP and the security of SAP systems themselves

[Former Member]

Hi Juan,

In my opinion the classic SAP security is a business function and can't be made to handle technology. I would go so far to say that classic SAP Security experts may know what an IP address is, but will not be able to explain the purpose of a subnet masks. In my opinion this is perfectly ok. I wouldn't expect that knowledge from an SD or MM expert either.

Basis can't fill the technical security role. You want your best basis people securing the system since they may most likely able to grasp the complexities and dependencies. However, you can be 100% assured that as soon as there is a severe production issues, these guys will be made to take responsibility and drop everything security related. Basis already has enough on their plate and most of the time don't have the right mindset. Stuff needs to be done quickly.

Regarding the InfoSec industry just take a look at the number of SAP related talks on events like BlackHat or DefCon and how full these presentations are. SAP is horribly complicated. It's much more effective, easier  and spectacular to compromise a company through other technologies. There are a few exceptions and companies will purchase products like yours, but the initiative come from the CISOs with no insight into the SAP technology. What happens then, the basis teams may configure some parameters so that your reports turn green (which is already a huge win, don't get me wrong) but that is nothing different then the issues that arise when compliance drives your security.

In my opinion there needs to be a new job function in the SAP world. Just like the classic SAP Security from business view there needs an equivalent position that focusses on SAP Security from a technological view (perhaps something like Functional-Security vs. Technical-Security).

When I started to focus on this field I was naive and thought that people would jump at the issues immediately if I raise awareness and show how simple it is to attack an SAP landscape. It's not working. It's overhead and additional work for the basis teams. It also requires a new way of thinking and a security focused mindset which will not happen anytime soon.