Code audits are an exercise that is often not appreciated by pentesters or auditors… But why?
Code audits are an exercise that is often not appreciated by pentesters or auditors. Indeed, why try to understand the code of an application when it is much easier to directly perform attacks on it? These audits actually allow a pentester to get a much deeper view of the test scope and therefore provide more relevant work.
My beginnings in the world of security
I did my first code audit long before joining Advens in 2013 at the very beginning of my professional life. At that time, my job was to assess the resistance of smart cards, for example bank cards, for certain types of attacks.
The tests carried out on these maps are unfortunately a little too complicated to explain in a few lines, and are not the subject that interests us here. But to summarize in a very simplified way, a card contains data that is secret and must remain so if we want to avoid fraud. The purpose of the attacks was then to try to find this data using oscilloscopes, and various tools that it is not necessary to explain here.
What is nevertheless important to mention is that the attacks carried out required hours of analysis, preparation, and days of testing to hope to find at least a small part of this coveted secret data. But most importantly, the bottom line here is that poor preparation could lead to negative results even if the target was vulnerable.
But then, how could we know if the test perimeter was indeed robust, or if our preparation was simply not adequate?
Well, an audit was systematically carried out on the source code of the application installed on the board, before the tests. Thus, code-related vulnerabilities were known to analysts, and even if the results of attacks depended on other parameters, this made it possible to better prepare them.
My first code audit
To be honest, this first audit was for me a source of extreme apprehension. Indeed, I could not see how to understand the code that a person had spent months, years to implement, in a few days and moreover find defects.
And to complicate things, the code was in assembler. For those who are not familiar with the assembler, I can only tell you that you are lucky. Auditing code in unfamiliar language can already be a difficult exercise, but auditing code in assembler is a whole other problem if you’re not used to it.
Fortunately I was accompanied by a more experienced person during this audit, and the code was well commented. The client was more honest when explaining and understanding, which ultimately made the analysis surmountable.
Despite the success of this mission, apprehension and fear of not being able to understand the code or not finding vulnerabilities remained for a while. But by performing this type of exercise, I realized that there were many similarities between the different codes, and after a few years of experience, the exercise became more and more simple.
Lessons learned from these first audits
In truth, even if the attacks carried out on smart cards are very different from a penetration test on a more conventional application, or another perimeter, the state of mind is exactly the same. The ultimate goal is to find vulnerabilities that an attacker could exploit in order to be able to strengthen security on the targeted perimeter.
As mentioned earlier, the attacks carried out as part of the smart card assessments require a significant amount of preparation time, with much of it spent trying to get the best possible signal on the oscilloscope and finding the area where the target is located. In reality, without knowledge of the code, this essential step in test preparation is almost impossible. It is indeed complicated to try to target a very small theoretically vulnerable area without understanding what is displayed on the oscilloscope.
Today, thanks to these code audits carried out in a previous life, I can see a parallel between this extremely sensitive preparation and dependent on a thorough knowledge of the code, with some of the attacks that one regularly carries out as a pentester.
Why audit the code of a web application
Let’s take the example of a web application. At first glance, unlike smart cards, it is very easy to understand what you have in front of you when you start a test. Everyone has already browsed a website, everything is normally done so that the user can easily understand what he can perform as an action on it. A pentester will therefore theoretically have no difficulty in exploring the targeted site and defining the possibilities of attacks.
Yes, but the success of some attacks depends heavily on how the applications are encoded. Depending on the language used, the functions favored by the developers, the same attack may not work, or on the contrary, allow the pentester to obtain full access to the confidential data manipulated by the application.
Without knowledge of the code, the pentester will be able to launch generic attacks, or attempt different actions specific to several different languages or functions, and get results from time to time. Because it is true that penetration tests alone, not being by definition exhaustive, sometimes make it possible to find critical vulnerabilities on a website, this is not questionable. But test results can be more relevant when they are accompanied by a code audit.
In the same way that these audits allowed me to interpret what I was observing on the oscilloscope, as part of the smart card evaluation, they help the pentester understand what he has in front of him, not just the visible part of the website, but the whole mechanism behind it. Thus, it will be able to provide much more comprehensive work by targeting more precisely the truly vulnerable areas.
But pentesters are not the only ones to benefit from carrying out these two types of missions jointly. Indeed, auditors can also gain confidence in understanding the code, which is an essential step in order to be able to find relevant vulnerabilities in the application context. Also, the ability to check if a vulnerability is really exploitable, under real conditions, makes it possible to better judge the level of criticality of the flaw and thus to adapt the recommendations made to customers.
In addition, the technical knowledge that code audits bring to those who perform them is significant. It is also extremely rewarding to be able to look behind the scenes, to learn how the applications that can be used in everyday life really work.
Even if code audits are not attractive at first glance, the benefits of performing such audits in conjunction with penetration testing are real for both auditors and pentesters. This comprehensive approach is particularly interesting for critical perimeters, exposed on the internet and handling sensitive data. These audits make it possible to better support customers in their efforts to secure their applications, by submitting relevant results that take into account the entire context of the application.
