- OWASP Top 10:
- DVWA (Damn Vulnerable Web App): https://github.com/ethicalhack3r/DVWA
- Kali Linux: https://www.kali.org/
- Wireshark: https://www.wireshark.org/
- Brute force calculator: https://www.grc.com/haystack.htm
- Check if you have been pwned: https://haveibeenpwned.com/ 😄
- A nice read: https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
- How public encryption works (the RSA algorithm): https://www.youtube.com/watch?v=wXB-V_Keiu8
- Practice:
- Everything demonstrated here is done by running DVWA locally using Docker via the following command:
docker run --rm -it -p 80:80 vulnerables/web-dvwa
- Check with ' first
- If that doesn't work --> ' or '1'='1
- See more here -> https://www.owasp.org/index.php/SQL_Injection
- Hydra hacking:
- hydra 127.0.0.1 -l admin -P /usr/share/wordlists/rockyou.txt http-get-form "/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security=low;PHPSESSID=rl6f1f7pjp9kpnh8e6sbe0t361"
- Replace the SESSIONID with the one you get in the response headers when you access the page (Use the browser console to find it)
- More about this here: https://medium.com/@dannybeton/dvwa-brute-force-tutorial-low-security-463880d53e50
- Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.
- Enter the following into the input box and you will see the contents of the server's root directory: `127.0.0.1; ls /`
- SELinux kinda counters this if you are sandboxing the application. That's why it is important to have SELinux enabled in a production environment
- File Inclusion is commonly found in poorly written PHP code, but can be seen for other languages as well. It allows an attacker to include a local or remote PHP file into the webservers running PHP code. The exploitation of this vulnerability depends on PHP versions and web server configurations.
- Click on any of the listed links. Notice the URL path? Let's change it:
- http://localhost/vulnerabilities/fi/?page=../../phpinfo.php
- http://localhost/vulnerabilities/fi/?page=../../../../../bin/sh
- http://localhost/vulnerabilities/fi/?page=../../robots.txt
- This attack causes the victim’s session ID to be sent to the
attacker’s website, allowing the attacker to hijack the user’s
current session.
- To achieve this, type any javascript tag into the input forms of the XXS vulnerable website (DVWA --> XSS Reflected for example). You can use this as a test: `<script>alert(1);</script>`
- Note: Attackers can use XSS to defeat any automated CrossSite Request Forgery ( CSRF) defense the application might
employ
- PHP Info. Make sure you block access to it in production!
- HTTP is BAD!
- Wireshark:
- Select your interface and, while recording, do a request to a login form on an unsecure/HTTP website. (DVWA works)
- Filter: tcp.port == 80 || udp.port == 80
- Endpoint should be: POST /login
- Plain text passowrds
- Checklist:
• Is any data transmitted in clear text? This concerns protocols
such as HTTP, SMTP, and FTP. External internet traffic is
especially dangerous. Verify all internal traffic e.g. betweenw
load balancers, web servers, or back-end systems.
• Is sensitive data stored in clear text, including backups?
• Are any old or weak cryptographic algorithms used either by
default or in older code?
• Are default crypto keys in use, weak crypto keys generated or
re-used, or is proper key management or rotation missing?
• Is encryption not enforced, e.g. are any user agent (browser)
security directives or headers missing?
• Does the user agent (e.g. app, mail client) not verify if the
received server certificate is valid?
- Attacks on application platform
Upload .jsp file into web tree - jsp code executed as the web user
Upload .gif file to be resized - image library flaw exploited
Upload huge files - file space denial of service
Upload file using malicious path or name - overwrite a critical file
Upload file containing personal data - other users access it
Upload file containing "tags" - tags get executed as part of being "included" in a web page
Upload .rar file to be scanned by antivirus - command executed on a server running the vulnerable antivirus software
- Attacks on other systems
Upload .exe file into web tree - victims download trojaned executable
Upload virus infected file - victims' machines infected
Upload .html file containing script - victim experiences Cross-site Scripting (XSS)
Upload .jpg file containing a Flash object - victim experiences Cross-site Content Hijacking.
Upload .rar file to be scanned by antivirus - command executed on a client running the vulnerable antivirus software
- Generate MD5 hashes and store them in a file:
echo -n "Password1" | md5sum | tr -d " -" >> hashes
echo -n "HELLO" | md5sum | tr -d " -" >> hashes
echo -n "MYSECRET" | md5sum | tr -d " -" >> hashes
echo -n "Test1234" | md5sum | tr -d " -" >> hashes
echo -n "P455w0rd" | md5sum | tr -d " -" >> hashes
echo -n "GuessMe3" | md5sum | tr -d " -" >> hashes
echo -n "S3CuReP455Word" | md5sum | tr -d " -" >> hashes
echo -n "HighlyUnlik3lyToB3Cr4ck3d…" | md5sum | tr -d " -" >> hashes
- Use hashcat to crack them:
hashcat --force --show –m 0 hashes /usr/share/wordlists/rockyou.txt
So, MD5 is next to useless:
Salted hashes:
- Storing passwords in plain text
- (Spring Security related): Opening all endpoints, then closing them. Don't do this ever!
- Using NPM libraries which come from unknown sources without quadruple checking their source code (https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5)
- Using docker images from unknown sources
- Not version-locking docker images or npm/maven libraries!
- Using outdated technologies. Security flaws are always discovered and fixed. The older the tech, the more vulnerable it is.
- 2FA is golden!
- Don't use DEFAULT passwords!
- Consequences:
- the average cost of a data breach is $3.86 million with an average cost of $148 per lost or stolen record.
- Equifax: $243.2 million
- Uber: 57 million records - $148 million
- Yahoo: 3 billion records - $350 million
- Target (GDPR only) - 40 million records - $252 million + 4% global anual turnover due to GDPR infringements
- Under GDPR, de affected ppl NEED to be notified of the breach within 72 hours.
- A GDPR breach, no matter how big, is payed with $25 million or 4% of the global anual turnover
- Let's just say, you don't want that happening to your app.
- Leaks happen extremely frequently
- Credit cards, emails, passwords
- All are sold in the millions on the deep web.
- Credit cards, emails, passwords
- Best thing is to use a random generated 20+ chars password for each site. --> LastPass | 1Password | Dashlane.
- If you want to be extremely sure, deploy KeePass or Bitwarden (https://bitwarden.com/) locally local vault.
- You can use a Raspberry pi @home to store the vault and access it anywhere by connecting to your home IP.
- Make sure your security is tight and you back it up regularly.
- You can use a Raspberry pi @home to store the vault and access it anywhere by connecting to your home IP.
- If you want to be extremely sure, deploy KeePass or Bitwarden (https://bitwarden.com/) locally local vault.
- Your main credit card should be OFFLINE!
- Create a secondary credit card and use that for online purchases only. Top it up when needed, then pay. Never hold more than you afford to lose on it for extended periods of time.