Penetration Test Report (Securitum): raport testy bezpieczenstwa yetiforce

Raport podatności znalezionych w aplikacji YetiForce CRM
Testowany system YetiForce CRM
Data wykonania audytu I-II kwartał 2017
Data wykonania retestów 5.07.2017 – 17.07.2017
Miejsce wykonania audytu Kraków
Audytorzy wykonujący prace Pentesterzy Securitum.pl
Wersja raportu 1.4
Raport jest dostępny publicznie – uzyskano na to formalną zgodę
YetiForce.
Informacje poufne. Zgoda na publikację .
www.securitum.pl
Strona 1 z 32 Raport podatności
Podsumowanie wykonanych prac
Niniejszy raport jest podsumowaniem testów bezpieczeństwa systemu YetiForce CRM w wersji 4.0.0.
Testy bezpieczeństwa realizowane były przy następujących założeniach:
• nakład pracy nie przekroczy 7 osobodni pracy pentesterów;
• testy powinny skupiać się na atakach pozwalających na przejęcie kontroli nad systemem
YetiForce (tj. wykonywanie dowolnego kodu po stronie serwera) przez napastnika
nieposiadającego dostępu do systemu. W następnej kolejności należy skupić się na
podatnościach pozwalających wyeskalować uprawnienia użytkownika;
• podatności, które mogły zostać wykorzystane tylko na koncie administracyjnym lub
uprzywilejowanym koncie użytkownika zasadniczo nie mają być sprawdzane.
Wnioski z testów
W systemie YetiForce zidentyfikowano kilka sposobów na wykonywanie dowolnego kodu po stronie
serwera. Praktycznie tego typu podatność może zostać wykorzystana m.in. do:
• Przejęcia wszystkich danych przechodzących przez system YetiForce. Mogą to być zarówno
dane użytkowników systemu (loginy i hasła), jak i dane przetwarzane przez system, takie jak:
listy kontrahentów, dane osobowe itp.
• Dalszych ataków na inne hosty znajdujące się w sieci wewnętrznej,
• Wykorzystanie oprogramowania typu „ransomware”, skutkującego zaszyfrowaniem plików na
dysku.
Zwraca również uwagę duża liczba podatności typu Cross-Site Scripting (XSS), które mogą zostać
wykorzystane do przejęcia kontroli nad kontami innych użytkowników.
Zalecenia
Większość podatności wynika z możliwości bezpośredniego dostępu do uploadowanych plików z
poziomu webroota. Zmiana architektury systemu YetiForce w taki sposób, by pliki wgrywane
użytkowników nie były umieszczone w webroocie pozwoli zniwelować te ryzyka.
Dużych zmian wymaga sposób ochrony przed podatnościami XSS. Zaleca się, by enkodować dane w
sposób odpowiedni dla kontekstu, jeśli w danym miejscu aplikacji nie pozwala się użytkownikom na
umieszczanie własnego kodu HTML, lub przefiltrować dane przez bibliotekę usuwającą złośliwe
elementy JavaScriptu, gdy niezbędne jest akceptowanie fragmentów HTML.
Szczegółowe zalecenia naprawcze zostały opisane przy poszczególnych podatnościach w dalszej części
raportu.
Informacje poufne. Zgoda na publikację .
www.securitum.pl
Strona 2 z 32 Raport podatności
Podsumowanie techniczne
W wyniku przeprowadzonych testów zidentyfikowano kilka sposobów na zdalne przejęcie kontroli nad
systemem YetiForce:
• Mechanizm importowania plików dostępny dla wszystkich użytkowników systemu YetiForce
w niewystarczający sposób waliduje poprawność wysyłanych plików, pozwalając tym samym
na wgranie pliku PHP do dowolnego katalogu serwera.
• System YetiForce może zostać połączony z firmową skrzynką emailową, dzięki czemu
wiadomości mailowe mogą być odczytywane i przetwarzane bezpośrednio z poziomu
YetiForce. Napastnik może jednak wysłać wiadomość ze złośliwym załącznikiem o rozszerzeniu
.php, który zostanie automatycznie zapisany na serwerze w katalogu o przewidywalnej
nazwie, a następnie wykorzystać podatność Cross-Site Scripting w odczycie maili, by wymusić
uruchomienie złośliwego kodu.
• Liczne podatności Cross-Site Scripting, m.in. w listingu nieudanych prób logowania w panelu
administracyjnym, mogą pozwolić na przejęcie konta administratora przez próbę logowania
na odpowiednio przygotowaną nazwę użytkownika.
• System YetiForce pobiera niektóre pliki źródłowe z serwerów GitHub. Ze względu na brak
walidacji poprawności certyfikatów SSL/TLS, napastnik dysponujący możliwością
przeprowadzenia ataku man-in-the-middle może przechwycić takie połączenie i podstawić
własne kody źródłowe PHP, które zostaną rozpakowane na serwerze.
Ponadto, w systemie zostało zidentyfikowanych kilka podatności o mniejszym poziomie istotności,
które jednak też mogą w pewien sposób ułatwiać napastnikom przejęcie kontroli nad systemem.
Wszystkie problemy zostały szczegółowo opisane w dalszej części raportu.
Informacje poufne. Zgoda na publikację .
www.securitum.pl
Strona 3 z 32 Raport podatności
Poniżej zestawienie statystyczne znalezionych podatności.
Podatności Wysokie
5
zagrożenie
6 5
Średnie
1
zagrożenie
3 3
4
Niskie
3
2 1 zagrożenie
0 Ogólne
3
Wysoki Średni Niski Info zalecenia
Informacje poufne. Zgoda na publikację .
www.securitum.pl
Strona 4 z 32 Raport podatności
Znalezione podatności
Na liście poniżej przedstawiono skrótowy opis każdej ze znalezionych podatności. Każdy błąd został
oznaczony kolorem, zgodnie z legendą:
Ogólne Niskie Średnie Wysokie
zalecenia zagrożenie zagrożenie zagrożenie
Status
Spis treści – podatności znalezione w systemie IT
po retestach
Wykonywanie dowolnego kodu w systemie operacyjnym przez Wyeliminowano
1.
import plików ZIP
2. XSS i wykonywanie dowolnego kodu przez załącznik w mailu Wyeliminowano
3. Liczne podatności XSS Wyeliminowano
4. XSS przez localStorage Wyeliminowano
5. Błędy SQL Injection – dostęp do bazy danych Wyeliminowano
Wykonywanie dowolnego kodu wskutek braku sprawdzania Wyeliminowano
6.
poprawności certyfikatów SSL
7. Możliwość obejścia zabezpieczenia przed zgadywaniem haseł Wyeliminowano
Niedziałające zabezpieczenie przed bruteforce przy niezgodności Wyeliminowano
8.
stref czasowych
9. Możliwość enumeracji użytkowników Wyeliminowano
10. Domyślna aktywacja regeneracji sesji Wprowadzono
11. Wydzielenie części aplikacji poza webroot Wprowadzono
12. Sugestia dotycząca stosowania SSL/TLS Wprowadzono
Informacje poufne. Zgoda na publikację .
www.securitum.pl
Strona 5 z 32 Raport podatności
Aplikacja - lista znalezionych podatności - szczegóły
Numer 1. Wykonywanie dowolnego kodu przez import plików ZIP
porządkowy
Lokalizacja Importowanie danych
Wymagane Zalogowany użytkownik systemu z możliwością importu plików.
uprawnienia
Opis W systemie YetiForce każdy z użytkowników ma możliwość importu różnego
typu danych (np. danych o produktach, kontrahentach itp.). Akceptowane są
rozszerzenia .csv, .xml oraz .zip.
Pliki .zip po imporcie są rozpakowywane do katalogu:
• cache/import/IMPORT_$userId_$userId
Nazwa katalogu jest przewidywalna, zaś sam katalog jest dostępny z poziomu
przeglądarki webowej. Jeśli w archiwum znajdzie się plik .php, zostanie on
również rozpakowany. Napastnik może wówczas odwołać się bezpośrednio do
pliku .php i wykonywać dowolne polecenia na serwerze. W konsekwencji
możliwe są m.in. następujące ataki:
• Podgląd wszystkich plików na serwerze, które są odczytywalne z
poziomu serwera aplikacyjnego,
• Podmiana plików źródłowych aplikacji,
• Dostęp do bazy danych aplikacji,
• Próby atakowania innych hostów w sieci lokalnej.
Utworzenie wewnątrz pliku zip pliku zawierającego w nazwie ciąg znaków: ../ (tj.
ucieczkę katalog wyżej), możliwe jest wypakowanie pliku .php do dowolnego
folderu na serwerze.
Zrzuty ekranowe
Aby wykorzystać podatność niezbędne jest przygotowanie pliku ZIP, zawierającego jeden poprawny
plik XML oraz złośliwy PHP. Plikowi PHP należy zmienić nazwę wewnątrz pliku ZIP na
"../../../exploit.php". Aby przygotować taki plik, należy wykonać poniższe polecenia w powłoce
shellowej:
echo '<MODULE_FIELDS><productname>sss</productname></MODULE_FIELDS>' > i.xml
echo '<?php phpinfo(); ' > test.php
zip import.zip test.php i.xml
printf "@ test.php\n@=../../../exploit.php\n" | zipnote -w import.zip
Aby zaimportować utworzony plik import.zip, należy przejść odpowiednio do: Bazy danych->Produkty-
>Akcje->Importowanie rekordów. Po zatwierdzeniu importu, plik exploit.php zostanie rozpakowany w
głównym folderze aplikacji Yeti.
Poniżej przedstawiono przykład wykonania funkcji phpinfo():
Informacje poufne. Zgoda na publikację .
www.securitum.pl
St