A badly written recap on COMP6443
Over the past semester, I completed a course on web application security. This was the second time that COMP6443 had been run at UNSW CSE… things did eventually get sorted out by the end - one of the best things about new courses is the enthusiasm and effort on the part of the teaching staff! The lecturers - similarly to COMP9447 - have a unique industry perspective on current issues which you don’t really get from your typical academic lecturers.
Overall I felt this course was worhwhile - I can say that I enjoyed the wargame challenges (at least for myself :P) Most of these infosec topics I probably would have never endeavored to learn on my own. The infosec community and landscape is one of utmost dedication.
Unlike COMP9447, I’ve decided to braindump before I forget things.
If you have an interest but no experience in infosec, I’d recommend you this course as a nice entry point. General comp sci skills are definitely required, but zero ‘hacking’ skills.
Recap: (“Richard talk”) The hacker mindset
- Defend by learning how to attack. Think like an attacker.
- Challenge assumptions. Including yours. People make mistakes.
- Persistence. Hackers don’t stop, and neither should you!
- Be ethical. There are serious legal implications if you cross the line - even if accidental.
Also see COMP6441 / COMP9447 content. It’s all part of an expanded universe…
- Set yourself up for success with good infrastructure, automate all things possible, and build your own tools/workflows if it helps. The most successful bug bounty hunters do this, and you can bet its the same for the Hackers.
- Get a VPS (or Droplet or EC2 or whatever) on the cloud, where the networks speeds are fast - do your heavy network tasks here. Get it set up with a free domain name, e.g. from freenom, and keep it short for use in your payloads. If you’ve never done this before, it’s not difficult and there’s plenty of good guides out there.
how to remember ln -s LINK TARGET
ln -s access.log /var/log/nginx/access.log ln -s error.log /var/log/nginx/error.log
Example VPS setup
ls ~/exam wordlists take about 5G+ of disk space
There are kids making a fortune on bug bounties. Okay, maybe not kids (or… maybe?)
The first step for any successful pentest is to recon for targets. Figure out what bits are out there exposed on the internet. In the case of web apps, this starts with discovering subdomains, URL resources and API endpoints.
Here’s some tools:
Note: There are new tools being released all the time, some which may be faster and better. Below are just some which I’ve used.
Subdomain discovery - altdns - use this to generate permuted wordlists. Do not use for resolving - its quite slow. Then …. in c++
Pro-tip #1: Python for network fuzzing requests is extremely s l o w. (Turns out that for subdomain recon, you need rather speedy DNS resolvers.) - subbrute - altdns - dirsearch - amass - massdns - dnscan - http://crt.sh/ - dnsdumpster - google dorks - reverse ip yougetsignal.com
Site asset discovery - Burp suite has a site spider - Dirbuster, etc.
Get a good wordlist - Permute on valid subdomains you discover
- Is session management implemented properly? Check cookies
- Misconfigured JWT
- CyberChef is a nice tool for testing various encodings/decodings
poorley configured xml parsers. OWASP top 10 e.g. RSS
Chain to an external XML (attacker.com/2.xml)
Put rest of payload in attacker.com/2.xml - avoids being filtered out.
' -- -
- Discover the injection point
- Figure out what the DBMS is
- Guess what the backend SQL query is
- Iterate (the hard bit)
- Gather column/table info
Handy reference: https://sqlwiki.netspi.com/attackQueries/informationGathering/#mysql
It can be helpful to try model the database as you work: sqlfiddle.com
S3 bucket takeover metadata service
- Meetups like SecTalks
- Public bug bounty reports, blog posts and writeups
Infosec seems to be largely picking up on topics yourself, and then spending hours trying it out.