3. Reasons for using
IDS solutions
β known weaknesses and vulnerabilities
β balance between security and usability
rd
β
3 -party applications and libraries
β insecure client software
β additional layer of security
β fear, uncertainty, doubt
IDS, IPS or WAF?
4. IDS purpose
β data source for post-intrusion analysis
β real-time intrusion investigation
β holy grail: intrusion prevention
How can we detect unknown attacks?
5. Positive security model
β βaccept known goodβ mantra
β allowed byte ranges
β regular expressions
β allowed variables whitelist
What about encoded (base64, weak encryption,
multiple charsets) or complex (HTML, file
upload) data?
6. Positive security model
β when application changes, whitelist has to
change too
β lots of alerts
β http://p1.tld/p2/p3.php/p4/p5=p6,p7?p8&p9=p0
β real-time protection? block them all!
β sanitizing wrong input could help
Why can't we do this in the application itself?
7. It's easier to fix applications,
than detect attacks
β usually true
β
3rd party software and libraries
β unknown attack methods
β security filters adding new vulnerabilities
β example: HTML filters
8. HTML filters review β March
2008
Tested: 5 popular anti-XSS HTML filters (PHP)
Results:
β 3/5 vulnerable to XSS (+1 already known 0-day)
β 2/5 included PHP code execution bugs (kses,
htmLawed)
β alternative syntax like Textile or Markdown also
not safe from XSS
9. Negative security model
β blacklist detection rules
β far less alerts
β classification by attack type, priority, etc.
β generic rules: often too general, false positives
β specific rules: very limited, often outdated
How to detect unknown attacks?
10. Examples
β Snort β known exploits
β ModSecurity Core Rules β generic
β PHPIDS β generic, focused on XSS
11. PHPIDS
β LGPL licensed IDS library for PHP applications
β impact rating for each malicious request
β could be added in auto_prepend_file, without
modifying application code
β attempts to detect unknown attack patterns
http://php-ids.org/
13. What are we trying to detect?
β automated exploits
β automated vulnerability scanners
β manual attacks
β uncommon user behaviour
β intrusion vs vulnerability testing
How to recognize source type?
14. A1 - Cross Site Scripting (XSS)
β most common: <script, document.cookie
β dangerous HTML tags and attributes
β breaking out of HTML attribute
β JavaScript keywords
β comparing request and response
β PHPIDS regular expressions
15. XSS from attacker's view
β needs just one byte to detect vulnerability,
e.g. β, <, (
β easy to make it look innocent
<a href=βhttp://tested.site.tld/page.php?
id=article">Interesting article</a>
<script>[Google Analytics]...
β usually needs at least several requests to
prepare working attack (for custom application)
16. XSS β detection
β hard to detect less common vulnerability testing
patterns
β recognizing malicious XSS code is easier
β time window between finding vulnerability and
developing exploit
β real-time detection could prevent attack
rd
How to detect DOM-based XSS or 3 party
JavaScript/CSS modifications?
17. XSS β reducing false positives
β different rules for public and private application
sections
β check for persistent XSS after HTML filtering
(response buffering or PHPIDS)
β don't alert when only single keyword/char
matches rule (skip non-malicious XSS)
β raise impact rating for suspicious or missing
Referer headers
β don't even think about βtrusted IPsβ
18. A2 β Injection Flaws
β paranoid mode: blocking semicolon and quotes
β checking for SQL (or other language) keywords
β 2.0, 2-0, 2-1, 2;[query]
β val'||', val';[query]
β 2 AND 1=1, 2 AND 1=2
β 2 UNION...SELECT [query]
β /*...*/, /*!...*/
β βpage.tld/page?var=1/*&UNION SELECT*/β
19. SQL Injection
β relatively easy to detect malicious attacks
β many false positives, if we want to detect
vulnerability testing
β good results with whitelisting
β reducing false positives by checking traffic
between application and database (or in the
application, before executing query)
β real-time reporting of SQL query errors
20. Command/Code Injection
β much wider range of malicious code than for
SQL Injection
β detect vulnerability testing, not exploits
β reducing false positives by eliminating known
vectors
β common commands and functions
β `, {${, <?, <%
β real-time reporting of application errors
23. A4 β Insecure
Direct Object Reference
β easier to fix than detect
β whitelisting often doesn't help
β we can try to detect data harvesting tools
β multiple requests to the same page, with
different set of parameters
β repeating requests to a single page or a small
subset of pages
β small mistakes in automatically generated
requests (Referer, null bytes, missing headers
or cookies)
24. A5 β Cross Site Request Forgery
(CSRF)
β why black hats love CSRF?
β again, it's really easier to fix than detect
β external or missing Referer header
β missing cookies
β Accept header
β user trying to perform action while logged out
β user trying to remind password while logged in
β broken application flow
β Referer-less redirects, clickjacking
25. A6 β Information Leakage and
Improper Error Handling
β monitoring outbound traffic (e.g. ModSecurity)
β application code, HTML comments, error
messages (esp. SQL)
rd
β
3 party software may leak undocumented or
non-standard error messages
β what information should be treated as leakage
(and how IDS knows it)?
β Blind SQL Injection
26. Forcing errors
β var[]=1
β 1.1, 1x, ./1, /1
β β, ', !, %0A, %00
β wrong type of data
β wrong format of session identifier
β DoS
β ...
β too many possibilities to check requests
27. A7 β Broken Authentication and
Session Management
Session hijacking detection
β another one that is easier to fix in the
application itself (or rather βfixβ)
After identifier is stolen:
β IP address change during session
β headers changed/missing during session
Before:
β tampering session identifiers
β XSS
28. Session hijacking
β attacker's view
β sniffing traffic
Spoof IP, everything else you already have.
β XSS
You don't need to hijack session identifier,
just force the victim to do whatever you
wanted.
β Referer header
29. A8/A9 β Insecure Cryptographic
Storage and Communications
β not much to do for an IDS
(at least on the server side)
β passing base64-encoded or weakly encrypted
values to the client
β WAF protection against tampering
β may be decrypted on client side and leak
information
β general brute-force attacks detection
30. A10 β Failure to Restrict URL
Access
β IDS has no information about user rights in the
application
β known vulnerabilities in libraries/include files
β brute-force detection may deal with fuzzing
β broken application flow
β whitelisting
β IPS/WAF as a hotfix solution
32. Log, block, alert
3-tier solution
Tier 1:
β log everything you can
Tier 2:
β detailed log of detected attack attempts
Tier 3:
β possible intrusions and bypasses
33. Tier 1
β log everything you can
β all application errors
(with their context)
β full requests
(URL, headers, cookies, body)
β full responses
(HTTP code, headers, body)
34. Tier 2
β detailed log of detected attack attempts
β IDS alerts
β combined data from several sources
β including vulnerability testing patterns
β including blocked/sanitized requests
β optionally: requests following blocked one
35. Tier 3
β possible intrusions and bypasses
β alerts that require manual verification
β generate as much as you are able to check
manually
β skip blocked requests