SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Manual Code Review- Null Bachaav
Hi Security geeks, This is santosh from Null Chennai.
I would like to share my experience and learning what I had at Null Bachaav Session at Banglore. This
session was delivered by Sandesh.
The entire session structure was a bit different. Generally, we used to have some learning and then
crack some stuff. But in this bachaav session, it was bit different and more interesting. We right
away started digging into finding vulnerabilities. We were provided with a deliberately developed
insecure application source code, which has got multiple basic level vulnerabilities.
This is very much ideal for beginners, who wanted to start manual source code review. Pre-requisite
for this session as stated earlier is Eclipse JEE version. The application is developed using JSP. The
primary thing what we did is, understanding the technological aspects involved in the application.
By looking at the structure and configuration files of the application, we could able to understand
that the following technologies have been used to design this vulnerable application.
The most important thing in source code review is to always begin with web.xml file, which will give
the entire structure of the application and its data flow. There were many challenges designed to be
cracked in a regular CTF fashion.
Let’s look at the way we cracked things.
Challenge 1: Attacker can able to find what Mr. X is doing, why?
In web.xml Transport-guarantee is set to NONE – which says the entire traffic flows in HTTP channel.
As http is a clear text protocol, attacker can intercept the entire traffic locally.
One more basic thing to observe here error-code redirection.
More number of error codes should be enabled and redirected to customized error.jsp page
to stop disclosing stack trace.
Challenge 2: Find interesting things in the code
Solution: After searching for sensitive key words like passwords,pwd, encrypt, decrypt, hash and
security could able to arrive at a line, where there are two sensitive comments in main.jsp
Interesting part here is first comment line is part of jsp code, it would not be displayed to end user.
But the next one is a html comment, which will be displayed in client side source
I have a copy of the database and a pastebin account. Can I paste clear text passwords and earn
some street cred?
In Crypto.java it is observed that there is no salting has been implemented, the encrypted hashes
can be cracked by using rainbow tables or pre-calculated hashes.
Me: Hi, My name is Hacker, May I come in?
Me: Hi, my name is May I come in ?
Solution: It is very clear that the hint is speaking about bypassing filters, so started looking at
validations. At one point observed that the XSS filters were designed to protect against basic key
words like <Script>,alert,onerror(), java script and vbscript etc. Attackers can use different keywords
like onMouseOver(),onLoad() and bypass those filters. Whitelisting is the best practice when
compared with blacklisting approach.
It is also observed that developer is trying to replace scripts with empty strings to sanitize, which is a
Hint: -> alalertert -> alert
Insecure log management
Plaintext is logged in LOG. Logs can be manipulated by writing “santosh logged at 4:30”
Logs can be manipulated by injecting EOF character into logs. (Injecting logs helps in covering
To find issuses such as log injection, important to learn how Data Flows.
Source- a place where taint enters in
Taint - Data which is coming from outside of the application givien by user
Taint Propagator – a function which carries taint
Sink – a place where taint comes back and executes and creates a vulnerability
Observations: In the above code snippet, it is observed that there is a hidden parameter for
userid, which can be intercepted and modified for performing Privilege Escalation.
Application is reading userid information from cookie, attackers can tamper cookies and
perform privilege escalation
Entire form is getting submitted without CSRF protection.
Other keywords at the end of discussion:
MD5 AND SHA1 COLLISONS
SECURITY REVIEW FINDBUG