Now we move further and we will prepare to make the real attack.
A transparent proxy for all the needs
A transparent proxy can be very useful when you’ve to check your browser interaction with the website to attack. Maybe we can discover some async call or how params are submitted and stuff like that.
For sure you can use your browser inspector funtion (if you’re using Apple Safari) or firebug to interact as a web developers does.
Creating a proxy with ruby and WEBrick is dramatically easy. You need just to extend the HTTPProxyServer class and you’re ready to go:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
In a private section I put business logic methods:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
I find it useful to trace all POSTs my browser make during navigation in order to inspect all values that can be tampered replying the submission…
As example the following trace showed my in a real world activity that browser make a double submission over the login page submitting a lot of different parameters, a cleartext password and some parameter like uuid suggesting some code managing user ids is in place.
This can be interesting since I want to digg deeper during the tests trying to make some privilege escalation attempt.
1 2 3 4 5
Check for backup files
You see it in TV movies. Detective looking into garbage to find informations against bad guys.
In IT security some principles are still valid; sometimes you can find backup files published on production servers full of useful informations like passwords, ip addresses, source code, …
Using anemone it’s easy to make some checks for backup files presence.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
In a real world attack we can go further behind this gentle approach computing the backup file url with brute force. However you must be careful about making bursts of requests or you’ll be busted by target web application firewall or perimetral defence appliances.
Make a deep and accurate recognition about a web application is a preliminary step for a successful security test.
It’s important that developers can make such tests not making assumptions about the code that they have wrote.
On a production server, you must publish only files needed by the application itself. No backups, no readme or other documentation, no too verbose config files must be on the server.
This is not “Security through obscurity”, this is the least privilege principle.
A lot of ruby hackers attended my #rubyday talk last 15th June. I prepared some very small demos for each piece of code or security tests I presented in order to make them aware about that the topics I was talking about do are real issues.
I performed well, after the talk I was very satisfied about the job done and this doesn’t happen too much often. I’m always very critical about myself as speaker, but this time not.
People liked it and it was the most upvoted talk for the conf.
The message they gave as a feedback is strong and clear:
- security do is a concern for us
- we don’t know how to make good security
- please help developers
I can’t wait more for other developer’s conferences…