Finding vulnerabilities in Source Code

Although I am not a professional source code auditor, I am a hyperactive programmer and security researcher. The article is based on my own experiences and reading various vulnerability reports throughout my journey in information security. Hence it might have some flaws that I would love to know about in the comments. Having that said, let’s get started.

Low hanging fruits

There are few things that can lead to discovering vulnerabilities without actually reading all the code. I am listing a few such techniques that I have found to be useful.

Validating patches

If previous versions of source code are available, go through the changelog to see if the developer has fixed any security vulnerabilities. Investigate the patches one by one. Pick the patched version of source code and compare it will the vulnerable version to understand what caused the vulnerability and what the developer did to patch it. Drink a glass of water and see if the patch has fixed the vulnerability properly or not, try bypassing the patch if possible.

Third party dependencies

Given the vast amount of open source code available, usage of third party dependencies is fairly common. Developers often fail to update these dependencies making the software vulnerable. Check for any outdated dependencies.

Identifying external libraries is pretty straight forward especially when you have a package.json or a requirements.txt but you also need to look for copyright notices in the code. When developers borrow code from other projects, they leave the copyright notice intact. If you encounter borrowed code, check the original project for any reported bugs.

Hard-coded Credentials

Hard-coded credentials are more common than you think, check this out. Looking for hashes, API keys, usernames and passwords can be rewarding and it’s really easy to automate.

Endpoints, Parameters & Domains

If the software deals with the web, it will most likely have hard-coded hosts and URLs. HTTP parameters which are not meant to be known by average users can also be found by inspecting the source code. This information can be used as per the context.

Finding Vulnerabilities

Auditing a huge code base is a tedious task and requires programming as well as field knowledge. However, there are tons of both paid and free software that can scan for security issues if you lack any of these two prerequisites. I recommend using one even if you intend to audit the code manually as it can point out a good amount of issues quickly.

Understanding the software

Don’t see the software as a vast ocean of code, it will only make the process boring, tiring and less effective. Use the software, see what options and features it has to offer and appreciate the developers for making it open source. The code will make more sense while reviewing if you do so.

It also helps gives an idea about what to look for. For example, a markdown editor is presumably more susceptible to DOS (caused by recursion) and XSS than other vulnerabilities given the set of actions it performs.

Following user controlled variables

Identify a user controlled variable and follow it throughout the code to understand its role. Analyze the associated functionalities and if they can be exploited in any way by modifying the value of the variable.

Identifying high risk methods

Some functions/methods/whatever pose security risks when supplied user controlled data. For example, if you see os.system in Python or exec in PHP, check if it using any user controlled variable. If it does, arbitrary system commands can be executed using it. This is exactly the opposite of following user controlled variables methodology.

Comments

Developers use comments to document the code, disable specific parts of the code or just flag things. Flags such as TODO or FIXME can be interesting sometimes as they indicated unfinished functionalities which can be taken advantage of by an attacker. Disable code snippets can contain interesting information that might be useful according the context.

Programming gotchas

Off by one errors, flawed logic, incorrect comparison operators etc. are some common mistakes that can be exploited. Ability to notice such flaws comes with experience and knowledge of the programming language in use.

Everything else

Does the program transfers sensitive data without encryption?
Is the encryption method susceptible to any attacks?
If the program uses random strings, are they random enough?
and so on…

I don’t recommend a check list, check lists are for people who are trying to get something done. Vulnerability testing should be context based.

That’s all for now. I hope you learned a thing or two from this article. Feel free to suggest edits to the article in the comments.

Have a nice day, stay hydrated!