1

Leszek MiśIT Security ArchitectRHCA,RHCSS,Sec+lm@linuxpolska.plLinux Polska Sp. z o.o.

Wykrywanie i eliminacja zagrożeń w czasie rzeczywistym – Appsensor

w akcji.

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

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

Agenda

● Web (in)security

● Web Application Firewalls

● OWASP Appsensor:

– Wbudowany w aplikację

– Reverse Proxy● Podsumowanie

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

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

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

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

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

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

Potrzeba posiadania WAF

12

Co to WAF?

● Web Application Firewall (L7):

– Wykrywanie

– Blokowanie

– Monitorowanie

– Audytowanie

– Response

● Różnica pomiędzy firewallem sieciowym, a WAF-em

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

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

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

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

OWASP Appsensor 2.0

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

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

OWASP Appsensor 2.0

● Metodologia

● Koncepcyjny framework

● Drogowskazy do zbudowania własnej implementacji bezpiecznej architektury aplikacji

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

Appsensor 2.0

● Podobieństwo w zachowaniu:

– czujniki dymu w budynkach i proces reakcji alarmowania

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

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

W jaki sposób zaimplementować Appsensor?

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

Appsensor

● Przede wszystkim: Secure SDCL

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.verifyValidRequestMethod(request, AttackDetectorUtils.POST);

29

Appsensor

● Intrusion Threshold Configuration

– IntrusionDetector.ACE2.count=3

– IntrusionDetector.ACE2.actions=log,logout,disable,disableComponent

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

Appsensor

● Ilość requestów

● Minimalizacja ryzyka

32

Appsensor

● Request Exceptions:

33

Appsensor

● Authentication Exceptions:

34

Appsensor

● Session Exceptions:

35

Appsensor

● Implementacje demonstracyjne:

– Appsensor WS– Appsensor Core– Light Touch Retrofit (phpBB)– Ensnare for Ruby– Using SIEM– Modsecurity

36

Schemat działania Appsensora

37

Appsensor – detection points/responses

38

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

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

WAF

● Architektura

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

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

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

Podsumowanie

● Linux Polska:

– Nad czym pracujemy:● WALLF Web Gateway● OpenStack● Backup VM system● Splunk Apps and Add-ons

– Wizja

– Zespół

– Kogo potrzebujemy?

45

Podsumowanie

46

Dziękuję za uwagę.

Leszek MiśIT Security ArchitectRHCA,RHCSS,Sec+lm@linuxpolska.plLinux Polska Sp. z o.o.