Urządzenia mobilne zyskują coraz większą popularność zarówno wśród użytkowników, jak i autorów aplikacji, także tych “finansowych”. Coraz więcej banków ma w swojej ofercie aplikacje dla urządzeń mobilnych, za pomocą których klienci mogą korzystać z usług swojego banku. Nie mam tu na myśli specjalnych wersji “normalnego” systemu bankowości internetowej w wersji przeznaczonej dla urządzeń mobilnych (w domyśle – inny layout, pewne ograniczenia funkcjonalne, itp.), ale specjalnie przygotowane aplikacje, które są przede wszystkim wygodniejsze dla klienta w użytkowaniu. Często aplikacje takie realizują wyłącznie GUI, cała istotna logika znajduje się po stronie banku, który udostępnia odpowiednie usługi (web service). Problem pojawia się, gdy taka aplikacja zechce przechowywać pewne dane lokalnie, na urządzeniu. Czy jest w stanie przechowywać je bezpiecznie?
W ramach wieczornej prasówki natknąłem się na taką informację: Z serwera Neckermanna wyciekły dane 1,2 mln osób. Trochę rozbawił mnie fragment o “natychmiastowym wzmocnieniu zabezpieczeń serwera”, choć akurat może mieć to sens, bo dane mogły wyciec z innego serwera, niż ten, którego zabezpieczenia wzmocniono, a sam Neckermann może mieć więcej klientów niż 1,2 mln.
Problem z kradzieżą informacji jest taki, że jak już ona wycieknie, to w zasadzie jest pozamiatane. Gdy ktoś ukradnie worek pieniędzy, to można te pieniądze odzyskać. Złodzieje nie mogą zwielokrotnić na ksero banknotów. OK, mogą, ale nie są one pełnowartościowe i raczej nie uda się nimi nigdzie zapłacić. Informacja może być bez problemu zwielokrotniana i z tego powodu nie traci ona swojej użyteczności, choć może tracić na wartości. Można liczyć na to, że informacja ta w pewnej chwili przestanie być aktualna (i dlatego wiele przydatnych “informacji” ma maksymalny czas życia), ale w wielu wypadkach “posprzątanie” po wycieku jest trudne lub praktycznie niemożliwe. W tym przypadku adres e-mail można zmienić, zmiana nazwiska jest już nieco bardziej “pracochłonna” :)
Jestem dość aktywną (fizycznie) osobą. Rower, rolki, nordic walking... Jest też kilka typów aktywności, których nie akceptuję. Jednym z nich jest bieganie. Bieganie może nie jest ZŁE, ale też nie jest tak rewelacyjne, jak się przyjęło uważać. Gdy patrzę na biegających mam mocne przekonanie, że znaczna część z nich (większość?) robi sobie krzywdę. W skrócie – bieganie po twardej nawierzchni (asfalt, chodnik), w dodatku w “wysztywnionej” albo “przegiętej do tyłu” pozycji, to proszenie się o problemy ze stawami, kręgosłupem i mikrourazy mózgu. Oczywiście krzywdę można sobie zrobić również na 100 innych sposobów przy innych aktywnościach ruchowych (a nawet siedząc na krześle – i to chyba jest najbardziej prawdopodobne/rozpowszechnione), ale irytuje mnie obecna dość intensywna promocja biegania... Chcesz biegać? Proszę bardzo, ale rób to z głową. W zasadzie dotyczy to każdej aktywności ruchowej.
Dziś mała refleksja związana z marudzeniem bezpieczników o tym, że biznes jest zły i ich nie rozumie. Informacje na ten temat mam w zasadzie z pierwszej ręki, bo sam tak marudziłem. I w zasadzie coś w tym marudzeniu jest. Z drugiej strony uważam, że działy bezpieczeństwa powinny popatrzeć również na siebie. Proponuję ciekawe ćwiczenie – zapoznanie się z listą błędów poznawczych. A może nawet nie, na początek wersja jeszcze bardziej uproszczona: heurystyka dostępności.
Prywatność to termin, który – w najszerszym znaczeniu – określa możliwość jednostki lub grupy osób do utrzymania swych danych oraz osobistych zwyczajów i zachowań nieujawnionych publicznie.
Ja bym nieco rozszerzył jeszcze to pojęcie. Moim zdaniem z prywatnością powiązane jest również prawo do decydowania o tym z kim i w jakim stopniu swoją prywatnością się dzielę.
Mówiąc “SSL” w rzeczywistości nie mówi się nic na temat wykorzystanego protokołu. Bo może to być równie dobrze SSLv2, SSLv3 lub TLSv1. Do tego dochodzi jeszcze całkiem spora grupa szyfrów, które mogą być wykorzystane w ramach danego połączenia, przy czym nie dla każdej wersji protokołu każdy szyfr jest dopuszczalny. W efekcie czasem pojawia się problem i klient nie może dogadać się z serwerem i zestawić połączenia. Jest to szczególnie irytujące, gdy akurat tym klientem jest twoje ulubione local proxy , a cała sytuacja uniemożliwia rozpoczęcie testów aplikacji...
Z problemem można radzić sobie na kilka sposobów. Można próbować użyć socat (trzeba pamiętać o opcjach cipher i method bo OpenSSL, z którego korzysta socat, sam z siebie również może mieć problemy z wynegocjowaniem parametrów połączenia), można próbować zestawiać kilka narzędzi w łańcuch (np. Burp i Fiddler)... Okazuje się jednak, że można również wpłynąć na wersję protokołu, którą używać będzie Fiddler. Całość sprowadza się np. do jednej linii kodu:
Jedna uwaga: socat może być przydatny wówczas, gdy narzędzia kompletnie nie radzą sobie z SSL. Przykładowo intruder21 ma zwyczaj, by wysyłać żądania wyłącznie jako HTTP, nawet jeśli oryginał korzystał z HTTPS.
Tak tak, “we are feeling confident” to bardzo popularne podejście. A potem jest pożar w burdelu. Albo na produkcję idzie dziurawa aplikacja, bo już “inaczej się nie da”...
Jeśli do tej pory uszło to Waszej uwadze już 23 maja odbędzie się w Krakowie kolejne spotkanie OWASP. Więcej informacji na ten temat można znaleźć oczywiście na stronie polskiego chapteru OWASP, jak również np. tu: [Kraków] Spotkanie OWASP.
Tym razem tematyka nieco inna niż na ostatnich spotkaniach:
Jak zapewne wiecie pojawiła się informacja o skutecznym ataku na przeglądarkę Chrome (np. tu: Dziura i exploit na Google Chrome [0day] i u źródła: Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass). Oczywiście całość okraszona podejściem “wiemy, ale nie powiemy”, a konkretniej “wiemy, ale powiemy tylko naszym klientom, a producent niech sam dziury szuka”. Z drugiej strony pojawiają się informacje, że dziura wcale nie jest w Chrome. I w tym momencie warto spróbować wykonać mały eksperyment myślowy: o co może chodzić.
Była sobie rozróba na stadionie. Nie pierwsza i nie ostatnia. A jej skutki są takie, że znowu mamy prześciganie się w pomysłach odnośnie tego co z tym trzeba zrobić i jak to zrobić. Postanowiłem się do tego strumienia pomysłów przyłączyć.
