Recently I have been involved in a number of 360 (Code review and Pen testing) technical security assessments.
The time was short and code base big; Out come the static analysis and fault injection tools. (”This should help us get ahead of the curve” – or so I thought!)
The systems were critical financial systems developed by a well known integrator so one would think, “this is going to be good quality“.
So as an initial step in terms of execution once I have established context is to throw the tools at it.
Fault injection tool: A tool which is a market leader. The tool couldn’t even crawl the site. For some strange reason which still bemuses me it could not see responses from the application.
Verdict: No use, We even pointed some verified XSS vulnerable links to it but it simply did not see the issues, funny that eh?
So we took the manual assessment approach which yielded some interesting results……
Onto the code review: Yes another commercial tool was used, yes it found lots of “stuff” but none I could say posed significant risk to the business (lots of issues to fix but no high risk issues).
Actually,Surprise surprise, this code was some of the worst garbage I have ever reviewed in the last 6 years!!. It was so bad with so many layers of linkage the tool initially decided not to even review portions of the code! (But to know this the error log was required to be reviewed – Good to know, i suppose given that this is a code review!!)
So what next:
Lets look at the the application in the manual sense, code review, line by line, transactional analysis, data flows, error handling etc…..
“Oh look” no authorization on any client request, so what can I do here??
First of all, a code review tool can’t comment on code that does not exist. The best way to fool a code review tool is not to have any code to review.
So, back to authorisation:
Lets transfer funds to an arbitrary account, seen as there does not seem to be any authorization, say €100,000,000.
Oh Look that worked!! and it also reconciled on the bank balances!!!
So now we have established the potential for massive fraud by altering the TO and FROM account Numbers.
The issue here is that the vulnerability is lack of logic reflecting business requirements. Technical issues such as XSS, SQLI, CSRF, SSI etc can be found by tools via signature/response but circumvention of business logic produces no apparent vulnerability signature for which tools can detect. – This is an important point to consider.
So even with an automated 360 review (code review and app pen test) such tools can not discover fundamental flaws in the systems logic which take no skill to exploit. – Still requires mushy human grey matter
