cshark_blog_PWNing-Conference
10/12/2018

PWNing 2018 Conference – The Future of Enterprise Safety

Table of contents:

    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 open-source products and if they have vulnerabilities, then the data is not secure.

    GitList, GitBucket and Gitea

    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 –an 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 a 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.

    JWT vulnerabilities

    Next interesting panel at PWNing Conference was performed 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 allowed to attach the attacker-controlled key to do the encryption. The .NET library wasn’t verifying the expiration date of the token. One library was allowed to attack the server using padding oracle vulnerability.

    cshark_blog_PWNing-Conference_in-text-1

    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 PWNing 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?

    Red teaming

    According to the SANS Institute, 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, the 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 defences or notify a defence team. Only after the stealthy approach fails, they can act more loudly. So, they might, for example, use a 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 a 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.

    Security of complicated architecture

    Another important topic during the PWNing Conference was brought up by Paweł Krzywicki. Security of complicated architecture systems in big organizations is trending. With the advancement of the software products and the 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:

    • Checking if an application does not show the attack vectors. That includes checking the URL address and the structure of parameters used by a given service
    • Determination of non-standard parameters of inductions and exploitation efforts, with fuzzing for example
    • Checking the mechanisms of authentication, alongside with session management, with customized security tokens

    To perform a full analysis of a given architecture path, you have to account for:

    • Possible attack vectors
    • Common features of architecture paths, alongside with different components that make for an integral part of the system and can directly or indirectly communicate with a fragment of the path
    • Common elements that can act as proxy nodes for attacks
    • A simulated attack through external node
    • Assess if the architecture path stopped the attack

    PWNing 2018 Conference was full of interesting keynotes. 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.

    cshark_people-dawid-trznadel
    Dawid Trznadel
    A Tech Lead at CSHARK. Passionate about web application security and secure design.