Specjaliści z Alliance Security Labs znaleźli w SecureIIS błędy, które wystawiają użytkowników na zagrożenia, przed którymi program ten miał ich chronić.
Błędy ma wersja 1.0.4 oraz wcześniejsze. Ironią losu jest, że dotyczą one zabezpieczeń, które reklamowane są przez firmę eEye jako główne atuty produktu. Oto niektóre nieprawidłowości:
1. Sprawdzanie słów kluczowych.
SecureIIS nie sprawdza zakodowanych znaków w żądaniach. Tak więc słowo „ADMIN” zostanie wykryte, ale „%41DMIN” już nie. Część główna (body) posta nie jest sprawdzana wogóle. Przykład:
GET /whatever.script?user=%41DMIN HTTP/1.0
oraz:
POST /whatever.script HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Lenght: 10
user=ADMIN
2. Ochrona zasobów przed nieautoryzowanym dostępem.
Podobnie jak w p.1, związane to jest z brakiem kontroli nad zakodowanymi ciągami znaków. Wystarczy więc zakodować kropkę jako %2e lub slash jako %2f, aby pozwolić niepowołanym osobom na swobodny dostęp do wszystkich plików. Przykładowo, następujące żądanie nie zostanie odrzucone przez SecureIIS:
GET /whatever.script?file=/%2e%2e/%2e%2e/boot.ini HTTP/1.0
oraz:
POST /whatever.script HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
page=/../../boot.ini
3. Przepełnienie bufora (nagłówki HTTP).
Pomimo ustawionego „Host protection” (z domyślnym limitem 256b), wysłanie więcej niż 256b w nagłówku hosta przechodzi przez SecureIIS i nie jest odrzucone:
GET / HTTP/1.0
Host: [500 x losowe znaki a-z ]
4. Przepełnienie bufora (SecureIIS).
Jeśli żądanie jest duże (kilkanaście tysięcy znaków), może się zdażyć, że atakujący pozna treść żądań poprzednich użytkowników, sposób wewnętrznej konfiguracji strony lub inne poufne dane.
Stwarza to dla witryny WWW poważne zagrożenie bezpieczeństwa, jakkolwiek incydenty z p.4 występowały losowo i były trudne do powtórzenia. (czyli zdarzyć się może wszystko :))
Osoby zainteresowane zgłaszać się powinny do firmy.