 Okay, well, take it off for coming to this talk, which is name I'm covering, SIP vulnerabilities. And it's basically the process I followed, tried to understand how the protocol works and trying to use that information from a security perspective. So I'm Martin Gaccio from the consulting team of Core Security. So let's start by reviewing the agenda for the talk. First, I will give a quick introduction on the topic and what SIP is. Then I will start showing some of the previous work that has been done on the protocol and showing the motivation for my research. Then I will show some of the main components of the subnet-weaver architecture for those who are not familiar with. Moving on to the main section of this talk, which is dissecting and trying to understand how the protocol works ending up with some results showing some of the tool side develop and discussing some defenses and confirmations that can be applied. So let's start. SIP is a software company based in Germany. It's the leader business software provider. And most of the large enterprises runs the most critical process on subsystems. So it has become a hot topic in security in recent years. And I think that some components are still not covered. One of the things is that some of these protocols are proprietary and documentation is not public. So this is one of the things that makes it difficult to have more knowledge about sub security. So this talk is basically about the DIAC protocol. DIAC means dynamic information and action gateway. And it's a network protocol used for communications between the sub-grid, the desktop client application, and the application servers, the subnet-weaver application servers. So this protocol is present in every subnet-weaver installation that is based on ABAP. And one of the main characteristics is that the protocol is not encrypted and it's only compressed by default. So encryption is optional and can be implemented using a third party product or a free product that were released by SAP last year. And the component is co-SNNC for secure network connections. So the protocol runs on TCP ports 22,000 and 2299. And there were a lot of work in the recent years around the protocol. Back in 2009, there were some proprietary tools to try to dissect the traffic of the protocol and getting clear text credentials. But the students were not public, so there's no match. In 2009, Securon published a paper in which he introduced a metal for sniffing the clear text credentials which they called a reflection metal, which is basically to get a network trace of a login and starting a fake server and using the trace of that session and connecting with another grid to that fake server and looking to process memory to get the point text password. So it's not a very useful attack. It works, but it can be used in a practical way. So in 2010, Dennis Yurichov published in his blog an article where he found that the compression algorithm being used in the protocol is the same that the compression algorithm using in MaxDB open source product. So MaxDB is an open source database. So the implementation of the algorithm, the compression algorithm is available. He writes a small tool to decompress the traffic and it helps a lot trying to understand how the protocol works. More recently in 2011, there was a lot of work on the protocol. The main one and the most interesting is a proxy-like tool that was released by Sempost. And it's a hub application that you can run to make a proxy communications between GUI and the application server. So additionally, the compression plug-in for Warshack was also released. And some sniffing capabilities were added to Cayenne and Abel to get also credentials. So as can be seen, most of the previous work was based on the compression and the compression of the traffic. And the protocol inner workings and details about the packet format remains still known. And there's no practical tool to perform a penetration test against this protocol or to make an assessment. So this was mainly the motivation for my research. And also the protocol is relevant because it's present in every NetWeaver installation. And we often see customers that are not using encryption. So this makes also an interesting point. And additionally, out of the around of 2,200 security fixes published by SAP, only two affect the protocol. So this also makes an interesting point to make some assessment and trying to attack the protocol. So let's move on to the main components of the SAP NetWeaver architecture. The NetWeaver architecture is the infrastructure layer where all SAP's applications run. And it's based on a three tier layer. So in the presentation layer, there's the SAPGEE client, which is a FAT client, a desktop application. And a browser in case you are accessing SAP's web applications. The database layer is independent so you can use any commercial database product. And in the business layer, there are two main different versions of NetWeaver. One based on Java and the other one based on ABAP. And we will talk in a few slides. So this talk is mostly focused on the ABAP engine part and the SAPGEE client, which are the components that uses the protocol for the communications. So some concepts and components that I want to mention because are relevant. The first one is the ABAP. ABAP is SAP's programming language. All standard programs, almost all standard programs of any SAP application are written in this language. And you can also customize and create your own programs. So this component plays a key part on every SAP system. Another interesting concept is the dispatcher and the work processes. The dispatcher is the service that listen to the network for requests coming from the GUI application, from the GUI client. And distributes all those requests to a pool of different work processes. Each work process handles different tasks and runs different tasks. There are five different work processes. We will be mostly focusing on dialogue work processes, which are the operating system process that parses all the requests coming from the dialogue protocol. And the last concept that I want to mention is the dialogue processing, which is the programming method which is used for all ABAP programs and is based on two different concepts. Screens that are all the screens that you see in the SAP GUI client with all the controls and input boxes, et cetera. And the dialogue steps, which are all the logic behind one screen and another. So this is important for the protocol because all the screens travels from the network, from the GUI to the server and from the server to the GUI in the dialogue protocol, using the dialogue protocol. So SAP uses different network protocols, different components. Some of them are standard like HTTP, SSL, et cetera. And others are proprietary protocols. The first, all one of the first protocols that came up is the network interface protocol. It's a protocol used to do some error handling and do some checks on all network connections. And different proprietary protocols runs above this one. So you have, for example, the RFC protocol, which is remote function call. And it's used to call a remote module in another system. The router protocol, which is used by subrouter that is an application level gateway that is used to control access between different network segments to subsystems. And then you have the dialogue protocol, which is the subject of this talk. So having said that, setting some context about SAP, let's start by reviewing the process I followed trying to understand how the protocol works. So my approach was mostly a black box approach. One of my goals was not to reverse engineer the binaries. The binaries are very huge and the code is really complex. So the idea was mostly to enable traces at both sites in the GUI and the application servers. And by analyzing network traces and the application traces, trying to understand how the protocol works and how all the packets are composed. So another of the goals was to learn by interacting with the different components. And at the time that having some knowledge about the protocol implemented in my own tools. So let's see how a regular DIAC packet looks like. First is the network interface protocol, which is only a four bytes header that it contains the length of the remaining payload. And the DIAC protocol is composed by different headers and the payload itself. There's one header that is optional and it's only used during the initialization, which is the DP header. Then you have the DIAC header which carries information about the communication. The compression header which is also optional and only present when the payload is compressed. And the payload itself that is the part that carries all the relevant information, all the screens, data, et cetera. And it's composed by a variable number of different items. So let's start with each one. Initialization is start by the GUI application. It's only composed by the first packet and only travels and compress. And during my test I only identified two relevant states of the protocol. When the connection is initialized or not initialized. So there's nothing more on this. The DP header is a 200 byte length header and it has two different semantics. For an internal perspective is used for inter-process communications between the dispatcher service and all the different work processes. And from a network perspective, which is the relevant for this talk, most of the fields are filled with default values and there are only two relevant fields. A terminal name and a length field which is the length of the remain of the packet. So let's move on to the DIAC header. The DIAC header is present in all the DIAC packets and it's an 8 byte length header. There are only two relevant fields. The first one is the mode. The mode is one byte field that identifies different sessions using the same communication channel. So you can, for example, have two different sub-G clients running different transaction, building transactions or programs in SAP. And these fields identify each one. The remaining relevant field is the compression flag which is set to a different value when the compression is enabled or disabled, when encryption is being used with SNNC. So about the compression, well, it's enabled by default. It uses two different variants of the compression algorithm, LES 77 and LES 78. And it's the same implementation of MaxDB open source products. So this code is available. And one interesting thing is that it can be disabled in the GUI application by setting a special environment value. So when the payload is compressed, there's a compression header with four fields. It's also an 8 bytes length header. The first one is the uncompressed length of the payload and identifier of which algorithm is being used. And magic bytes which are constants. And a special field which depends on which protocol is being used. So the payload itself, which is the most important part of every packet, is composed by a variable number of items. During my tests, I identified these 11 different items. Some of them are for care information about the screen, about the connection, XML streams and et cetera. And we will be focusing on one of these items, which is the ABPL or ABPL for items, which carries the most relevant information. So each one of these items has also their own header. The first field is the type which denotes if there is an ABPL or ABPL for item. Then you have a length field, which also can be two bytes length or four bytes. And then you have two additional identifiers, an ID and SID. During my tests, I identify 172 different combinations of IDs on SIDs. So if you have, if you look at a DIAC packet, you can find several different items and several different ABPL items, each one with their own mean and their own format. So the combination is really big and the complexity of each packet is so, so interesting. So the first one is that one of the ABPL items that must be included during the initialization is the protocol version. So one of the things that I found is that if you specify a specific version number during the initialization, all the remaining packets coming from the server will be uncompressed. So this is useful, for example, if you are writing an exploit or some script or some code and you don't want to use all the compression functions in all your packets. Another interesting thing is about the authentication. What I found is that the authentication is performed as a regular dialogue step. So the authentication is from the protocol perspective, is the same that every single transaction that you can run in the GUI application. There are input boxes, you enter information, that information travels to the server, the server parses and handlets, that's all. So this has also an interesting thing from a security perspective and is that all the packets and all the requests coming from the GUI application using the dialogue protocol are handled using privileges because the program doesn't know which are the user and it's not already authenticated. So another thing that I found interesting and I think that is the most important one is that I found that the dialogue protocol is used only for carrying all the screens and all the context information but the actual actions on both sides on the GUI application and on the application server are performed using RFC codes. So there's one special APPL item that carries RFC codes. RFC is another SAP's proprietary protocol. It's mostly used for interfaces and for communicate different SAP systems or SAP external systems. So this is interesting because the server does not accept RFC codes until you have authenticated but because of the protocol is unencrypted and there's no strong or mutual authentication, the client do accept RFC codes and this can be used in a very interesting way. So this is interesting. Let's move on to some results and finding of my research. First is for packet dissection. I wrote Warshack plugin. It's a plugin written in C and C++ and it has four main disectors. The first one is for the network interface protocol and just all the DCP reassembly. Basically not much. I also include an additional disector for the router protocol with some basic support and changes the DIAC protocol disector, the most important one which handles all the compression and identifies the different parts of the DP header, the DIAC header and the compression header. It also identifies the different items and some of the most relevant are also desects. The value of those items are also desects. And this disector also calls the RFC disector when found and embed code. So the last disector is for the RFC protocol. It has some basic coverage because it's another protocol and they will need another research project. But some of the relevant parts of an RFC code are also desects. So here are some screenshots. I will be showing some fun with the tool later. For packet crafting, I build a small library using SCAPI. SCAPI is a Python library to craft packets at low level. It's a framework that you can use to build your own protocol implementation. You can extend and create new packets using SCAPI classes. So there are four main classes. The SAP network interface class, another class for the DIAC DP header. The main one for the DIAC protocol, which is the one that handles all the compression. One class for DIAC items. Some classes are included for the relevant items. You can also create different classes for the different items. So the tool also includes an extension for all the compression and the compression, which is based on the compression functions being public. So I also include some example scripts and proof of concept scripts. For example, to gather information on the application server, to perform a login brute force using the protocol, to run a money in the middle attack, set a proxy between the GUI application server, or to plant a fake DIAC server. So I will show some of the tools working. So the setup for these demos is very basic. I have a these Linux box with my tools installed. And I have an application server running in another VM. So I will start the Warshack and using the SAP GUI for Java, make a connection to the application server. Okay, this is the standard SAP D desktop application. So I will make a login and just to look how the packets look like. Use the display filter. And this is the initialization packets sent from the GUI to the application server. And you can find the DP header with all the relevant fields, the DIAC header and the message which each item and their values. So for example, if you want to find the credentials, you can use the different filters and look for them. For example, to one of the text contract that has a flag which is the invisible flag and denotes that there's a password. And looking into the packet, you can find, for example, the password in plain text. So this is useful for research, for trying to understand how the protocol works. And I will show also who this looks using the SCAPI classes. So I will make a connection to the application server. And I will grab the login screen. And this is how a packet looks using the SCAPI tools. So obviously each of these items and each of these fields can be manipulated. And you can also craft your own packets using these tools. So let's move on how I use these tools. Well, one of my goals was to look if there's any vulnerability in either the client or the application server. So I came up with this fusing approach for the test cases generation and for the delivery of the packets. I use my own SCAPI classes. I use WinDBG for monitoring of the target. And I use XML or RFC for synchronization between the different components. And the only thing you have to take into account if you are fusing an application server is that you have to monitor all the work process at the same time because you don't know which of the work process are handling your request. So using this approach and some manual tests, I found six vulnerabilities on the SAP application server. These issues were fixed on May by SAP. And five of the issues are denial of servers vulnerabilities. Three of them requires that you enable the developer traces on the application server. And there are two more that does not require that feature to be enabled, but all can be triggered by an authenticated and a remote attacker. And the another vulnerability and the most interesting one is a remote code execution when the developer traces are enabled. It's basically a stack buffer overflow while the application server parses one special API item. So Francisco from course exploit team wrote the exploit for this issue. So thanks to him. I will show. So all these tools can be used with two different attack scenarios. The first one and the most obvious one is to directly target the application servers. For example, to gather information about the servers to exploit the recently mentioned issues or to perform a login brute force or to test for additional vulnerabilities, et cetera. Another attack scenario that I think is used is to target the users. So for example, you can use all this knowledge and all these tools to perform a kind of client side attack. There's a feature in the application, which is called the Sharkats, that are special dot sub files that when you open with the GEE application, the GEE starts a business transaction or a program in the application server. So for example, you can use this to send by email or either embedding in a web page, different dot sub files or GEE Sharkats, point that Sharkats to your own fake servers, for example, to gather credentials or to inject RFC calls in the clients. And another attack scenario is to perform mining the middle attacks to valid GEE users, either by gather credentials or also to inject RFC calls in the user's desktop application. So let's see. So some of these attacks. First, I will start a netcap here. Sorry. I will launch an exploit for the vulnerability that I found. Here you have a reverse shell with subservice account, which is the account that runs all the database services and all the SAP services. And I will show an additional attack vector, which is to set a rogue server and using the standard GEE connect to that rogue server. For example, in this case, I customize some of the different components of the screen, for example, showing an additional fail and customizing the help, the menus. And you can also handle different events start by the GEE. So you can imagine different attack scenarios by planting a rogue server, for example. So there are some defenses or actions that can be applied to try to limit the attack surface. The first one and the most obvious one is to restrict all the network access to the dispatcher service. The dispatcher service run on ports 3200 and 399 or 998. You can use application level gateways, such as the subrouter application level gateway to perform this kind of segmentation. Another and the most important recommendation is to implement encryption on all clients. The SNSE component provides both authentication and encryption. It's available for free to, I think, all sub-customers. Another recommendation is to restrict the use of GEE shortcuts. You can disable this function on all the sub-GEE installations. Another possibility could be to use the WebGEE instead of the FAT client. Obviously patch regularly all your systems to patch, especially those affecting the DIAC protocol. There are also additional mitigation and confirmation recommendations in CURS advisory. And obviously to test regularly all your systems. So let's move on to the end. Well, we have discussed how the protocol packet looks like, the details about the protocol are now available. Practical tools both for dissecting and for crafting packets are available. Both tools will be released with GBL license. So it will be available for anyone. There are new vectors that are now practical. There are well-known vectors, but now it's possible to perform actual attacks. We have also discussed some countermeasures and defenses to try to protect your subsystems. So as you can see, there's a lot of future work that are around this protocol for example. It will be interesting to perform a security assessment and fusing of all the components and all the different items. As I mentioned, every item has their own format and there will be different vulnerabilities at the time that both the GEE or the application process the different items. Also it will be interesting to have a complete dissection of the RFC calls that are the most important part because of that the actions are performed using RFC calls. Obviously a full implementation of the different attack scenarios and integration with external tools. For example, exploitation tools like MedSploit, Core Impact, et cetera. Also it will be interesting to take a look at how the encryption works and have some coverage for the tools for encrypted traffic. There are different settings that you can apply in the application server and TR1s that does not provide integrity for example. So it will be interesting to take a look at the encryption part of the protocol. So that's what Mali of the talk. So thank you all.