This document discusses reverse engineering a web application for web application firewall (WAF) detection. It describes analyzing application traffic and structure, including parameter matching, file structure analysis, and restricting access. Statistical analysis of traffic is also suggested to identify attacks and new trends for the WAF. Challenges include vulnerabilities in code, themes, plugins and handling multiple languages.
Power point inglese - educazione civica di Nuria Iuzzolino
Reversing Engineering a Web Application - For fun, behavior and detection
1. Sector 2014
Toronto, Ontario
Reverse Engineering a Web
Application - For Fun, Behavior &
WAF Detection
Rodrigo “Sp0oKeR” Montoro
Sucuri Security
2. $ whois @spookerlabs
➢ Senior Security Administrator at Sucuri
Security
➢ Author of 2 patent pending technologies
➢ Researcher
➢ Open Source enthusiast
➢ Triathlete
➢ Dad
3. About Sucuri Security
Over 50 Security Professionals Making a Safer Web
SECURITY SCANNING & ANALYSIS
Checking the health over 3 Million websites
every month through our free Sitecheck Scanner:
http://sitecheck.sucuri.net
MALWARE CLEANUP
Cleaning and remediating 300 – 400
hacked or infected websites everyday.
ATTACK PROTECTION
Blocking over 33 million attacks and
instances of malicious traffic every month
EDUCATION
Providing detailed and actionable security
information through our blog at
http://blog.sucuri.net
4. A Note on the Examples
This talk is based on WordPress / NGINX, but the
concepts can apply to any
Web Application / CMS.
5. Motivations
➢ Trying different approach than a regular
WAF
➢ Protect specific content (CMS)
➢ Malware reinfections
➢ Less rules with better detection =
performance
➢ Protected against "new vulnerabilities"
27. Something could go wrong …
Counter Intelligence / Statical Data
Traffic Analysis
Analyzing Application
Structure /
Local Hardening
Monitoring
D
E
T
E
C
T
I
O
N
F
L
O
W
Bypass rules
Credentials stolen
Cookie hijack
Bad administrator
D
E
T
E
C
T
I
O
N
F
L
O
W
Analyzing Application
Structure /
Local Hardening
Monitoring
40. Realtime Monitoring w/ OSSEC
<localfile>
<log_format>apache</log_format>
<location>/var/log/httpd/access_log</location>
</localfile>
<!-- Frequency that syscheck is executed - set to every 4 hours -->
<frequency>14400</frequency>
<!-- Directories to check (perform all possible verifications) -->
<directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories realtime="yes" check_all="yes">/bin,/sbin</directories>
<directories realtime="yes" report_changes="yes"
restrict=".htaccess|.php|.html|.js">/var/www/html/</directories>
<alert_new_files>yes</alert_new_files>
<scan_on_start>no</scan_on_start>
<auto_ignore>no</auto_ignore>
<alert_new_files>yes</alert_new_files>
41. Threshold ideas
➢ Too many 404
➢ GET per time same IP Source
➢ POST per time same IP Source
42. Special File Permissions ( bit paranoid =) )
spooker@spookerhome:/tmp/wordpress$ echo "Malware Content" >> test.php
spooker@spookerhome:/tmp/wordpress$ cat test.php
Malware Content
spooker@spookerhome:/tmp/wordpress$ ls -lah test.php
-rw-rw-r-- 1 spooker spooker 16 Set 12 14:12 test.php
spooker@spookerhome:/tmp/wordpress$ lsattr test.php
----i--------e-- test.php
spooker@spookerhome:/tmp/wordpress$ echo "Malware Content" >> test.php
bash: test.php: Permission denied
spooker@spookerhome:/tmp/wordpress$ ls -lah test.php
-rw-rw-r-- 1 spooker spooker 16 Set 12 14:12 test.php
spooker@spookerhome:/tmp/wordpress$
A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created
to this file and no data can be written to the file. Only the superuser or a process possessing the
CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
52. The Challenges
➢ Bad codes
➢ Themes
➢ Plugins (33.5K+)
➢ Languages
53. Looking to the Future
➢ Integration with SCAP (Security Content
Automation Protocol) checks
➢ Create an OpenSource tool to regex traffic
○ Database of regexes per Application
➢ Build a rule set for CMS (WordPress,
Joomla, Drupal, vBulletin, Magento …)
under OWASP Projects
When crawling remember about simulate a regular user =)
Burp to spider and tcpdump saving pcap
Many thousands ways to modify a variable, why not check if only one way and so drop the rest ?
Comment about HTTP version
Referer
Number of headers
Pwd as blacklisted most common password
POST won't cache info
Comment about HTTP version
Referer
User-Agent (talk about size)
Number of headers
Non match traffic will be drop when deploying but we could deploy after some tune in monitor mode
Save a regular traffic to site and TEST against our parser.
Customer could send a pcap with traffic so we could previous tune rules for them.
Comment about if problems
Talk about POST methods
Comment about default bypass, cookie hijack or regular stolen user/pass
remember to talk about Gregg CMS 101 talk that looks into readme, changelog to detect versions
Besides protecting some files, those protection will make your directory/files not accessible if infected.
Advantage about nginx protection its harder to hack nginx file
No 100% security
What to do if protection fails and attacker has local acccess ?
Talk about CMS hacking 101
Changing 404.php file using admin interface
Talk about CMS 101 AppSec hacking
19 bytes
Most of ours blocks are made by GEOIP
Comment about default bypass, cookie hijack or regular stolen user/pass