Victory on PHDays 9. We share life hacking in three parts. Part 1
Hello! My name is Vitaly Malkin. I am the head of the security analysis department of Informzaschita and part-time captain of the True0xA3 team. In this article we begin a cycle of 3 materials dedicated to our performance at the PHDays IX Standoff. In this article, we will explain why competent preparation is half the success, why it is so important to gather “fruits” in time and how to organize the interaction of the pentest-team within one single project.
TL; DR article contains a huge number of anglicisms and complex technical terms, for which I apologize separately.
We had 16 selected pentesters, 4 trainees, 6 servers, our own CUDA station and a huge desire to win.
We started the active preparation phase 8 days before the start of StandOff. This was our 3rd attempt as an attacker, and many of us already had enough experience to understand what to look for this year. We saw 5 priority areas for study:
')
Let's try to parse these items in order.
It is easiest for me to talk about this item, because I was the overall decision responsible for its implementation. During StandOff, the most frequent problem for newbies, in my opinion, is poor coordination. Team members decide the same task, there is no clear understanding of what they have already seen and what has not. The obtained information on tasku is not transmitted to each other, as a result, the efficiency of work falls sharply. And the more participants there are, the more the efficiency decreases. Moreover, it is very useful to have a person who understands the overall infrastructure well and can link individual vulnerabilities into a full-fledged attack vector.
This year Discord platform was chosen for team interaction. In general, it is very similar to the good old IRC chat with additional features like file-upload-a and voice communication. We took a description of all the objects from the Agend competitions and created a channel for each of them, in which we placed information. Thus, any person who connected to the task could see everything they’ve dug before, including the results of running various tools and manual surveys. A limit of one message per minute was set on all info-channels in order to prevent flooding. And the whole discussion was conducted in separate chats, which were also created for each object.
A number of organizational decisions were also taken to improve coordination. In general, in our team it is not customary to set tasks with the wording “NADO”. We try to discuss why a particular task has been set, what its implementation will lead to, as well as how to accomplish it more effectively. But within the framework of StandOff-a, such a model can lead to unnecessary altercations, so we decided to entrust the coordinator with full authority over the process. For 28 hours of competition, his decisions were practically not discussed, which certainly saved us a lot of time. Although it may have affected the quality of communications. In addition to this, we decided to very clearly delineate the areas of responsibility: in spite of the fact that some of the team members did not get the most exciting tasks.
In my opinion, the main secret of our success were: a huge daily project experience and the correct prioritization of tasks. Last year, we were able to seize the whole office and hold it for the whole game simply due to quickly cracked simple vulnerabilities. This year we approached the problem centrally and made a list of such vulnerabilities.
ms17-010; ms08-67; SMBCRY; LibSSH RCE; HP DATA Protectoer; HP iLo; ipmi; Cisco Smart Install; Java RMI; JDWP; JBOSS; drupalgeddon2; weblogic; heartbleed; shellshock; ibm websphere; iis-webdav; rservices; vnc; ftp-anon; NFS; smb-null; Tomcat
Next, two checker and penetrator services were written, which, in automated mode, using public exploits and metasploit, first checked for vulnerabilities, and then tried to exploit them. At the entrance, the utility accepted the nmap report, which ultimately accelerated the process.
We most often do projects for banks and other financial organizations. SCADA systems, if they meet, are more likely in the style: “If you were able to get network access to a scud, fix it and read it as one of the project’s success criteria.” Therefore, we do not have a good applied experience in analyzing the security of an automated process control system. This in turn led to the fact that a week before StandOff, we urgently sat down to study typical vulnerabilities. With IoT and GSM, the situation is even worse: if IoT is sometimes found in projects, we have only seen GSM on previous StandOffs.
Thus, during the preparation, we singled out two separate people for the process control system, and another two on GSM and IoT. During the preparatory week, the 1st group wrote out typical approaches to the Pentest of SCADA-systems, and also studied in detail the video dedicated to the last-year infrastructure of the industrial control system. Also, the guys pumped out about 200 GB of various HMI, drivers, and other software that is directly related to the controllers. As for GSM and IoT-a, then we prepared several pieces of iron, read all the available articles on GSM and hoped that this would be enough. (SPOILER: Actually, no!)
Realizing that our team this year will be quite large, we immediately decided that we needed additional equipment. Next will be a list of proposals that we have collected within the team, with a “+” marked that we eventually took:
- coffee machine;
+ - CUDA server (they didn’t take it with them, but used it);
+ spare laptop;
+ WI-FI router;
+ managed switch;
+ network cables of various lengths (20 pcs);
+ pilot (3 pieces);
+ Wi-fi Alfa (3 pieces);
+ rubber-duck (2 pieces);
- proxmark;
- camera.
As for infrastructure, this is a separate song. Already last year, we realized how useful it was to use a CUDA station, hacking several handjacks, so there was no doubt about the need for its use. It is important that this year, as well as in the past, all the attackers were behind the NAT, which generally denied the possibility of reverse connections from the DMZ. But absolutely all the hosts had to have access to the Internet, except for the nodes of the automated process control system. In this regard, we have decided to raise three server listener-a, available from the Internet. We also used our own OpenVpn server with client-to-client mode enabled for ease of pivoting and pinning. Unfortunately, it is impossible to automate the process of connecting the gateway, so about 12 hours out of 28 one of the team members worked on working with gateways.
Our past experience of performing at StandOff has very clearly shown that it is not enough to successfully hack the server: it is important not to let others gain a foothold on it. Therefore, sufficient attention was paid to RATs with new signatures and scripts to strengthen the protection of Windows. RAT we used our standard, slightly changing the methods of obfuscation. With the rules it was a bit more complicated. In general, we have identified the following set of scripts:
For Linux, a special init-script was developed that closed all ports, opened SSH on a nonstandard port, and registered the command's public keys for access to SSH.
On May 17, 5 days before StandOff, a briefing was held for the attackers. In the course of it, a host of information surfaced that influenced our preparation.
First, the organizers published a map of the network, and this was a great help for us. We were able to divide the areas of responsibility in advance, update the network segments, and most importantly understand what the network is all the same. In my opinion, the most important statement that was made at the briefing was the phrase that the network of automated process control systems will be accessible only from one segment, and this segment will not be protected. Moreover, the most points will be given for the automated process control system and protected offices, and the organizers directly encourage the fight for networks between hackers.
We took this information like this: "Anyone who captures a bigbrogroup will most likely win the game." The fact is that our experience told us: whatever punishments the organizers would think up for a simple service, the defenders will drop vulnerable services if they cannot patch them. Indeed, it is much more terrible when it is announced from the scene of the largest information security conference that you have defeated hackers than if some game points are taken from you. Our theory was confirmed, but we will describe this in detail in the 2nd article.
As a result, we decided to divide the whole team into 4 parts:
1. Bigbrogroup. This was the task that gave us the highest priority. The team involved people who have the most experience hacking into the internal infrastructure of different customers. In total, this mini-team consisted of 5 people. Their goal was - as soon as possible to gain a foothold in the domain and cut off other teams from access to the automated process control system.
2. Wireless Network. The team, which was responsible for monitoring the Wi-Fi, tracked new points, intercepted handshakes and bruised them. Also, their tasks included GSM, but first of all it was necessary to still capture Wi-Fi and cut off other teams from it.
3. Unprotected networks. The team that spent the first four hours picking up all the unprotected networks for vulnerabilities. We understood that during these four hours nothing super important would happen in the protected segments, and if it does, the defenders will roll back. Therefore, they focused on what could change irreversibly. As it turned out - not in vain. Four hours later, the same group proceeded to the analysis of the protected segments.
4. Scanners group. The organizers directly stated that the networks will change, so we had two people who continuously scanned the network for changes. It was not so easy to automate, because for different networks, different settings were needed at different times. For example, in the first hour on the fe.phd network, nmap worked perfectly in T3 mode, and after 12 hours I barely worked in T1.
Another important vector for us was the list of software and technologies published by the organizers. For each of the technologies we tried to create our own competence center, which could very quickly help and see typical vulnerabilities.
For some services, we found very interesting vulnerabilities, but there were no public access exploits. So it was, for example, with Redis Post-exploitation RCE. We were confident that this vulnerability would appear in the gaming infrastructure, so we decided to write our own 1-day exploit. It was not possible to write 1-day specifically for this vulnerability, but in general we had about five non-public exploits in our hands that we were ready to use.
Unfortunately, we did not have time to share all the technologies, but it was not so bad. We covered the main set, and that was enough. There was also a list of controllers for automated process control systems, which we also disassembled and tried to prepare for it.
Preparing for the battle, we prepared several tools for an inconspicuous connection to the physical network of the automated process control system. For example, we implemented a cheap analogue of Pineapple with raspberry. The module was connected via Ethernet to the industrial network and via GSM to the control service. Then we could remotely configure the Ethernet connection and distribute it on site using the built-in Wi-Fi module. Unfortunately, at the briefing, the organizers made it clear that physically it is impossible to connect to the automated process control system, so we left this module until better times.
A lot of information was about the bank, offshore bank and the work of the antifraud. But having learned that there is not very much money in it, we decided not to prepare for this in advance, but to invent something along the way.
Summing up, we have done a fairly large amount of work in preparation. It is important to note that in addition to the obvious advantages in the form of a successful performance at StandOff, there were also not obvious ones.
Now, having described this all in the text, I understand that we didn’t accomplish anything as grand as it seemed before. In general, it seems to me that the main reason for the victory of our team was a properly organized preparation stage. And what directly happened during StandOff itself - I will tell in the second article of the cycle.
TL; DR article contains a huge number of anglicisms and complex technical terms, for which I apologize separately.
I. Input
We had 16 selected pentesters, 4 trainees, 6 servers, our own CUDA station and a huge desire to win.
We started the active preparation phase 8 days before the start of StandOff. This was our 3rd attempt as an attacker, and many of us already had enough experience to understand what to look for this year. We saw 5 priority areas for study:
')
- Effective coordination;
- Collect Low Hanging Fruits;
- Operation of vulnerabilities of non-standard (for us) technologies (industrial control system, IoT, GSM);
- Preparation of external infrastructure and equipment;
- Development add. persistence and hardening methods.
Let's try to parse these items in order.
1. Effective coordination
It is easiest for me to talk about this item, because I was the overall decision responsible for its implementation. During StandOff, the most frequent problem for newbies, in my opinion, is poor coordination. Team members decide the same task, there is no clear understanding of what they have already seen and what has not. The obtained information on tasku is not transmitted to each other, as a result, the efficiency of work falls sharply. And the more participants there are, the more the efficiency decreases. Moreover, it is very useful to have a person who understands the overall infrastructure well and can link individual vulnerabilities into a full-fledged attack vector.
This year Discord platform was chosen for team interaction. In general, it is very similar to the good old IRC chat with additional features like file-upload-a and voice communication. We took a description of all the objects from the Agend competitions and created a channel for each of them, in which we placed information. Thus, any person who connected to the task could see everything they’ve dug before, including the results of running various tools and manual surveys. A limit of one message per minute was set on all info-channels in order to prevent flooding. And the whole discussion was conducted in separate chats, which were also created for each object.
A number of organizational decisions were also taken to improve coordination. In general, in our team it is not customary to set tasks with the wording “NADO”. We try to discuss why a particular task has been set, what its implementation will lead to, as well as how to accomplish it more effectively. But within the framework of StandOff-a, such a model can lead to unnecessary altercations, so we decided to entrust the coordinator with full authority over the process. For 28 hours of competition, his decisions were practically not discussed, which certainly saved us a lot of time. Although it may have affected the quality of communications. In addition to this, we decided to very clearly delineate the areas of responsibility: in spite of the fact that some of the team members did not get the most exciting tasks.
2. Collect Low Hanging Fruits
In my opinion, the main secret of our success were: a huge daily project experience and the correct prioritization of tasks. Last year, we were able to seize the whole office and hold it for the whole game simply due to quickly cracked simple vulnerabilities. This year we approached the problem centrally and made a list of such vulnerabilities.
ms17-010; ms08-67; SMBCRY; LibSSH RCE; HP DATA Protectoer; HP iLo; ipmi; Cisco Smart Install; Java RMI; JDWP; JBOSS; drupalgeddon2; weblogic; heartbleed; shellshock; ibm websphere; iis-webdav; rservices; vnc; ftp-anon; NFS; smb-null; Tomcat
Next, two checker and penetrator services were written, which, in automated mode, using public exploits and metasploit, first checked for vulnerabilities, and then tried to exploit them. At the entrance, the utility accepted the nmap report, which ultimately accelerated the process.
3. Operation of non-standard (for us) technology vulnerabilities (industrial control system, IoT, GSM)
We most often do projects for banks and other financial organizations. SCADA systems, if they meet, are more likely in the style: “If you were able to get network access to a scud, fix it and read it as one of the project’s success criteria.” Therefore, we do not have a good applied experience in analyzing the security of an automated process control system. This in turn led to the fact that a week before StandOff, we urgently sat down to study typical vulnerabilities. With IoT and GSM, the situation is even worse: if IoT is sometimes found in projects, we have only seen GSM on previous StandOffs.
Thus, during the preparation, we singled out two separate people for the process control system, and another two on GSM and IoT. During the preparatory week, the 1st group wrote out typical approaches to the Pentest of SCADA-systems, and also studied in detail the video dedicated to the last-year infrastructure of the industrial control system. Also, the guys pumped out about 200 GB of various HMI, drivers, and other software that is directly related to the controllers. As for GSM and IoT-a, then we prepared several pieces of iron, read all the available articles on GSM and hoped that this would be enough. (SPOILER: Actually, no!)
4. Preparation of external infrastructure and equipment
Realizing that our team this year will be quite large, we immediately decided that we needed additional equipment. Next will be a list of proposals that we have collected within the team, with a “+” marked that we eventually took:
- coffee machine;
+ - CUDA server (they didn’t take it with them, but used it);
+ spare laptop;
+ WI-FI router;
+ managed switch;
+ network cables of various lengths (20 pcs);
+ pilot (3 pieces);
+ Wi-fi Alfa (3 pieces);
+ rubber-duck (2 pieces);
- proxmark;
- camera.
As for infrastructure, this is a separate song. Already last year, we realized how useful it was to use a CUDA station, hacking several handjacks, so there was no doubt about the need for its use. It is important that this year, as well as in the past, all the attackers were behind the NAT, which generally denied the possibility of reverse connections from the DMZ. But absolutely all the hosts had to have access to the Internet, except for the nodes of the automated process control system. In this regard, we have decided to raise three server listener-a, available from the Internet. We also used our own OpenVpn server with client-to-client mode enabled for ease of pivoting and pinning. Unfortunately, it is impossible to automate the process of connecting the gateway, so about 12 hours out of 28 one of the team members worked on working with gateways.
5. Development add. persistence and hardenin methods
Our past experience of performing at StandOff has very clearly shown that it is not enough to successfully hack the server: it is important not to let others gain a foothold on it. Therefore, sufficient attention was paid to RATs with new signatures and scripts to strengthen the protection of Windows. RAT we used our standard, slightly changing the methods of obfuscation. With the rules it was a bit more complicated. In general, we have identified the following set of scripts:
- close SMB and RPC;
- porting RDP to a non-standard port;
- Disable reversible encryption, guest-accounts and other settings from the security baseline.
For Linux, a special init-script was developed that closed all ports, opened SSH on a nonstandard port, and registered the command's public keys for access to SSH.
Ii. Briefing
On May 17, 5 days before StandOff, a briefing was held for the attackers. In the course of it, a host of information surfaced that influenced our preparation.
First, the organizers published a map of the network, and this was a great help for us. We were able to divide the areas of responsibility in advance, update the network segments, and most importantly understand what the network is all the same. In my opinion, the most important statement that was made at the briefing was the phrase that the network of automated process control systems will be accessible only from one segment, and this segment will not be protected. Moreover, the most points will be given for the automated process control system and protected offices, and the organizers directly encourage the fight for networks between hackers.
We took this information like this: "Anyone who captures a bigbrogroup will most likely win the game." The fact is that our experience told us: whatever punishments the organizers would think up for a simple service, the defenders will drop vulnerable services if they cannot patch them. Indeed, it is much more terrible when it is announced from the scene of the largest information security conference that you have defeated hackers than if some game points are taken from you. Our theory was confirmed, but we will describe this in detail in the 2nd article.
As a result, we decided to divide the whole team into 4 parts:
1. Bigbrogroup. This was the task that gave us the highest priority. The team involved people who have the most experience hacking into the internal infrastructure of different customers. In total, this mini-team consisted of 5 people. Their goal was - as soon as possible to gain a foothold in the domain and cut off other teams from access to the automated process control system.
2. Wireless Network. The team, which was responsible for monitoring the Wi-Fi, tracked new points, intercepted handshakes and bruised them. Also, their tasks included GSM, but first of all it was necessary to still capture Wi-Fi and cut off other teams from it.
3. Unprotected networks. The team that spent the first four hours picking up all the unprotected networks for vulnerabilities. We understood that during these four hours nothing super important would happen in the protected segments, and if it does, the defenders will roll back. Therefore, they focused on what could change irreversibly. As it turned out - not in vain. Four hours later, the same group proceeded to the analysis of the protected segments.
4. Scanners group. The organizers directly stated that the networks will change, so we had two people who continuously scanned the network for changes. It was not so easy to automate, because for different networks, different settings were needed at different times. For example, in the first hour on the fe.phd network, nmap worked perfectly in T3 mode, and after 12 hours I barely worked in T1.
Another important vector for us was the list of software and technologies published by the organizers. For each of the technologies we tried to create our own competence center, which could very quickly help and see typical vulnerabilities.
For some services, we found very interesting vulnerabilities, but there were no public access exploits. So it was, for example, with Redis Post-exploitation RCE. We were confident that this vulnerability would appear in the gaming infrastructure, so we decided to write our own 1-day exploit. It was not possible to write 1-day specifically for this vulnerability, but in general we had about five non-public exploits in our hands that we were ready to use.
Unfortunately, we did not have time to share all the technologies, but it was not so bad. We covered the main set, and that was enough. There was also a list of controllers for automated process control systems, which we also disassembled and tried to prepare for it.
Preparing for the battle, we prepared several tools for an inconspicuous connection to the physical network of the automated process control system. For example, we implemented a cheap analogue of Pineapple with raspberry. The module was connected via Ethernet to the industrial network and via GSM to the control service. Then we could remotely configure the Ethernet connection and distribute it on site using the built-in Wi-Fi module. Unfortunately, at the briefing, the organizers made it clear that physically it is impossible to connect to the automated process control system, so we left this module until better times.
A lot of information was about the bank, offshore bank and the work of the antifraud. But having learned that there is not very much money in it, we decided not to prepare for this in advance, but to invent something along the way.
Summing up, we have done a fairly large amount of work in preparation. It is important to note that in addition to the obvious advantages in the form of a successful performance at StandOff, there were also not obvious ones.
- Such training is a great way to get distracted and to do something that I have long wanted to try and search, and there was simply no time for project activities.
- We have no projects that involve the entire team as part of one task, so we have a good team building with a specific goal.
- Much of what we have done can be used in real projects, so that in addition to expanding competencies we also got ready-made tools.
Now, having described this all in the text, I understand that we didn’t accomplish anything as grand as it seemed before. In general, it seems to me that the main reason for the victory of our team was a properly organized preparation stage. And what directly happened during StandOff itself - I will tell in the second article of the cycle.
Source: https://habr.com/ru/post/453834/
All Articles