Last year has been filled with intense work for the entire Wallarm team. We have implemented our products for dozens of new clients and conducted information security audits for teams across the world. Our client companies range from newborn startups to huge corporations, which is how we were able to see lots of interesting practical data in the wild. We believe in making the research available to the community. We have a transparency policy, to publish as much research as we can to enrich the community and make everybody more secure.
Now at the very beginning of 2020, we want to go back to the #research we did in the previous year, review the materials, and highlight the articles that picked the public’s interest the most. So, here are the Wallarm blog most cited posts of 2019.
This article is our undisputed champion. It was quoted in dozens of publications all over the world.
Wallarm security researcher, Andrew Danau, stumbled upon an unusual #PHP script behavior while solving a #CTF task. When he sent %0a (newline) byte in the URL, the server response was unexpected. It returned more data than it should. And, the amount of extra data was related to the number of bytes after %0a inside the URL. Usually, that type of response is related to memory corruption attacks and we expected to see an information disclosure attack. Information disclosure is bad enough as it can result in leaking sensitive or financial data. Even worse, from time to time, although not frequently, such behavior can indicate a remote code execution vulnerability.
Andrew had not found the solution to the CTF game designer planned. His original thinking allowed him to find a new course, that leads to unforeseen, valuable discoveries. Following the trail from the unusual behavior, Andrew’s CTF fellow players, Emil and Omar, decided to drill down into the issue and exploit it. They were able to understand the reason for the unusual behavior, find an exploitation path, and make a relevant exploit to cause Remote Code Execution.
There are various tricks you can use to increase the likelihood of a successful race condition. Send multiple keep-alive requests in one, slowing down the webserver. Break the request into several parts and create a delay before sending it. Reduce the distance to the server and the number of abstractions to the network interface.
As a result of this analysis, together with Michail Badin, we developed the RacePWN tool. It can be integrated into other utilities (e.g., in Burp Suite), or you can create a web interface for managing races. Enjoy!
This post was the beginning of a series of articles on GraphQL, and it immediately attracted a lot of interest.
Wallarm’s partner, Vulners, shows at least 61 records related to GraphQL vulnerabilities in the Vulners aggregated threat intelligence feed. As always, the best way to protect anything is to apply secure coding practices, test for security issues before the application is released and limit the number of security issues in your code. At the same time, many parts of the application are not actually developed by your team and often are not under their control. To mitigate, you typically need an additional layer of application protection, that can work with GraphQL APIs, such as Wallarm Advanced Cloud-Native WAF.
The Wallarm engineering team did a good job this year working around these issues to create a system that avoids false positives and bypasses for GraphQL attacks. This article provides recommendations for configuration and best practices to keep GraphQL secure.
There are several issues facing the developer using #GraphQL when working on developing secure code. It’s mainly related to bypassing limits and abusing rates. In this post, we present a few examples Wallarm has encountered when analyzing how to protect GraphQL applications. There is a new attack surface when the app tech stack includes GraphQL. How can these apps be protected?
The first line of defense is secure coding. Our basic advice is to think about every public function you wrote as an Internet-faced #API endpoint. But sometimes it’s not enough, especially when we are talking about business logic issues, rate limits, and some other things such as Introspection query disabling. Our recommendations for protection from such #attacks are in the article.
When it comes to XXE issues, hackers have multiple ways to take advantage of WAF configurations. Here we are going to show you four ways hackers trick WAFs, sneaking #XXE issues past their defenses. In this article, we show you 4 ways hackers can fool a WAF and get XXE through.
- Extra spaces in the document
- Invalid format
- Exotic encodings
- Two types of encoding in one document
And, of course, recommendations on how you can stop XXE Attacks are included as well.
Surely, this is not even close to all the topics that we covered in our blog. Our researchers are constantly working on information security issues and in 2019 we published dozens of articles on this topic. Stay with us and let’s make the IT world safer together!
