Tag: security

Opublikowane w

Uroki korzystania z telefonu starego typu na przykładzie pobierania aplikacji moBILETu

Od początku lipca zmieniły się ceny biletów w Poznaniu[1]. Jestem przekleństwem sprzedawców telefonów GSM i od 6 lat mam niezawodny telefon Nokia 3110c. Z Javą. Bateria od początku ta sama, trzyma tydzień, ale mniejsza. Próbowałem zaktualizować cennik dla Poznania – system wykonał błąd itp. komunikaty. „OK, bywa” – myślę. Spróbowałem parokrotnie, w różnych dniach – to samo. Stwierdziłem, że zaktualizuję aplikację, tym bardziej, że w sumie nie wiem, czy to mój system wykonał błąd, czy moBILETu.

Przypomnienie hasła działa OK, teraz możesz się zalogować. Natomiast loginu nie sposób przypomnieć, a zalogować można się tylko jednym, wybranym kiedyś sposobem i może to być numer telefonu, adres email (który?), login (jaki?). A może błędne hasło, bo jeszcze coś się nie zaktualizowało? Nie wiadomo, bo komunikat to Niepoprawne hasło lub nazwa użytkownika. Proszę sprawdzić wpisywane dane. Skądinąd słuszny, ale czemu nie ma możliwości przypominania loginu? Np. wysyłanie go na adres email podany w systemie (hasło można przypomnieć tylko na komórkę, więc wysyłanie loginu na komórkę to słaby pomysł w przypadku jej przejęcia).

OK, w końcu zalogowałem się. Wybieram pobranie aplikacji, przepisuję CAPTCHA. Bo nie ma po prostu „pobierz”, jest personalizowany, unikatowy link, pod konkretny model telefonu (moBILET ma te dane u siebie) ważny 30 minut[2]. Kiedyś przysyłano SMS pobierający aplikację od razu na komórkę. Teraz nie. Zwykły SMS z linkiem. O takim: http://p.mobilet.info/ota/m/?DQ2OFQPTHN Zastanawiam się, jaki piękny umysł na to wpadł. Po pierwsze, na telefonach starego typu nie ma multitaskingu, więc trzeba gdzieś zapisać na boku. Po drugie, klepanie 43 znaków klasy wielkie, małe litery i znaki specjalne na komórce starego typu (a wiedzą, komu wysyłają linka) to szczyt ergonomii.

I część najlepsza: po dobraniu się do linka dostajemy Server not found (to już komunikat z desktopa). A czemu? Ano temu, że domena p.mobilet.info nie istnieje. Gwoli ścisłości, mobilet.info też nie istnieje. I wygląda na domenę dostępną do rejestracji. Ciekawe czy byłby to dobry sposób rozsyłania malware’u?

Normalnie wronan groteska! A bilet muszę kupić papierowy.

[1] Na absurdalnie drogie, więc korzystam z tego, że nie muszę korzystać z komunikacji miejskiej i poruszam się inaczej, głównie pieszo/rower, a z moBILETu nie korzystam już praktycznie, ale warto mieć bilet pod ręką. Nie to jednak jest przedmiotem notki.

[2] Można to (było) obejść o czym pisałem w notce o zabezpieczeniach moBILETu, ale zachowujmy się jak cywilizowani ludzie.

Opublikowane w

Microsoft blokuje No-IP

Krótka lekcja nt. neutralności sieci w praktyce. Zaglądając na stronę popularnego operatora domen, w szczególności jednego z bardziej znanych dostawców darmowych domen dla osób z dynamicznym IP, można dziś zobaczyć taki komunikat:

 No-IP warning

Pod pretekstem wykorzystywania domen przez twórców malware (co z pewnością miało miejsce, malware korzysta z czego się da…), na mocy nakazu sądowego, Microsoft zajął 22 domeny. Zgodnie z tym, co pisze No-IP, nie było żadnego wcześniejszego kontaktu w celu usunięcia „złych” domen. Co ciekawe, No-IP utrzymuje aktywny zespół abuse, ma surową politykę przeciwko nadużyciom i… ma historię dobrej współpracy z Microsoftem w reagowaniu na podobne nadużycia.

Najwyraźniej komuś nie zależało, by z tego skorzystać. Duży może więcej.

Poniżej kopia oświadczenia wydanego przez No-IP w tej sprawie (stan na godzinę 8:00):

We want to update all our loyal customers about the service outages that many of you are experiencing today. It is not a technical issue. This morning, Microsoft served a federal court order and seized 22 of our most commonly used domains because they claimed that some of the subdomains have been abused by creators of malware. We were very surprised by this. We have a long history of proactively working with other companies when cases of alleged malicious activity have been reported to us. Unfortunately, Microsoft never contacted us or asked us to block any subdomains, even though we have an open line of communication with Microsoft corporate executives.

We have been in contact with Microsoft today. They claim that their intent is to only filter out the known bad hostnames in each seized domain, while continuing to allow the good hostnames to resolve. However, this is not happening. Apparently, the Microsoft infrastructure is not able to handle the billions of queries from our customers. Millions of innocent users are experiencing outages to their services because of Microsoft’s attempt to remediate hostnames associated with a few bad actors.

Had Microsoft contacted us, we could and would have taken immediate action. Microsoft now claims that it just wants to get us to clean up our act, but its draconian actions have affected millions of innocent Internet users.

Vitalwerks and No­-IP have a very strict abuse policy. Our abuse team is constantly working to keep the No-­IP system domains free of spam and malicious activity. We use sophisticated filters and we scan our network daily for signs of malicious activity. Even with such precautions, our free dynamic DNS service does occasionally fall prey to cyber scammers, spammers, and malware distributors. But this heavy-handed action by Microsoft benefits no one. We will do our best to resolve this problem quickly.

UPDATE: Wpis dotyczący sprawy na blogu no-ip.com został parę razy zaktualizowany. Z tego co zauważyłem, moje domeny zaczęły działać wczoraj, czyli downtime w granicach 36h. Zdarzenie jest przykładem kluczowej roli DNS (domeny, serwery), a w kontekście bezpieczeństwa warto zwrócić uwagę na to, z jakich domen się korzysta.

Opublikowane w

Dziura w OpenSSL, o jakiej się nie śniło

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL