Sprawozdanie

Z przedmiotu

Podstawy Bezpieczeństwa Informacji

Laboratorium 3 – 4

Sprawozdanie wykonali:

Robert Nawrot
Maciej Gudanowicz

Grupa I9M1S1

1. Projekt sieci przedsiębiorstwa

Pierwszym ćwiczeniem było stworzenie projektu sieci przedsiębiorstwa. Projekt miał

uwzględniać usługi takie jak: web, bezpieczny zdalny dostęp, baza danych, serwery DNS, poczta
elektroniczna, serwery plików, sieć użytkowników.

Poniżej nasz projekt sieci:

Do projektu dołączamy przykładowe ustawienia firewalli:

Source

Destination

Action

LAN

Internet

Permit

LAN

Serwer DB

Block

LAN

Poczta

Permit

LAN

Serwery DNS

Permit

LAN

Serwer plików

Block

LAN

Serwer Web

Permit

Internet

LAN

Block

Internet

Serwer DB

Block

Internet

Poczta

Permit

Internet

Serwery DNS

Permit

Internet

Serwer plików

Block

Internet

Serwer Web

Permit

Serwer Web

Serwer DB

Permit

Serwer Web

Serwer plików

Permit

Serwer Web

LAN

Block

ANY

ANY

Block

Wnioski:

Dla zapewnienia najlepszej możliwej ochrony przed atakami należy podzielić projektowaną

sieć na strefy ochronne. Strefę współdzielą ze sobą elementy sieci, które wymagają takiego samego
poziomu ochrony. Najsłabiej chroniona jest tak zwana strefa zdemilitaryzowana. Znajdują się w niej
zasoby, które muszą być dostępne z internetu, takie jak serwer poczty, serwer DNS, serwer web
oraz bezpieczny zdalny dostęp. Za kolejnym firewallem znajdują się strefy o najwyższym stopniu
bezpieczeństwa: strefa DB oraz strefa LAN. Taki układ sieci zapewnia dobrą odporność na ataki a
przy tym umożliwia na zdalny dostęp do zasobów przedsiębiorstwa poprzez zdalny dostęp.

2. Wykonanie ataków na aplikację SuperVEDA

Drugim zadaniem było przeprowadzenie kilku ataków na aplikację SuperVEDA, ataki SQL

Injection oraz XSS. Następnie próba powtórzenia tych ataków przy włączonym firewallu aplikacji.

Po podłączeniu się do aplikacji rozpoczęliśmy od ataku SQL Injection na stronie showproducts.asp.
Luką w zabezpieczeniach jaką tutaj wykorzystaliśmy była podatność na wprowadzenie kodu SQL
do adresu URL przeglądarki. Do adresu strony dodaliśmy następujący kod SQL:

UNION SELECT * FROM users WHERE 1=1

Został wygenerowany błąd mówiący o nieprawidłowej ilości argumentów. Następnie
powtarzaliśmy zapytanie dla coraz większej liczby argumentów. Dla sześciu argumentów
wygenerowany został błąd o nieprawidłowym typie argumentów. Po kilku próbach znaleźliśmy
poprawną kombinację argumentów w zapytaniu:

UNION SELECT 1, '1', 1, 1, '1', '1' FROM users WHERE 1=1

Następnie podmieniliśmy pierwszy argument typu tekstowego na nazwę kolumny tabeli users
przechowującej nazwy użytkowników:

UNION SELECT 1, username, 1, 1, '1', '1' FROM users WHERE 1=1

Zapytanie to wygenerowało następującą tabelę:

Zdobyliśmy również hasła użytkowników, które przechowywane były w niezaszyfrowanej postaci:

Następnie również metodą SQL Injection zaatakowaliśmy stronę dosearch.asp. Do pola
wyszukiwania wpisaliśmy następujący kod SQL:

' UNION SELECT 1, 1, password, '1', 1, 1, '1' FROM users WHERE '%'='

To również poskutkowało wyświetleniem listy haseł użytkowników:

Ostatni atak SQL injection wykonaliśmy na stronie login.asp. Ze względu na to, że aplikacja
wysyłając zapytanie do bazy sprawdza jedynie czy zostały zwrócone jakiekolwiek rekordy a nie ich
ilość, należało w pole username i password wpisać takie wartości aby poskutkowało to zwróceniem
całej tabeli użytkowników. Do pól wpisaliśmy:

' OR ”='

Co poskutkowało zalogowaniem się na konto pierwszego użytkownika z tabeli. W naszym
przypadku było to konto użytkownika Mickey.

Następnie przeszliśmy do ataku Cross Site Scripting. Techniki tej użyliśmy w formularzu kontaktu
z administratorem strony contactus.asp. Wypełniając formularz kontaktowy wpisaliśmy do pola text
kod mający na celu symulację działania złośliwego kodu wprowadzonego przez intruza:

<script>alert(„Przekierowanie administratora na strone intruza”)</script>

Po wysłaniu wiadomości zalogowaliśmy się na panel administratora i weszliśmy na stronę
Messages Review. Po kliknięciu na wysłaną wiadomość pojawiło się okno:

Następnie włączony został firewall aplikacji a naszym zadaniem była próba powtórzenia
wcześniejszych ataków. Niestety nie udało nam się to, firewall wyłapał każdy nasz atak. Zarówno
na stronę showproducts.asp:

Jak i na stronę dosearch.asp:

Poniżej prezentujemy również screen z panelu firewalla ilustrujący powiadomienie o próbie ataku
SQL injection:

Wnioski:

Zadanie laboratoryjne pokazało jak poważne niebezpieczeństwo stanowią ataki typu SQL

injection oraz XSS. Pozwalają one na pozyskanie poufnych danych z bazy aplikacji bądź na
wykonanie kodu na komputerach innych użytkowników aplikacji. Po uruchomieniu firewalla
aplikacji nie udało nam się skutecznie przeprowadzić ataku, co nie znaczy, że jest on niemożliwy.

Nie należy w kwestiach bezpieczeństwa polegać jedynie na jednym rozwiązaniu. Gdyby

firewall z jakiegoś powodu przestał poprawnie działać aplikacja tego typu była by podatna na
wszelkiego rodzaju ataki.

Zamiast tego należy starać się napisać jak najbezpieczniejszą aplikację i dodatkowo

wzmocnić ją firewallem. Można np. używać sparametryzowanych zapytań do bazy lub przed
wykonaniem zapytania sprawdzić czy pole tekstowe zawiera wyłącznie znaki alfanumeryczne.