Sapocalypse Blackhat. J2EE hacking. Nightmare nightmare
Hello! Here, many asked us to write more; in fact, having carved out the time between flights, I remembered a couple of old vulnerabilities in ... well, you guessed it.
Much time has passed since the first publication of information about these bugs. Or rather, a whole year. Exactly a year ago, I went to BlackHat with a report on the J2EE security theme of the SAP engine. Why not tell about that bug, especially since they have not yet reached out to describe in detail in RuNet everything that was presented on BlackHat, well, not counting a small video from ZeroNights , where it turned out pretty messy.
The study was devoted to the SAP NetWeaver J2EE Engine platform, about which, compared with the ABAP Engine, there is very little information, and there is almost no research worldwide on its safety. But you don’t feed Digital Security Research Group with bread, just let it break up something that no one else has ever gone to. In general, first there will be a few general words about what SAP is and how important it is for business, so cynics can scroll down - to pieces of code, well, everyone else can read further.
')
All business applications from SAP are based on one of two platforms, not counting the old solutions and all sorts of supporting applications. More precisely, there is a third platform - SAP Business Objects, on which a number of systems operate, but in general it is less common and to some extent similar to the NetWeaver J2EE Engine.
Platform number one, the oldest, well-known and more or less studied from the point of view of security is SAP NetWeaver ABAP. Based on this application server, such systems as ERP, CRM, SRM, PLM and other three-letter abbreviations work, which are usually enumerated in order to give themselves weight in the eyes of smart people. All these applications are united by a single goal - to automate business processes. What this means, many still do not know, but for this article it does not matter.
The second platform is the SAP NetWeaver J2EE Engine (hereinafter referred to as the “J2EE engine”; under the J2EE engine, the article refers to the entire application server platform, with all applications, and not the core of the JAVA virtual machine). This platform, in fact, is designed to combine business applications, that is, in itself, it often does not contain any critical information, but acts as a so-called mediator. The list of such applications based on the NetWeaver J2EE platform includes, among other things, SAP Portal, a kind of universal enterprise portal that provides unified access to various resources, for example, through SSO. On the portal, you can often find a link to the interface of some internal SCADA-system, which is not directly available, but some of the functionality is translated into the portal. Than it threatens, I think, clearly. In addition to the portal, for example, the SAP XI / PI application is based on the J2EE engine, which is an enterprise integration bus and provides the exchange between various business applications, and quite a few other applications. In general, what am I doing all this for?
Suppose you need to gain control over business flows in a single company (I will not ask why you need it, and you will not ask where this example came to my mind). In order to do this, it is much easier to hack a server, which is a link, than a bunch of servers processing data. Moreover, as for the safety of the ABAP engine, there have already been a lot of research, and it is gradually becoming more secure, which cannot be said about the JAVA engine, which was developed a little more than completely by the Indians.
So, it was decided to dissect the J2EE part. Our safety studies of the JAVA engine, started sometime in 2009, resulted in the discovery of about 200 vulnerabilities, most of which are currently being closed by the manufacturer. In addition to the mass of XSS-ok, vulnerabilities of information disclosure and other relatively trivial problems, there were also more interesting bugs, which, in fact, tell you more.
Everyone knows that it is much cooler to detect a whole class (or at least a subclass) of vulnerabilities than a separate problem, since, having discovered a new class, it will be possible to find a lot of examples. And with examples in the J2EE engine, there will be no problems, because the SAP NetWeaver J2EE Engine platform is a J2EE application server that allows you to host applications written in JAVA. This is something like Apache Tomcat, only 100 times more, and more difficult, and more incomprehensible - and where there is complexity, vulnerabilities will certainly appear. On this server, in fact, the business systems themselves are located, such as SAP Portal, SAP XI, SAP PI, in the form of individual applications or a set of applications, as well as proprietary applications. Such large systems consist of smaller applications (applications), each of which is often comparable with a small web project in complexity and code size. There is a huge set of such applications by default. So, in the version of NetWeaver 6.40 there are about 500 of them, and in version 7.2 there are already 1200 of them. Naturally, each application contains its own bugs, but there’s no need to search for them there, and they are all quite specific. We wanted to find something more general, some kind of mass vulnerability, which means that it should potentially be present in all applications.
People familiar with J2EE applications probably know that at least one file combines them all - web.xml. People who are even closer acquainted with this file and with SAP, most likely, already guess what this is about. But first, let's look at the structure of a typical WEB.XML file:
By that, I probably already knew where there could be a mistake ... no, do not rush to poke a finger at an unclosed tag, I mean not just a typo, but a vulnerability that can lead to sad consequences. Not found? Then I recommend reading on. The J2EE engine has a mechanism like Invoker Servlet. It allows you to call any servlet (part of the application that performs functionality on the server) directly on the class name, in order to make it easier for developers to access the class directly in debug mode. In any case, this is explained in such a way, so I will not argue, maybe it’s really convenient. But it is especially convenient to bypass the security settings by typing the name of the lass for this servlet in the URL bar like this: / servlet / <servlet-name-or-class>.
The problem begins at the moment when you make a servlet that performs a dangerous action, place it in any directory such as / admin and close it to access with the help of <auth-constraint> for everyone who admins as an admin. Fail is that the servlet can still be accessed directly via Invoker at the link / servlet / <servlet-name-or-class> and get the necessary data without authentication, since direct access to the / servlet directory is not blocked in any way (if if the defense was on / *, then everything would be OK). So simple and concise, and it does not matter that there is no buffer overflow in J2EE applications and that JAVA is safer than C when there are such architectural bugs.
The main problem for us was that it was necessary for all of the 500 applications that did not filter access to Invoker Servlet and perform dangerous actions through this servlet - because you need to show the real risk, and not just poke your finger at the architecture curve with the words: "this is theoretically, in special situations, provided a + bc * d can lead to something not very good."
One funny web service, for example, allows you to read an arbitrary file from the OS, and it is vulnerable to this bug, which means you can read files stored on the server. If you wish, you can even download data directly from the DBMS and delve into financial transactions ... the main thing is that the browser does not freeze from opening and downloading files of several gigabytes, but this is a completely different story.
Something we did not have enough of this vulnerability, and not comme il faut somehow, without E shells on BlackHat to go. Therefore, I began to look further: what else can be created with WEB.XML? And then I remembered an old article about vulnerabilities like Verb Tampering. quite a valid bug described in theory, and there were no practical examples on real systems. Naturally, I decided to try: what if it works, and, not particularly hoping for good luck, I almost choked on my morning donut ... It really works - no, well, it can not be! Gorgeous!
After the passions subsided, I realized that I really had to, because it was one thing to discover a problem in architecture, and another to find a real example of the fact that such vulnerabilities exist. However, I will tell you what is actually the case. So, here is another example of WEB.XML, or rather, its part, which is responsible for access control:
In our example, it is indicated that only the user with the role of admin and only the GET method can access applications located in the / admin directory. No o you pass? It’s not so: it turned out that everything that is clearly not prohibited is allowed, that is, for example, a call using the HEAD method, which does exactly the same thing as GET, only does not show the result to the user, can be implemented , without a user and without a role at all. Why? Yes, because it is so written in the file: in the / admin directory using the GET method, only admins can. And by other methods - to anyone! That is, if the name of the method was not explicitly stated, it would mean that all methods can only be used by the admin, and everything would be OK. And once indicated one method, then please excuse all the others.
Do you want to be happy? Yes, it was not there: now we must again look for a needle in a haystack, or rather, at least some application installed on the J2EE engine, which:
• Vulnerable to Verb Tampering
• Supports a HEAD request and processes it in the same way as GET
• Performs a critical action, and the response body is not important to us, since this is HEAD
• Preferably present in all installations, not just as a demo example
Yes, tired. Yes, I found.
In general, this application is called ... but by the way, this you can find out by carefully reading this post. And it is as much a control for a J2EE web-based engine. That is, you can create a user in the system, so what's the user there! You can assign any role to it, you can execute an OS command, you can remotely stop the server, and all this with one simple HEAD request.
At the same time, SAP Portal, which uses the J2EE engine, can be easily downloaded on the Internet. For example, like this: inurl: / irj / portal
The coolest part of the story is that when I went to Bangalore to attend the SecurityByte conference (the so-called “Indian Silicon Valley”, I’m writing and holding laughter directly), to tell a presentation on this topic, I was approached by no less than one of developers of the most vulnerable interface, thus my suspicions were justified. The developer, by the way, turned out to be a cool guy, and I, of course, thanked him for helping me get on Bla c kHa t , so if you are still wondering how to do this, I can recommend a great idea. Just kidding
That's all for today, I finish these lines on an airplane flying to Las Vegas on Bla c kHat 2012, where I am going to present one very elegant bug - by the way, also in SAP and also in JAVA, so wait for the report ...
Much time has passed since the first publication of information about these bugs. Or rather, a whole year. Exactly a year ago, I went to BlackHat with a report on the J2EE security theme of the SAP engine. Why not tell about that bug, especially since they have not yet reached out to describe in detail in RuNet everything that was presented on BlackHat, well, not counting a small video from ZeroNights , where it turned out pretty messy.
The study was devoted to the SAP NetWeaver J2EE Engine platform, about which, compared with the ABAP Engine, there is very little information, and there is almost no research worldwide on its safety. But you don’t feed Digital Security Research Group with bread, just let it break up something that no one else has ever gone to. In general, first there will be a few general words about what SAP is and how important it is for business, so cynics can scroll down - to pieces of code, well, everyone else can read further.
')
Some water
All business applications from SAP are based on one of two platforms, not counting the old solutions and all sorts of supporting applications. More precisely, there is a third platform - SAP Business Objects, on which a number of systems operate, but in general it is less common and to some extent similar to the NetWeaver J2EE Engine.
Platform number one, the oldest, well-known and more or less studied from the point of view of security is SAP NetWeaver ABAP. Based on this application server, such systems as ERP, CRM, SRM, PLM and other three-letter abbreviations work, which are usually enumerated in order to give themselves weight in the eyes of smart people. All these applications are united by a single goal - to automate business processes. What this means, many still do not know, but for this article it does not matter.
The second platform is the SAP NetWeaver J2EE Engine (hereinafter referred to as the “J2EE engine”; under the J2EE engine, the article refers to the entire application server platform, with all applications, and not the core of the JAVA virtual machine). This platform, in fact, is designed to combine business applications, that is, in itself, it often does not contain any critical information, but acts as a so-called mediator. The list of such applications based on the NetWeaver J2EE platform includes, among other things, SAP Portal, a kind of universal enterprise portal that provides unified access to various resources, for example, through SSO. On the portal, you can often find a link to the interface of some internal SCADA-system, which is not directly available, but some of the functionality is translated into the portal. Than it threatens, I think, clearly. In addition to the portal, for example, the SAP XI / PI application is based on the J2EE engine, which is an enterprise integration bus and provides the exchange between various business applications, and quite a few other applications. In general, what am I doing all this for?
Suppose you need to gain control over business flows in a single company (I will not ask why you need it, and you will not ask where this example came to my mind). In order to do this, it is much easier to hack a server, which is a link, than a bunch of servers processing data. Moreover, as for the safety of the ABAP engine, there have already been a lot of research, and it is gradually becoming more secure, which cannot be said about the JAVA engine, which was developed a little more than completely by the Indians.
So, it was decided to dissect the J2EE part. Our safety studies of the JAVA engine, started sometime in 2009, resulted in the discovery of about 200 vulnerabilities, most of which are currently being closed by the manufacturer. In addition to the mass of XSS-ok, vulnerabilities of information disclosure and other relatively trivial problems, there were also more interesting bugs, which, in fact, tell you more.
Read from here
Everyone knows that it is much cooler to detect a whole class (or at least a subclass) of vulnerabilities than a separate problem, since, having discovered a new class, it will be possible to find a lot of examples. And with examples in the J2EE engine, there will be no problems, because the SAP NetWeaver J2EE Engine platform is a J2EE application server that allows you to host applications written in JAVA. This is something like Apache Tomcat, only 100 times more, and more difficult, and more incomprehensible - and where there is complexity, vulnerabilities will certainly appear. On this server, in fact, the business systems themselves are located, such as SAP Portal, SAP XI, SAP PI, in the form of individual applications or a set of applications, as well as proprietary applications. Such large systems consist of smaller applications (applications), each of which is often comparable with a small web project in complexity and code size. There is a huge set of such applications by default. So, in the version of NetWeaver 6.40 there are about 500 of them, and in version 7.2 there are already 1200 of them. Naturally, each application contains its own bugs, but there’s no need to search for them there, and they are all quite specific. We wanted to find something more general, some kind of mass vulnerability, which means that it should potentially be present in all applications.
And better from here
People familiar with J2EE applications probably know that at least one file combines them all - web.xml. People who are even closer acquainted with this file and with SAP, most likely, already guess what this is about. But first, let's look at the structure of a typical WEB.XML file:
<servlet> <servlet-name>CriticalAction</servlet-name> <servlet-class>com.sap.admin.Critical.Action</servlet-class> </servlet> <servlet-mapping> <servlet-name>Critical</</servlet-name> <url-pattern>/admin/criticalfunc</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Restrictedaccess</web-resource-name> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> By that, I probably already knew where there could be a mistake ... no, do not rush to poke a finger at an unclosed tag, I mean not just a typo, but a vulnerability that can lead to sad consequences. Not found? Then I recommend reading on. The J2EE engine has a mechanism like Invoker Servlet. It allows you to call any servlet (part of the application that performs functionality on the server) directly on the class name, in order to make it easier for developers to access the class directly in debug mode. In any case, this is explained in such a way, so I will not argue, maybe it’s really convenient. But it is especially convenient to bypass the security settings by typing the name of the lass for this servlet in the URL bar like this: / servlet / <servlet-name-or-class>.
And here in general the most gusto
The problem begins at the moment when you make a servlet that performs a dangerous action, place it in any directory such as / admin and close it to access with the help of <auth-constraint> for everyone who admins as an admin. Fail is that the servlet can still be accessed directly via Invoker at the link / servlet / <servlet-name-or-class> and get the necessary data without authentication, since direct access to the / servlet directory is not blocked in any way (if if the defense was on / *, then everything would be OK). So simple and concise, and it does not matter that there is no buffer overflow in J2EE applications and that JAVA is safer than C when there are such architectural bugs.
The main problem for us was that it was necessary for all of the 500 applications that did not filter access to Invoker Servlet and perform dangerous actions through this servlet - because you need to show the real risk, and not just poke your finger at the architecture curve with the words: "this is theoretically, in special situations, provided a + bc * d can lead to something not very good."
One funny web service, for example, allows you to read an arbitrary file from the OS, and it is vulnerable to this bug, which means you can read files stored on the server. If you wish, you can even download data directly from the DBMS and delve into financial transactions ... the main thing is that the browser does not freeze from opening and downloading files of several gigabytes, but this is a completely different story.
I cheated, actually the most gusto here
Something we did not have enough of this vulnerability, and not comme il faut somehow, without E shells on BlackHat to go. Therefore, I began to look further: what else can be created with WEB.XML? And then I remembered an old article about vulnerabilities like Verb Tampering. quite a valid bug described in theory, and there were no practical examples on real systems. Naturally, I decided to try: what if it works, and, not particularly hoping for good luck, I almost choked on my morning donut ... It really works - no, well, it can not be! Gorgeous!
After the passions subsided, I realized that I really had to, because it was one thing to discover a problem in architecture, and another to find a real example of the fact that such vulnerabilities exist. However, I will tell you what is actually the case. So, here is another example of WEB.XML, or rather, its part, which is responsible for access control:
<url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> In our example, it is indicated that only the user with the role of admin and only the GET method can access applications located in the / admin directory. No o you pass? It’s not so: it turned out that everything that is clearly not prohibited is allowed, that is, for example, a call using the HEAD method, which does exactly the same thing as GET, only does not show the result to the user, can be implemented , without a user and without a role at all. Why? Yes, because it is so written in the file: in the / admin directory using the GET method, only admins can. And by other methods - to anyone! That is, if the name of the method was not explicitly stated, it would mean that all methods can only be used by the admin, and everything would be OK. And once indicated one method, then please excuse all the others.
Do you want to be happy? Yes, it was not there: now we must again look for a needle in a haystack, or rather, at least some application installed on the J2EE engine, which:
• Vulnerable to Verb Tampering
• Supports a HEAD request and processes it in the same way as GET
• Performs a critical action, and the response body is not important to us, since this is HEAD
• Preferably present in all installations, not just as a demo example
Yes, tired. Yes, I found.
In general, this application is called ... but by the way, this you can find out by carefully reading this post. And it is as much a control for a J2EE web-based engine. That is, you can create a user in the system, so what's the user there! You can assign any role to it, you can execute an OS command, you can remotely stop the server, and all this with one simple HEAD request.
At the same time, SAP Portal, which uses the J2EE engine, can be easily downloaded on the Internet. For example, like this: inurl: / irj / portal
The coolest part of the story is that when I went to Bangalore to attend the SecurityByte conference (the so-called “Indian Silicon Valley”, I’m writing and holding laughter directly), to tell a presentation on this topic, I was approached by no less than one of developers of the most vulnerable interface, thus my suspicions were justified. The developer, by the way, turned out to be a cool guy, and I, of course, thanked him for helping me get on Bla c kHa t , so if you are still wondering how to do this, I can recommend a great idea. Just kidding
That's all for today, I finish these lines on an airplane flying to Las Vegas on Bla c kHat 2012, where I am going to present one very elegant bug - by the way, also in SAP and also in JAVA, so wait for the report ...
Source: https://habr.com/ru/post/148480/
All Articles