Hacking Web Apps Brent White

Hacking Web Apps

Sr. Security Consultantat Solutionary

Twitter:

@brentwdesign

Brent White-----------------------------------

www.solutionary.com

Disclosure Statement (Dis – closure?)

The content within this presentation represents the opinions and thoughts of the presenter(s) and in no way represent the thoughts or opinions of Solutionary, NTT,

NTT Com Security, or any of NTT’s subsidiaries.

=== INTRO ===

•  High-level, from start to finish of what we do during assessments

•  We’re telling you how to get started & pro-tips to save you time and heartache

•  Using this info doesn’t make you a “Hacker”. (l33t h4x0r)

•  You have to dig in, learn & practice.

• It takes time!

=== Kick Off ===

A few things must happen before the assessment starts: •  Kick-off call •  Rules of engagement doc

– When – Limits – Scope – Point of contacts

=== Evidence Gathering ===

A report is expected at the end of the assessment. •  The more evidence you collect, the easier this makes your life.

=== Evidence Gathering ===

KeepNote is a great choice. –  Available for Linux, Windows and Mac. –  Paste screenshots, Create embedded pages and folders.

Group things based on vulnerability: –  Folder named "Default Server Pages" and each page will be the host & port.

–  Color-code the folder based on risk-rating. (personal preference)

–  Easy exporting of the KeepNote notebook as .html files & easy copy/paste into your program of choice while report writing.

–  Dradis is another popular choice in Kali.

=== Evidence Gathering ===

By Host: By Vuln

=== Evidence Gathering ===

Document: – HTTP Request and Response for each vulnerability

– Any unscheduled downtime or issues – Changes in test data

•  Creation of additional accounts, change passwords, or client-provided data

•  Intentional or inadvertent modification of any static data resource

–  (i.e. Added or altered files)

=== Evidence Gathering ===

Do not share screenshots or data of a great "hack” online.

=== Evidence Gathering ===

Get relevant, legible screenshots of the vulnerability.

Good evidence.Bad screenshot!

=== Evidence Gathering ===

Get relevant, legible screenshots of the vulnerability.

=== Evidence Gathering ===

•  Call out the specific issue during the write-up, so the client can see exactly what was sent. –  If a screenshot, outline the vulnerability. –  If text, highlight the vulnerability.

=== Evidence Gathering ===

List all known affected

pages and

parameters for a

vulnerability.

=== Evidence Gathering ===

•  Have a methodology and checklist to go by during each assessment. –  OWASP has a good methodology and checklist.

–  Helps to keep you on track

-  Don’t limit yourself to it!

=== Discovery / OSINT ===

•  Search engines, Pastebin, ShodanHQ, Recon-NG, PwnedList.com, for anything related to the application. – This is a manual and time-consuming process, but not one to be ignored!

– Email archives, logins, dev help forums

– Any leaked credentials, known previous hacks?

– Sites like urlvoid.com to check for known active malware/threats for the domain

=== Discovery / OSINT ===

Found info on DB type, schemas & test credentials through old development help forums that were STILL valid!

=== Discovery / OSINT ===

=== Discovery / OSINT ===

=== Automated Scanning ===

"Why do you run automated tools?

You're supposed to be a hacker."

=== Automated Scanning ===•  HUGE time-saver with assessments! – Wide range of tests, quickly – Finds “low-hanging fruit”

A vuln scan is NOT a penetration assessment!

=== Automated Scanning ===

...and to those who say it is:

=== Automated Scanning ===

•  Nessus – Looks at the host and web app. Covers everything from SSL/TLS layer, content discovery, basic CGI vulns and more.

•  IBM App Scan – More web app focused for things such as SQL/LDAP injections, CSRF and XSS, inspect WSDLs, etc...

=== Automated Scanning ===

•  BurpSuite Pro – Built-in "Active" scanner, content spider and content discovery brute-forcer tools.

•  Nikto – Great for finding default pages, known vulnerable scripts, CGI testing and more

– Also built in to Nessus, but can add a great deal of time to the scan

– We prefer to use this separately, outside of Nessus. It gives me more control.

=== Automated Scanning ===

–  Identifies known WP vulnerabilities –  Enumerates themes, plug-ins and usernames –  Also other content-management system scanners out there for Joomla, Drupal and more.

=== Automated Scanning ===

=== Automated Scanning ===

•  PRO TIPS: – You want to verify the settings of the automated scanner. Don't just blindly click "scan" after entering a URL.

– Make sure that you're not using something that's checking for Denial-of-Service (DoS) unless specifically requested by the client.

– Number of threads/connections at a time? Don't flood the host.

=== Automated Scanning ===

•  PRO TIPS: – Add any pages/functions the client has asked you to avoid. (Password reset page, sign-up page, "Contact" forms)

– Might need to specify a "Page not found" or Error 404 page to help weed out false-positives for file discovery.

– Configure the log-in process and credentials for authenticated scans.

– You must take the time to verify the results and remove false-positives!!

=== Automated Scanning ===

Then when you’re ready, Gooooooooooooo!

=== Manual Testing ===

Automated Scanner results: – Document the vulnerabilities that are legitimate.

•  Can you take it further than the scanner?

•  For example, if the scanner suspects SQL injection, see if you can exploit and dumb the tables with SQLMap.

=== Manual Testing ===

Explore the application through a proxy program like BurpSuite Pro.

– Manually explore the app while the "Spider" and "Content Discovery" tools are running.

– Alternatives: •  OWASP Zap •  Paros

=== Manual Testing ===

•  Review the server response to help verify what the server is running (IIS, Apache)

•  Parameter Fuzzing – How do they handle characters and commands outside of the normal expected input/actions?

•  Parameters can be directly in the URL. They are also found in HTTP POST requests

=== Manual Testing ===

•  Test for: – Cross-site Scripting (XSS) – Cross-site Request Forgery (CSRF) – SQL/LDAP injection – Local & Remote File Inclusion (LFI/RFI)

=== Manual Testing ===

•  BurpSuite Pro has lists available that you can load for file discovery, XSS, SQLi, usernames, directories & more. – There are also several places to download your own lists, or make your own.

– XENOTIX by OWASP is a good XSS scanner w/ big list.

=== Manual Testing ===

Specify the parameters you want to fuzz.

=== Manual Testing ===– Save the POST or GET request and execute with SQLMap to search for SQL injection.

– BurpSuite has a SQLMap plugin.

=== Manual Testing ===

•  Is sensitive info being passed through the URL in a GET request? – Usernames, Passwords, Session ID

•  Look for valuable comments in the source code of the HTTP Responses – Internal IPs, DB names, usernames, "hidden" admin URLs, database calls in JavaScript and more!

– This is certainly a manual process and is time-consuming. However, it can pay off.

=== Manual Testing ===

To prevent “death by PowerPoint”:

=== Manual Testing ===

•  Authentication - can it be bypassed or broken? – Can you access URLs/functions as an unauth user that you could while logged in?

– Can you re-use the session token after logging off?

– Is there a "log off" feature? – Can you have multiple sessions as the same user at the same time?

– What are the password requirements? – What’s the password change process?

=== Manual Testing ===

•  Look at the host, not just the web app – Identify the web server platform. Apache, IIS?

•  If it's an old/outdated install, look for exploits

– Is there an admin portal available? •  cPanel, Apache Tomcat Manager, etc...

– Are the test/default creds valid? – Search for backup, default & obsolete files

– Is directory browsing enabled? What about directory rights?

=== Manual Testing ===

– Look for dangerous HTTP methods •  ie...PUT, COPY, DELETE, TRACE

– Are they vulnerable to directory traversal, Shellshock, Heartbleed?

– Use Nmap to see what ports/services are open to the public.

•  Are other things open other than 80 & 443?

=== Manual Testing ===

– Look at SSL/TLS settings for known and weak cipher vulns, expired or untrusted certificates

•  SSLScan in Kali or Qualys SSL Labs is a good online resource too

– SSL Enforcement •  Can you access HTTPS areas by HTTP?

=== Manual Testing ===Look for file uploading features.

–  Can you upload malicious shell scripts? •  PHP, ASP, ASPX, .WAR, shell scripts

=== Manual Testing ===Evasion against AV, IDS, IPS, WAFs •  Obfuscation, Polymorphic •  File Extensions •  File Wrapping

=== Manual Testing ===

•  Continue to study & understand each attack vector. – Know what is going on behind the scenes after you push a button.

– Several great books and free resources online! (Save $$)

•  Practice in a lab, NOT on a client’s site. ☺

•  Then....

Go hack some websites!

Hacking Web Apps

Sr. Security Consultantat Solutionary

Twitter:

@brentwdesign

Brent White-----------------------------------

www.solutionary.com