I have a codebase that needs a code review to evaluate it for backdoors.
The code is far too big to review it all, how would you recommend approaching the problem.
It is a java web application with an oracle database, the code is customized from a product that is exceedingly large.
The customizations cover almost all of the codebase, but I can identify the customised code automatically.
The bottom line: You are screwed. If you are concerned that one of the developers deliberately hid a backdoor in that codebase, you have no realistic hope of telling whether a backdoor is present. Life sucks.
Comment: Some folks here are suggesting you can check for a backdoor by reviewing the code, or using static analysis tools, or somesuch. Don't believe it. They are fooling themselves if they think that this is likely to detect a deliberately hidden backdoor. In my opinion, those answers are overly optimistic and are likely to give you a false sense of security. (I know I'm going to make myself unpopular by saying this and dissing other commentators, but I feel a responsibility to give you my honest, frank advice.)
Advice and mitigations: As for what you should do, I think you need to tell us more about the function of that piece of software, how it relates to your business, and what are the consequences if it does have a backdoor. Here are some generic mitigations you could consider, which might or might not be relevant to you, depending upon the circumstances:
Risk transfer. Require the supplier to provide a warranty that the code is free of backdoors, with major financial penalty clauses if any are found. (Note that, if a backdoor is present, the chances are finding it are pretty low, so the penalties if one is found have to be increased proportionally to the inverse of the probability of detecting it.)
Isolation. You could try to isolate the effect of a backdoor, so that it can only affect the functioning of this piece of software and has limited opportunity to attack other systems of yours. You could run it in a virtual machine, firewall it off from your networks, etc. You could potentially also firewall it off from the network, to make it harder for a bad guy to activate the backdoor.
Monitoring. In some cases, it may be possible to perform external monitoring to detect illicit activity. For instance, in a slot-machine joint, you could monitor the amount of money taken in, the amount paid out, and statistically, those two should bear a strong relationship; if you see pay-outs that exceed the expected amount by over five standard deviations, that might be a good reason to get concerned. As another example, at a bank, you may be able to use double-entry book-keeping and track some aggregate metrics, such as the rate of consumer complaints and how often consumers dispute charges. These kinds of monitoring techniques are highly specific to your particular business, but can potentially be effective at detecting shenanigans.
Keep in mind that none of these are likely to provide a really good defense against deliberate backdoors, and they may or may not be applicable in any particular situation, but if you're lucky, they might be better than nothing.
I would start with a structural overview - from a design perspective, are separate parts of code well defined? eg do you have validation code, input and output functions etc which are used for those purposes throughout the codebase, or is every function individual? Do you have code which is functionally safe (often certain style constructions do not impact the security of data flow)
If you have a security wrapper which carries out authentication for every function, you can possibly shortcut review of those functions and just check for usage of the wrapper function, for example.
If it is a very large codebase, then you will want to run a tool such as Fortify (or others that @AviD will be able to name :-) to make a first pass at the problem, but all tools suffer from a lack of context intelligence. They identify based on typical signatures, so you will get false posisives (and possibly false negatives - which is why having a good overview can help you identify risks a tool won't spot)
The idea is that the tool narrows down the possible risk areas and identifies the vast majority of issues, as tools are relatively cheap, then a human validates and adds to the tool's output, placing it into the context of the application environment.
At risk of sounding overly commercial I would advise using the services of an experienced security consultant who not only knows the code review tool inside out and is fluent in Java + Oracle, but also someone experienced in business and security risk based architecture.
@Rory pretty much covered how to go about doing the review...
I'll just add that you should know what you're looking for, and not just "backdoor" in general (similar to what @VP01 said in his comment on top).
E.g. are you looking for backdoors that do:
If you know what types of backdoors you're looking for, you don't have to concentrate equally on each of the millions of lines of code, and you can prioritize.
I'll also add that there are some automated tools that can be scripted very richly, such that it supports looking for those specific types of backdoors that you define, based on human intelligence and context, then applies that throughout the millions of LOC...
P.S. you might be interested in some of these related questions:
I think the answer from Rory touches the kernel, but the timing is really important here. To do the code review after that the code is already huge, badly documented, badly tested, in production (i don't know if that is the case here) is already almost "too late" to do it right. Even with the best tools and Java/Oracle external analysts will be harder to understand business logic flaws (intentionally planted there). In my opinion the code analysis since the beginning is the way to go.
There are some methods that are common to every application review, regardless of language is used. Here are some tips:
