LUKI M3 - M5
Trzecia kategoria obejmuje nieprawidłową konfigurację lub niewłaściwe korzystanie z rozwiązań, które zapewniają poufność transmisji danych. Lukę wykryto w ponad jednej trzeciej ze zbadanych aplikacji. Najczęstszy zidentyfikowany problem polegał na niesprawdzaniu poprawności certyfikatu TLS, a tylko w 10% aplikacji zostało to zrealizowane poprawnie.
W korzystających w tym zakresie z własnego mechanizmu wykryto błędy implementacji, przez które certyfikat wygenerowany przez przestępcę nie zostałby odrzucony, umożliwiając mu tym samym dokonanie ataku typu man in the middle. W kilku aplikacjach stwierdzono przeprowadzanie uwierzytelniania oraz komunikację z serwerem otwartym tekstem.
W jednej przejście w ten tryb następowało w razie nienawiązania bezpiecznego połączenia. To mogło zostać wykorzystane przez hakera, który poprzez celowe zakłócanie transmisji wywoływałby ten tryb, żeby przeprowadzić atak man in the middle i podsłuchać albo zmienić przesyłane dane.
Do kategorii M4 zaliczane są przypadki niewłaściwie przeprowadzanego uwierzytelniania. Wykryto je aż w 18% testowanych aplikacji. Nieprawidłowości polegały na: niewłaściwym zarządzaniu sesją, niesprawdzaniu hasła przy interakcji z serwerem lub urządzeniem, nawet w czasie wykonywania operacji o znaczeniu krytycznym oraz szyfrowaniu haseł metodami, które nie zapewniają już odpowiedniego poziomu bezpieczeństwa, jak MD5, a nawet base64.
Twórcy prawie jednej czwartej aplikacji (24%) wykazali się niefrasobliwością w zakresie implementacji funkcji kryptograficznych (M5). Na przykład w dwóch z nich wykryto identyczny fragment kodu. Jak się potem okazało, został on zaczerpnięty z tego samego źródła, którym był ogólnodostępny portal dla programistów. Co gorsza, zapisano w nim w otwarty sposób wartość wektora inicjalizującego, która miała pozostać niezmienna, chociaż prawidłowo powinna być unikalna dla każdej operacji szyfrowania.
M6, M7
Do kategorii M6 zaliczane są przypadki niewłaściwie przeprowadzanej autoryzacji. Z kolei M7 obejmuje dużą grupę niedociągnięć, które są przyczyną słabej jakości kodu aplikacji klienckiej. Dotyczą one m.in. nieefektywnego zarządzania pamięcią czy nieprzestrzegania dobrych praktyk w zakresie obsługi wyjątków.
Ponieważ wiele mobilnych HMI dopuszcza wgrywanie, pobieranie oraz zapisywanie projektów w postaci archiwum .ZIP, postanowiono zbadać także, czy występuje w nich luka typu directory traversal. Polega ona na oparciu się na nazwie pliku podanej w archiwum, bez sprawdzenia, czy nie zawarto w niej znaków specjalnych wykorzystywanych w zapisie ścieżek relatywnych.
Może mieć to poważne konsekwencje, jeżeli bowiem w nazwie pliku zapisano odwołanie do katalogu nadrzędnego lub innego miejsca, zaś aplikacja nie została przed tym zabezpieczona, zostanie on tam rozpakowany. W ten sposób atakujący jest w stanie nadpisać konkretny plik, o ile oczywiście z poziomu aplikacji zapis w danej lokalizacji jest dopuszczalny.
W ramach eksperymentu specjaliści z Embedi i IOActive dokonali ataku na jedną z aplikacji mobilnych o funkcjonalności HMI. Umożliwiała ona pobranie z serwera archiwum .ZIP, bez prawidłowo zaimplementowanego sprawdzenia, czy jego adres jest właściwy. W rezultacie w ramach ataku man in the middle badacze spowodowali, że za jej pośrednictwem z fałszywego serwera pobrane zostało odpowiednio przez nich przygotowane archiwum.
Po jego rozpakowaniu okazało się, że zgodnie z planem został zmieniony obrazek, który przedstawiał instalację sterowaną za pomocą tej aplikacji. I chociaż na pierwszy rzut oka wszystko wyglądało tak jak wcześniej, ze schematu został usunięty jeden z ważnych wskaźników. To wprowadzało operatora w błąd co do rzeczywistego stanu instalacji. Blisko jedna trzecia przetestowanych aplikacji miała luki zaliczane do kategorii M7.
