The third edition of the two-day PWNing Conference proves that there is a constant battle between hackers and security experts. It’s fought on the virtual battlefield but consequences are dire. Especially when it comes to open source; GitList, GitBucket and Gitea, which are open source alternatives for GitHub, are heavily compromised. Many companies rely on the open source products and if they have vulnerabilities, then the data is not secure.
Kacper Szurek from ESET brought up this issue. He discovered multiple vulnerabilities in GitList, GitBucket and Gitea. Kacper discovered that GitList is just using normal git client and passing arguments to its form values inputted by the user on the web page. Because of this he found that git grep accepts –open-files-in-pager parameter which executes any program specified by an attacker. That led to Remote Code Execution on GitList server. Next one in the queue was GitBucket. He also archived Remote Code Execution there, however this time exploitation was more complex. He first discovered Path Traversal attack on windows version of GitBucket, which allows him to upload any file onto the server. He used it to upload custom plugin for GitBucket server that was automatically installed and was able to execute any code on the server. The last issue was authentication – all the previous steps required from the attacker to have an active account on the server.
Kacper also analyzed an authentication mechanism in GitBucket and discovered that the server was using just 4 digits to encrypt the message. He wrote a simple tool to brute force the key and archived – full RCE without authentication on GitBucket. The last server that he attacked successfully was Gitea – a git server written in Go. He also was able to get Remote Code Execution without authentication. He discovered an issue in Large File System implementation of Gitea, which allows him to retrieve any file from the server. He was able to retrieve app.ini file which contains secrets used to encrypt access tokens. Having these secrets allowed him to create his own token and become an administrator of the server.
Lastly he used mechanism called git hooks to create a reverse shell to his computer and gain full access to the server. All 3 servers (GitList, GitBucket and Gitea) were fully compromised, which means that any organization that was using them might lose control over their code or services. Kacper also mentioned that GitHub (which is a closed source solution) has its own bug bounty program and all easy bugs were already fixed for it.
So even that code gets published for everyone to inspect – not always bugs do get fixed in the early stages of the project. Sometimes the researcher specialized in finding vulnerabilities has to inspect the code in order to find problems, which might be a problem in case of open source projects as they are not getting any external founding. Luckily recently Google started VRP (Vulnerability Reward Program), which allows security researchers to report bugs in common open source software and get some rewards from Google.
Next interesting panel was by Michał Sajdak from Securitum. He presented JWT vulnerabilities which were found in recent years. JWT is a common standard to create and exchange access tokens between client and application. This mechanism was created in 2015 and for the past three years, quite a few significant problems with it were found. Sometimes libraries allow to use a none encryption algorithm allowing to easily forge the token, some other well-known JWT library was allowing to attach attacker controlled key to do the encryption. .NET library wasn’t verifying the expiration date of the token. One library was allowed to attack the server using padding oracle vulnerability.
These errors were a direct result of a poorly written specification that was suggesting to implement „none encryption” algorithm. Together with not enough attention from the development side to create a secure library, it created a real threat. During the talk, the speaker showed that vulnerabilities were discovered in most of well-known and commonly used JWT libraries and there are hundreds of other JWT implementations that were created by less known organizations and people. Those less known libraries might still have plenty of security issues not discovered. At the end of the presentation Sajdak presented a better alternative for JWT called PASETO which hopefully will replace JWT in the near future.
Part of the conference was dedicated to improving penetration test results. **Paweł Krzywicki and Sebastian Dudek **from the Red Team have talked about red teaming. What exactly is it?
According to the SANS Institute, a cooperative research, education organization, training and security certification, red teaming is “the process of using tactics, techniques, and procedures (TTPs) to emulate real-world threats in order to train and measure the effectiveness of the people, processes, and technology used to defend environments. Built on the fundamentals of penetration testing, Red Teaming uses a comprehensive approach to gain an insight into an organization's overall security in order to test its ability to detect, respond to, and recover from an attack.”
To elaborate on that - they are using a variety of custom tools and known exploits from public databases and experience, but also physical and social techniques as long as they allow to access the required information.
How is Red Team different than penetration testing? They are usually given a specific task like obtaining a set of data. Unlike penetration testing, where the focus is on identifying as many attack vectors and vulnerabilities in software and systems, Red Team is more focused on controlled and stealth attack. Not getting caught is one of the most important things at the beginning. Once a vicious actor is detected, systems can trigger defenses or notify a defense team. Only after stealthy approach fails, they can act more loudly. So, they might for example use phishing technique to get login and password from an employee that is working at the company. Or tailgate an employee and use the fact that he is not locking his PC. Paweł Krzywicki in his talk was able to access one of the employees’ laptop. On it here was a source code of tested application. Having the code, he quickly identified potential vulnerability and was able to access the database. He underlined, that unlike pen testing, Red Team work is not finished when the exploit is detected and reported. The Red Team acts like a real attacker would on a production system but without data damaging techniques.
Another important topic was brought up by Paweł Krzywicki. A security of complicated architecture systems in big organizations is trending. With advancement of the software and more complex architecture that goes along with it, you have to integrate external systems and different architecture paths in order to keep up with demands. You naturally steer away from monolithic applications to microservices, to modern CQRS architectures. An immanent characteristic of the complicated architecture software is a focus on multiple paths related to a given attack vector.
For example, when testing an application with REST API some standard actions are performed:
To perform a full analysis of a given architecture path, you have to account for:
PWNing 2018 Conference was full of interesting keynotes; we can’t write in detail about all of them. What we can do though, is to give credit where credit is due. Gynvael Coldwind, who is the conference’s Chairman of the Program, prepared a brilliant edition. Can’t wait for the next year!