The document summarizes a manual code review session where attendees analyzed vulnerabilities in insecure application source code. The session involved multiple challenges where attendees had to find vulnerabilities like intercepting HTTP traffic, error code disclosure, sensitive data exposure, password hash cracking, XSS filtering bypass, insecure redirects, log injection, privilege escalation via cookie tampering, and lack of CSRF protection. The document outlines solutions and observations for each challenge that demonstrate vulnerabilities in technologies like JSP, Log4j, password hashing, and lack of defenses like input validation, access control, and TLS.

1. 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.
HTML 4, JAVASCRIPT, JSP, LOG4J, some struts concepts, SQL.
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?
Solution:
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.

2. One more basic thing to observe here error-code redirection.
Error Handling
 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
Challenge 3:
I have a copy of the database and a pastebin account. Can I paste clear text passwords and earn
some street cred?
Solution:
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.

3. Challenge 4:
Me: Hi, My name is Hacker, May I come in?
You: NO
Me: Hi, my name is May I come in ?
You: Sure
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.

4. It is also observed that developer is trying to replace scripts with empty strings to sanitize, which is a
bad idea.
Hint: -> alalertert -> alert
Challenge 5
Insecure redirect
InsecureRedirect.jsp
Insecure log management
In Crypt.Java

5. Observations:
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
tracks”)
Data Flow
To find issuses such as log injection, important to learn how Data Flows.
Trust Zones
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
Challenge 6
Privilege Escalation
CSRF
Cookie-injection

6.  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:
Reflection vulnerability
MD5 AND SHA1 COLLISONS
BCRYPT SCRYPT
SECURITY REVIEW FINDBUG
Dataflow analysis
Threat Modeling