Czasem komuś ufamy i powierzamy nasze skarby. Bank pilnuje naszych pieniędzy, menedżer haseł pilnuje naszych haseł. Czasem jednak okazuje się, że mogliśmy się bardzo mocno pomylić i nasze zaufanie ulokować w złych rękach.
Świat kryje w swoim wnętrzu wiele tajemnic. Pełno niewyjaśnionych zagadek, do których odpowiedzi ciężko się dokopać przez gęste, lepkie błoto półprawd i częściowych odpowiedzi. Prawdopodobnie już nigdy nie dowiemy się, gdzie znajdują się pieniądze za las, kto jest autorem tej piosenki albo jak wyrównać CSS-em element HTML jednocześnie w pionie i poziomie. Co dziwniejsze, istnieją sytuacje zupełnie przeciwne – na widoku leży coś, co powinno zwrócić uwagę wielu, ale nie zainteresowało nikogo. Do czasu. Tak też stało się z aplikacją na iOS KeePassMini, która wesoło podchodziła do kwestii prywatności danych użytkownika.
KeePass KeePassowi KeePassem
Na początek drobna uwaga – KeePassów na świecie jest mnogo. Istnieje chociażby klasyczny (acz brzydki i bardziej pod Windowsa niż pod cokolwiek innego), wersja XC (wyglądająca świeżo i działająca na każdym komputerze) albo jeszcze osobna apka pod Androidy. Cały sekret jest w tym, że swojego własnego klienta kompatybilnego z KeePassem może napisać każdy. Nie zrażajcie się więc do całego ekosystemu, jeżeli przeczytacie, że jedna z tych aplikacji okazała się trefna.
Co się stało?
21 kwietnia użytkownik Pinting opublikował na Reddicie niepokojący wpis, w którym stwierdził, że ktoś próbował zalogować mu się do konta w banku. Po obdzwonieniu placówki, przeskanowaniu komputera antywirusami oraz zaktualizowaniu aplikacji na Jabłuszku zauważył, że KeePassMini, owszem, znajduje się na jego telefonie, ale apki nie ma już w App Store. Tak się jednak złożyło, że aplikacja była otwartoźródłowa, więc możliwe, że autor umieścił w repozytorium stosowne wyjaśnienia. Faktycznie, na GitHubie projektu znalazła się informacja, że przyczyną zdjęcia aplikacji ze sklepu było naruszenie regulaminu App Store – posiadanie wyrażenia iOS w nazwie.
Pinting przy okazji postanowił rozejrzeć się po kodzie i dość szybko dokopał się do funkcji, która miała wykradać zawartość schowka z telefonu.
Wieściami podzielił się też @ghidraninja na Twitterze.
Faktycznie, kod źródłowy jasno wskazywał na to, że zawartość schowka gdzieś sobie szła:
Twórca się broni
Po rozkręceniu afery autor programu, Frank Hausmann, zresetował repozytorium na GitHubie, aby pozbyć się śladów Anny (bo tak nazwano moduł analityki). Teoretycznie więc dostępna była tylko najnowsza wersja kodu pozbawiona modułu śledzenia.
Co jednak raz trafi do sieci, to nigdy już z niej nie zniknie, chyba że to BIOS do starej płyty głównej.
Pinting w kooperacji z DerEchteJoghurt utworzył zapasowe repozytorium z przywróconą historią zmian menadżera, a my utworzyliśmy zapas tegoż zapasu.
Twórca po jakimś czasie wściekł się jeszcze bardziej, przez co obecnie zamiast kodu źródłowego dostępne są tylko gorzkie żale.
Szybka analiza repozytorium
Na podstawie samego kodu trudno jest mi w zasadzie stwierdzić, czy wysyłanie zawartości schowka to nieprzemyślana decyzja, wypadek przy pracy czy celowe i złośliwe działanie autora. Nawet nasz mBank wysyłał Gemiusowi salda rachunków swoich klientów, więc takie incydenty się już zdarzały. Jedyne, co mogę stwierdzić, wertując commity, to to, że projekt nie był prowadzony zbyt profesjonalnie. W oczy aż kłują wiecznie powtarzane nazwy commitów, co powoduje spory bałagan i dezorientację.
Co i rusz przewijają się dziwne zmiany: dodawanie pustych linijek, wyłączanie pojedynczych linijek kodu, zamiana słów na jakieś pomylone dziwadła albo usuwanie wzmianki o DeepL, która przypadkiem dorzuciła się do README.
Zrzuty powyżej przedstawiają kilka wybranych commitów (wszystkie można powiększyć, klikając). Rozumiem, czasem wypada coś poprawić na szybko, ale takie zmiany pojawiają się w tym repozytorium jedna po drugiej. Trochę bez sensu.
Opuśćmy bańkę GitHuba
Temat samego repozytorium już został, moim zdaniem, wyczerpany. Można zatem przejść spokojnie do analizy domeny, do której dane analityczne miały być wysyłane.
Strona UniCom EDV wydaje się na pierwszy rzut oka całkiem normalną stroną. Ot, jakaś oferta usług MS Office i VoIP, tylko że po niemiecku. Jednakże znowu czuć tutaj powiew amatorszczyzny. Część witryny jest tak naprawdę tylko osadzonym obrazkiem (i to takim, który ma narysowane przyciski, ale nigdzie nie linkuje), a na dole znajduje się reklama jeszcze innego biznesu.
W zakładce „O nas” widnieje wzmianka o dyrektorze zarządzającym Montgomery Müllerze.
Ten sam pan był powiązany z Black Diamond Suxess – piramidą finansową, o której więcej możecie poczytać tutaj.
Po wymieszaniu wszystkich składników tej KeePassowej sałatki otrzymujemy menadżer haseł, który miał wysyłać dane analityczne (w tym schowek!) na serwer należący do jakiegoś biznesu IT dla firm, którego dyrektor wcześniej był powiązany z piramidą finansową (!!).
Trudno jest mi uwierzyć w pokrętne tłumaczenia autora aplikacji (o czym zaraz), ale jednocześnie jedynym dowodem na rzekomą kradzież danych są jakieś dwie próby zalogowania się do banku. Jednakże obrażanie się autora na cały świat na pewno nie przysparza mu zaufania.
Róbcie sobie sami!
Po drugim resecie repozytorium można było znaleźć jedynie dwa pliki ReadMe (bo konto w ciągu tego pół roku zdążyło już zniknąć, dzięki Adam!). Pierwszy – zupełnie pusty i na dodatek z literówką w nazwie, drugi za to przeszedł 8 iteracji różnych drobnych poprawek.
Koniec końców, autor zapewniał, że:
- żadne dane nie były wysyłane na jakiekolwiek serwery,
- serwer analityki nigdy nie działał,
- żadne dane nigdy nie były przechowywane,
- jeżeli jakiekolwiek dane byłyby wysyłane, to byłyby one zaszyfrowane (tylko co to zmienia?),
- chodziło tylko o to, aby poprawić użytkownikowi korzystanie z aplikacji (stąd zbieranie informacji o języku),
- użytkownik miał prawo wyłączyć tę analitykę (która i tak rzekomo nie działała?).
Ale żeby było zabawniej, Frank Hausmann obraził się na cały świat, a potem nawrzucał autorowi odkrycia. Hurr durr, jak to, robię coś kilka godzin tygodniowo i nikt tego nie docenia???
To w końcu kradł, czy nie kradł?
W tej sprawie istnieje za mało dowodów, żeby stwierdzić to na 100%. Na pewno za podejrzane można uznać (pośrednie, ale jednak) powiązanie KeePassMini z piramidą finansową. Z drugiej strony mamy tylko jedno zgłoszenie o tym, że ktoś komuś próbował się zalogować na konto, a jednocześnie korzystał z tejże aplikacji. Całą sprawę można zatem potraktować jako nierozwiązaną, chociaż zawierającą historię z morałem.
Publikowanie źródeł aplikacji na GitHubie jest super, bo przecież każdy na pewno przejrzał kod aplikacji, prawda? PRAWDA?
Pobierając aplikacje z Google Play czy AppStore, nie mamy absolutnie żadnej pewności, że ta aplikacja to dokładnie ten sam kod, co dostępny w publicznych repozytoriach. W tym wypadku tak się złożyło, że kontrowersyjny kod także był publiczny, ale wcale być nie musiał!
Frazy w opisach aplikacji „open source” zachęcają do pobrania tychże aplikacji, ale nie znaczą w żadnym wypadku, że takie apki są bezpieczne. Co prawda, im popularniejsze repozytorium, tym większa szansa na to, że ktoś coś wyłapie. Niestety bywa też tak, że „każdy patrzy, ale żaden nie widzi”. Dlatego pozostaje założyć foliową czapeczkę i zapisywać hasła kredą na ścianie. Albo korzystać z aplikacji, które faktycznie przeszły konkretne audyty bezpieczeństwa.
Mam apkę KeePassMini/iOSKeePass. Co teraz?
Na pewno musisz zaopatrzyć się w nową aplikację, gdyż KeePassMini został wycofany przez autora. Solidną propozycją wydaje się KeePassium (całkiem popularna aplikacja wg gwiazdek na GitHubie, wygląda więc obiecująco).
Ponadto, jeżeli faktycznie zakładamy, że schowek był wykradany, to należałoby pozmieniać hasła do wszystkich kont zapisanych w bazie danych. Będzie to robota żmudna i smutna, ale przynajmniej będzie można spać ciut spokojniej.
Można też zastosować podejście „firma zrobi to najlepiej” i zacząć korzystać z chmurowego menadżera haseł. Ma to również swoje wady, więc najlepiej jest usiąść i przemyśleć to na spokojnie.
Ewentualnie, można skorzystać z rozwiązania hybrydowego i postawić chociażby chmurowego Bitwardena na swoim prywatnym serwerze. Możliwości jest wiele, kwestia tego, co Czytelnik uważa za najlepsze dla swoich zastosowań.
Komentarze
Głównym celem ruchu open source / free software wcale nie jest bezpieczeństwo, ale udostępnienie użytkownikom kontroli nad oprogramowaniem, z którego korzystają. Życie codzienne jest coraz bardziej oparte na różnych programach, chodzi o to żebyśmy wiedzieli, jak one działają i mogli je modyfikować, jeśli zajdzie taka potrzeba.
Powinno to doprowadzić do zaniku funkcjonalności nieprzyjaznych użytkownikowi, jak np. różnego rodzaju ograniczenia cyfrowe.
Jednak to nie przypadek ze najlepsze zabezpieczenia opieraja sie na transparentnych, deterministycznych, werifikowalnych i zdecentralizowanych rozwiazaniach open-source, ktore zawsze sa do wgladu dla kazdego
Najwieksza wada security by obscurity – niejawnych zabezpieczen jest to ze zawsze stoi za tym jakis nieweryfikowalny z zalozenia czlowiek o nieokreslonych motywacjach politycznych, etycznych, religijnych, etc.
Ktoś nieprzypadkowo przegrał dwie wojny światowe…
jakie obie? może pierwszą, ale drugą tylko militarnie i tylko na krótko: jedyny europejski bank centralny nie okradziony z rezerw złota podczas 2 wojny to NBP. Plan marszala, cud gospodarczy (powrót skradzionych rezerw), EWG i mamy główny filar EU
Przegrani to byli na prawo od żelaznej kurtyny …
Mitem jest też przekonanie ze płatne i zamknięte= bezpieczne. Tak samo jak mitem jest ze oss to gwarancja czegokolwiek (jakość kodu, bezpieczenstwo, cokolwiek).
Moim zdaniem otwarty kod to jednak zaleta, niezależnie od tego czy to kod bezpieczny, dobrze napisany czy też nie.
W zasadzie zarówno w przypadku otwartych jak i zamkniętych rozwiązań przeciętny użytkownik zupełnie nic nie może, bo się nie zna.
Ale ostatecznie lepiej, że jest nawet teoretyczna możliwość „zajrzenia pod maskę ” produktowi niż gdy po prostu jej nie ma wcale. Wtedy pozostaje tylko bazowanie na wierze i zaufaniu do dowolnego producenta softu.
„Mitem jest też przekonanie ze płatne i zamknięte = bezpieczne.”
Zgadzam się, jednak dodam, że:
– mitem jest również przekonanie ze darmowe i otwarto źródłowe = bezpieczne, przykład:
Corrupted open-source software enters the Russian battlefield
A programmer behind the popular open-source npm program node-ipc poisoned it with malware that erased the hard drives of computers located in Russia or Belarus.
https://www.zdnet.com/article/corrupted-open-source-software-enters-the-russian-battlefield/
– mitem jest również przekonanie, że audyt gwarantuje bezpieczeństwo, przykład:
Arthur Andersen
https://pl.wikipedia.org/wiki/Arthur_Andersen
Arthur Andersen LLP – globalna firma z siedzibą w Chicago, świadcząca usługi audytorskie i doradcze, istniejąca w latach 1913–2002. Jedna z firm tworząca tzw. wielką piątkę.
Firma ta została oskarżona o pomoc w ukrywaniu długów oraz fałszowanie sprawozdań finansowych w procesie dotyczącym upadku przedsiębiorstwa Enron
Open source i posiadanie audytu to plusy, ale trzeba patrzeć również na inne czynniki aby ocenić bezpieczeństwo danej aplikacji.
„Co jednak raz trafi do sieci, to nigdy już z niej nie zniknie, chyba że to BIOS do starej płyty głównej”
Made my day :-)
Ciekawe jak wiele było pobrań takiej apki. Gdyby z podobnym problemem wyskoczył taki np. Keepass2Android to twórcy ładnie by mogli się nasycić danymi.
Nie rozumiem jednego: jak ktoś powiązał hasło (przesłane, bo było w schowku i przesłane w danych „analitycznych”) do loginu i nazwy banku, które były potrzebne, aby wykorzystać hasło? (wiedzieć na której stronie użyć przechwycone dane)
Brakuje mi podsumowania z jednoznacznym wnioskiem na końcu artykułu zrozumiałego dla przeciętnego użytkownika. Część z nich pojawiła się na początku artykułu, ale takie podsumowanie było by najlepszą formą dotarcia z praktyczną wiedzą co w danym wypadku robić.
1. KeePass to bardzo dobry program a ten artykuł dotyczy tego, że ktoś go zmienił i upublicznił swoją wersję. Nie dotyczy oryginalnego produktu.
2. Oryginalny produkt można pobrać z poniższej strony.
https://keepass.info/
3. Jest brzydki to fakt, ale jego kod został sprawdzony przez EU-FOSSA, organ działający pod auspicjami Komisji Europejskiej.
Wniosek jest taki, że to jest bezpieczny produkt.
https://joinup.ec.europa.eu/sites/default/files/inline-files/DLV%20WP6%20-01-%20KeePass%20Code%20Review%20Results%20Report_published.pdf
Minusem jest to, że przegląd przez organ KE dokonano w 2016r. Oczywiście można poszukać raportów innych instytucji, urzędów które dokonały podobny przegląd kodu KeePass, ale nieco później. Ten podaję to jako przykład.
Na poniższej stronie zaniepokoił mnie fakt, że takie przeglądy nie są już prowadzone a ostatni był dokonany na kodzie KeePass.
https://joinup.ec.europa.eu/collection/eu-fossa-2/code-review-log
Być może nie potrafię odnaleźć właściwej/nowej strony z przeglądami. Jeśli to zostało zarzucone to może siła zespołu Z3S wpłynie na wznowienie tego typu praktyk przez UE, które są tak bardzo ważne.
P.S.
Dziękuję Z3S za ten tekst i ogólnie za działalność :)
@Inte Ja dziękuję Tobie za podsumowanie artykułu i zwrócenie uwagi na audyty kluczowych aplikacji wrażliwych. Świetny pomysł by zadziałać w sprawie regularności audytów. KeePassXC, gnupg, bitcoin, zcash a może nawet kluczowe fragmenty lub całe systemy operacyjne: OpenBSD, AlpineLinux mogłyby doczekać się takiego przeglądu.
Też dziękuję za świetny komentarz
Jak ktoś akceptuje używanie aplikacji bez dostępnego kodu źródłowego to mocno polecam Strongbox na iOS. Apka jest świetna – znakomicie działa z plikami z KeePass, jest mocno rozwijana i ma masę świetnych rozwiązań – jak np. „virtual keys” które pozwalają na emulację Yubikeya jako dodatkowego składnika do otwierania plików KDBX.
> Ponadto, jeżeli faktycznie zakładamy, że schowek był wykradany, to należałoby pozmieniać hasła do wszystkich kont zapisanych w bazie danych.
Powodzenia w zmienianiu (jak u mnie) ~80 haseł, w tym najbardziej upierdliwych – bankowych xD