My presentation from Confitura 2014 Conference

1. 1
Leszek Miś
IT Security Architect
RHCA,RHCSS,Sec+
lm@linuxpolska.pl
Linux Polska Sp. z o.o.
Wykrywanie i eliminacja zagrożeń
w czasie rzeczywistym – Appsensor
w akcji.

2. 2
#whoami
● Leszek Miś:
– IT Security Architect – RHCA/RHCSS/Sec+
– Instruktor/egzaminator Red Hat
– Splunk Certified Architect
– Lider projektu WALLF Web Gateway (http://wallf.pl)
● Skupiam się głównie na:
– Linux/Web/Cloud Security
– SELinux/WAF/SSO
– IdM/Domena linuksowa
– Testy penetracyjne

3. 3
O firmie Linux Polska
● Podstawowa działalność spółki:
– Wsparcie lokalne dla systemów Open Source
– Wdrożenia i migracje
– Bezpieczeństwo IT
– Szkolenia autoryzowane i autorskie

4. 4
Agenda
● Web (in)security
● Web Application Firewalls
● OWASP Appsensor:
– Wbudowany w aplikację
– Reverse Proxy
● Podsumowanie

5. 5
Web (in)security
● Aplikacje webowe jako cel czyli zagrożenia kryją się
wszędzie:
– Aplikacja
– Protokół
– Implementacja HTTP
– Język/Framework
– Konfiguracja
– System operacyjny

6. 6
Web (in)security
● Rzeczywistość weryfikuje:
– Zimbra: priv_esc poprzez LFI:
● /res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz?
v=091214175450&skin=../../../../../../../../../opt/zimbra/conf/localconfig.xml
– OSSIM: SQL Injection
– Apache Struts: RCE
– F5 BigIQ – priv_esc
– JIRA: directory traversal
– Katello: users/update_roles
– I wiele, wiele innych...
● Dostępność kodu/możliwość zakupu->hacklab
● Wiele podobnych instalacji

7. 7
Web (in)security
● Cross Site Scripting
● SQL Injection
● LDAP Injection
● XPATH Injection
● XML Injection
● Blind SQLi
● Time based SQLi
● RCE
● Forced browsing
● Local File Inlusion
● Remote File Inclusion
● Session Hijacking
● HTTP Response Spliiting
● Sniffing/Spoofing
● ClickJacking
● MitB
● Open Redirect
● DOS/DDOS
● Cross Site Request
Forgery (CSRF)
● Information/Path
Dislosure
● Server Side Includes
Injection
● Bruteforce
● Buffer overflow
● Misconfiguration
● Drive by Download
● + mix

8. 8
Web (in)security
● A jak wygląda “badanie” dedykowanej aplikacji
biznesowej?
– Hostowanej jedynie w obrębie środowiska
atakowanego podmiotu
– Bez dostępu do kodu źródłowego
– Bez dostępu do dokumentacji i społeczności
– Bez możliwości uruchomienia w “hacklabie”

9. 9
Web (in)security
● A jak wygląda “badanie” dedykowanej aplikacji biznesowej?
– Fingerprinting
– Analiza nagłówków HTTP
– Analiza wygenerowanego HTML
– Fuzzing
– Skanery aplikacyjne
– Modyfikacja nagłówków i ich wartości – local proxy
– Spear phishing -> APT
● Dużo “egzotycznych” logów

10. 10
Web (in)security
● Problem z patchowaniem podatności:
– Wysoki koszt
– Kod źródłowy firmy zewnętrznej
– Ograniczony kontrakt/umowa
– Brak zasobów
– Brak skillsów
– SDLC -> TST->ACC->PROD
– Niedostępność aplikacji
– Inne?

11. 11
Potrzeba posiadania WAF

12. 12
Co to WAF?
● Web Application Firewall (L7):
– Wykrywanie
– Blokowanie
– Monitorowanie
– Audytowanie
– Response
● Różnica pomiędzy firewallem sieciowym, a WAF-em

13. 13
Potrzeba posiadania WAF
● Bezpieczeństwo i dostępność serwisów IT podstawą
profesjonalizmu i wysokiej jakości usług odczuwalnej
przez użytkowników
● 80% ataków i włamań do systemów IT odbywa się
poprzez stronę internetową lub powiązany z nią
komponent
● Dotychczasowe systemy ochrony są niewystarczające –
nie potrafią wykrywać co poprawne, a co niebezpieczne
● Niezależnie od wdrożonych zasad, procedur i polityk –
błędy w oprogramowaniu będą pojawiać się zawsze

14. 14
Potrzeba posiadania WAF
● WAF nie jest złotym środkiem
● WAF jako ubezpieczenie
● WAF -> wirtualne patchowanie -> hotfix for 0-day X
● WAF często daje złudne poczucie bezpieczeństwa
● WAF WAF-owi nierówny
● Czasochłonna konfiguracja i trudne utrzymanie
● WAF również posiada podatności ;-)

15. 15
Potrzeba posiadania WAF
● Rodzaje WAF:
– Komercyjne
– Open Source
● Architektura:
– Wbudowane w serwer HTTP
– Reverse Proxy
– SPAN/port mirroring
– Inline bridge / Sniffer
● Tryby pracy:
– DetectionOnly / Learning mode
– Enforcing
● Silniki wykrywania oparte na: white/black/hybryd listach

16. 16
Potrzeba posiadania WAF
● Problemy:
– Już po fakcie
– Analiza powłamaniowa
– False positives
– Trudne w utrzymaniu (change mgmt +
niekontrolowany payload aplikacyjny)
– Brak kontekstu użytkownika ze względu na
odseparowane urządzenie WAF
– Fingerprinting zachowania WAF + omijanie BL
– Informowanie o zagrożeniach

17. 17
OWASP Appsensor 2.0

18. 18
Organizacja OWASP
Open Web Application Security Project
Misja: Poprawa stanu bezpieczeństwa aplikacji
„Make application security visible so that people and organizations
can make informed decisions about true application security risk”
- Projekty – dokumentacja, narzędzia
- Edukacja
- Współpraca (rządy, inne organizacje, twórcy standardów)
Linux Polska jako OWASP Silver Local Chapter Supporter

19. 19
Wybrane projekty OWASP
DETECT PROTECT LIFE-CYCLE
Documentation Top10
ASVS
Testing Guide
Code Review
Guide
Development Guide
Secure Coding
Practices – Quick
Reference
OpenSAMM
Tools WebScarab
Zed Attack Proxy
JBroFuzz
ESAPI
AppSensor
ModSecurity Core
Ruleset
WebGoat
Education Project
https://www.owasp.org/index.php/Category:OWASP_Project

20. 20
OWASP Appsensor 2.0
● Metodologia
● Koncepcyjny framework
● Drogowskazy do zbudowania własnej implementacji
bezpiecznej architektury aplikacji

21. 21
Appsensor 2.0
● Użytkownik raczej się nie pomylił, gdy:
– Podmieniane są wartości parametrów w locie
– “><script>alert(/confitura/)</script>
– Wysłany został GET zamiast POST
– User-Agent jest URL-em
– 5x JSESSIONID

22. 22
Appsensor 2.0
● Podobieństwo w zachowaniu:
– czujniki dymu w budynkach i proces reakcji
alarmowania

23. 23
Appsensor 2.0
● Aplikacja powinna potrafić:
– Identyfikować zachowania użytkownika odchodzące
od normy
– Wykrywać próby ataków/”sondowanie”
– Punktować/blokować atakujących lub w sytuacji
“zarobaczenia” blokować podatną część aplikacji
– Rozumieć i akceptować zachowanie zwykłego usera
– Informować -> SIEM

24. 24
Appsensor 2.0
● IDS dla aplikacji webowych:
– Detection
– Evaluation/Scoring
– Response
● Niskopoziomowy – wbudowany w aplikację
● Minimalna ilość false'ów -> kontekst
● Automatyczna detekcja oraz natychmiastowa reakcja

25. 25
W jaki sposób
zaimplementować Appsensor?

26. 26
Appsensor
● Zależności:
– OWASP ESAPI Java library:
“Don’t write your own security controls!”
– JavaMail libraries
– Servlet/JSP
– Log4j (domyślnie)
– POM:
<dependency>
<groupId>org.owasp.appsensor</groupId>
<artifactId>AppSensor</artifactId>
<version>2.0</version>
</dependency>

27. 27
Appsensor
● Przede wszystkim: Secure SDCL

28. 28
Appsensor
● Konfiguracja globalna dzieli się na:
● Intrusion Detection Code:
– new AppSensorException("ACE3", "Invalid
request", "Attacker is requesting a
non-existent (404) page (" + requestedURI +
")");
– AttackDetectorUtils.verifyValidRequestMeth
od(request, AttackDetectorUtils.POST);

29. 29
Appsensor
● Intrusion Threshold Configuration
– IntrusionDetector.ACE2.count=3
– IntrusionDetector.ACE2.actions=log,logout,di
sable,disableComponent

30. 30
Appsensor
● Kategorie obsługiwanych wyjątków:
– Request Exceptions
– Authentication Exceptions
– Session Exceptions
– Access Control Exceptions
– Input Exceptions
– Enconding Exceptions
– Command Injection Exceptions
– Honey traps
– Reputation
– System Trend Exceptions

31. 31
Appsensor
● Ilość requestów
● Minimalizacja ryzyka

32. 32
Appsensor
● Request Exceptions:

33. 33
Appsensor
● Authentication Exceptions:

34. 34
Appsensor
● Session Exceptions:

35. 35
Appsensor
● Implementacje demonstracyjne:
– Appsensor WS
– Appsensor Core
– Light Touch Retrofit (phpBB)
– Ensnare for Ruby
– Using SIEM
– Modsecurity

36. 36
Schemat działania Appsensora

37. 37
Appsensor – detection points/responses

38. 38
A co z aplikacjami, do których nie
posiadamy kodu źródłowego?

39. 39
Secure Web Gateway - co jest istotne?
● Hardened Linux distro
● HA
● LB/Clustering
● WAF/Appsensor
● SSL configuration
● Access Control
● Change Mgmt
● Logging Mgmt
● Incident Response Mgmt
● Isolation
● Separation
● Scalability
● Monitoring
● Caching
● Performance tuning
● 2FA
● Auditing
● Logout ;-)

40. 40
WAF
● Architektura

41. 41
Reverse Proxy - WAF
● Fazy filtrowania:
● Każda transakcja przechodzi przez 5 faz filtrowania:
– 1: Request headers
– 2: Request body
– 3: Response headers
– 4: Response body
– 5: Logging
● Modsecurity CRS

42. 42
Reverse Proxy - WAF
● HMAC
● Content Security Policy
● Webhoneypots
● LUA
● JSON/XML
● AV Scanning
● SIEM Integration
● GEO/IP reputation
● BEEF czyli Attack the attacker:
– Browser as Pentester's gateway

43. 43
Podsumowanie
● WAF = ubezpieczenie
● Appsensor jako podejście nowe, przyszłościowe
● Krytyczność Reverse Proxy
● Zasoby OWASP jako wzorce do naśladowania
● Open source jako platforma
“Some people, wether vemdors or customers, believe in "auto
learning mode". My experiance with such systems is that the
(generated) rule set becomes unmanageable after a couple of
time.” - Achim Hoffman - OWASP

44. 44
Podsumowanie
● Linux Polska:
– Nad czym pracujemy:
● WALLF Web Gateway
● OpenStack
● Backup VM system
● Splunk Apps and Add-ons
– Wizja
– Zespół
– Kogo potrzebujemy?

45. 45
Podsumowanie

46. 46
Dziękuję za uwagę.
Leszek Miś
IT Security Architect
RHCA,RHCSS,Sec+
lm@linuxpolska.pl
Linux Polska Sp. z o.o.