Ochrona przed atakiem na zakupy w aplikacji iOS

Question

System zakupów w systemie Apple na iOS został w przeszłości zaatakowany przez osoby, które oszukały aplikacje, udostępniając je za darmo. Od tego czasu udoskonalili systemy, aby spróbować ograniczyć tego rodzaju rzeczy.

Przeczytałem dokumenty referencyjne StoreKit dostępne w Apple i mam ogólne pojęcie o przepływie pracy i kontrolach, które należy wykonać, i tak dalej. Mogą jednak wystąpić problemy z bezpieczeństwem, których nie znam.

Czy ktoś może podać pełną listę kradzieży, które można podjąć w związku z mechanizmami zakupu w aplikacji, jak deweloperzy mogą omyłkowo dopuszczać takie ataki i jakie są najlepsze praktyki, aby im zapobiegać?

Answer 1

Są to ataki, że jestem świadom, przeszłości i teraźniejszości:

Fałszywy App Store

rozsławione przez rosyjskiego programistę Alexey Borodin, atak ten dotyczy tylko aplikacji, które weryfikują pokwitowania zakupu bezpośrednio z App Store. Modyfikując ustawienia DNS urządzenia i instalując sfałszowane certyfikaty bezpieczeństwa, żądania weryfikacji są wysyłane do fałszywego serwera App Store, który automatycznie zwraca, że ​​zakup jest ważny. Niepodejrzewające aplikacje zaakceptują te wywołania weryfikacyjne i dostarczą zawartość użytkownikowi.

Komentarz

Po tym wykorzystać znane powstał w lipcu 2012 roku, Apple wydał zaktualizowane dokumentację i porady dla programistów, aby zapewnić ten rodzaj ataku nie będzie nadal występować. Borodin został zacytowany w różnych artykułach internetowych jako stwierdzenie, że "gra się skończyła" w oparciu o zaktualizowane API firmy Apple i wskazówki dotyczące najlepszych praktyk.

Zapobieganie

Apple ma cały dokument poświęcony tej luki here. (EDYCJA: Link jest wyłączony, Wayback, jeśli chcesz ... mimo że dokument obejmował iOS 5.1 i wcześniejsze.) Największy wniosek, jaki mają, to wysłanie potwierdzenia na zewnętrzny serwer, który posiadasz, a następnie twój serwer zweryfikuje paragon z Apple. Jeśli jednak wyślesz pokwitowanie bezpośrednio z aplikacji do App Store, zalecamy następujące kontrole:

• Sprawdź, czy certyfikat SSL użyty do połączenia z serwerem App Store to certyfikat EV.
• Sprawdź, czy informacje zwrócone przez funkcję sprawdzania poprawności są zgodne z informacjami w obiekcie SKPayment.
• Sprawdź, czy paragon ma prawidłowy podpis.
• Sprawdź, czy nowe transakcje mają unikalny identyfikator transakcji.

Fałszywy serwer Weryfikacja

Jeśli aplikacja wysyła wpływy transakcji na serwer, który następnie przekazuje je do App Store, jedną z opcji jest dla atakującego do fałszywego serwera weryfikacji. Według niektórych metod (zmiana tabeli DNS, zmiana adresu URL itp.) Paragon jest wysyłany do alternatywnej lokalizacji i zwracana jest "pomyślna weryfikacja".W ten sposób paragon nigdy nie dociera do serwera, a Ty nigdy nie masz szansy sprawdzić go w App Store.

Komentarz

Najwyraźniej istnieje wiele aplikacji w sklepie Cydia, które służą do uruchamiania w tle, monitorowanie ruchu kwit i przekierować go do tego celu. Źródło: Hussulinux Blog

Zapobieganie

Jeśli natychmiast dostarczać treści jak tylko paragon jest weryfikowana, nie jest znany sposób, aby zapobiec tego rodzaju ataku. Weź jednak taki scenariusz: system konta użytkownika jest zarządzany na własnym serwerze. Jeśli celem zakupu w aplikacji jest powiadomienie serwera, że ​​dane konto użytkownika zakupiło produkt, a aplikacja pobiera ten element z serwera, użytkownik jest odporny na atak. Przekierowanie pokwitowania na inny serwer nie przyniesie nic osobie atakującej, ponieważ serwer nigdy nie oznaczy konta użytkownika jako posiadania przedmiotu, ponieważ nigdy nie widzi pokwitowania.

Fałszywe Wpływy

Atakujący może fałszywy proces zakupu, a następnie wysłać sfałszowany pokwitowanie na serwer weryfikacji. W odróżnieniu od poprzedniego ataku, położenie wychodzące paragonu nie ulega zmianie, ale zostaje zastąpione oszustem. Ten sfałszowany paragon jest w rzeczywistości ważnym paragonem z poprzedniej transakcji App Store, a App Store zweryfikuje go jako taki. Przez sfałszowanie procesu zakupu, a następnie wysłanie fałszywego potwierdzenia do serwera, treść nigdy nie jest opłacana.

Komentarz

Widocznie są różne Cydia aplikacji, które wykonują tego typu rzeczy. Możesz wykryć fałszywe wpływy, ponieważ ich numer product_id jest całkowicie inny niż wszystko, co używasz w swojej aplikacji. Najwidoczniej najbardziej znanym sfałszowanym identyfikatorem jest com.zeptolab.ctrbonus.superpower1. Źródło: Hussulinux Blog.

Zapobieganie

W link gdzie znalazłem ten atak, bloger zaleca się rozpakować pokwitowanie na serwerze weryfikacji (base64_decode) i sprawdź product_id przed wysłaniem potwierdzenia do App Store. Jednak w numerze this article Apple zaleca, aby najpierw wysłać potwierdzenie do App Store, a następnie odczytać zwrócone informacje, aby upewnić się, że paragon jest ważny.

(Popraw mnie, jeśli się mylę, ale zalecana przez Apple technika może być również używana do zapobiegania tego typu atakom, nawet jeśli nie masz serwera weryfikacji. Jeśli aplikacja wysyła potwierdzenie bezpośrednio do aplikacji sklep, to może zbadać zawartość odpowiedzi JSON, aby upewnić się, że to ważne. Ale to wykracza przeciwko Apple zaleca najlepszych praktyk z wykorzystaniem zewnętrznego serwera weryfikacyjnego, więc nie popierają go.)

na zakończenie

Są to ataki, o których jestem świadomy, nie krępuj się poprawiać mnie, jeśli się mylę w jakimkolwiek punkcie lub zgłaszać dodatkowe ataki i poprawki.

Na tej stronie znajduje się strona internetowa: http://www.in-appstore.com/, która twierdzi, że umożliwia zakupy w aplikacji za darmo, na iOS 5 lub z jailbreakowanym urządzeniem iOS 6 i jest aktywna od 5 lipca 2013 r.Chociaż nie jestem w 100% pewny, jak to robią, na pewno wiąże się to z przekierowywaniem DNS i fałszywymi certyfikatami bezpieczeństwa, co oznaczałoby Fake App Store lub Fake Verification Server, co dodatkowo sugerowałoby, że nadal istnieją aplikacje, które są nie zabezpieczone przed tymi atakami.

Resources

• Apple iOS in-app purchase hacking
• My Experiences With Verifying In-App Purchase Receipts
• How to detect "IAP Crackers"?

EDIT:

dodatkowe

Wygląda na to, że jedna lub dwie osoby przekręciły się tutaj i uznały ten post za przydatny, i cieszę się.

Istnieje więcej informacji, które można uzyskać na ten temat, albo w innych postach, książkach, lub, jeśli masz zamiar, szorowanie podbrzusza z Internetu. Oto kilka stron internetowych i postów i tak dalej, że chcę się przyjrzeć, ale nie miałem jeszcze okazji. Dodam więcej linków później, gdy znajdę interesujące ciekawostki.

http://www.se7ensins.com/forums/threads/tut-how-to-hack-ios-games-and-apps.701845/ http://www.iapphacks.com/

Kilka bezpośrednich wynos: nie przechowywać dane odtwarzacza w prosty plist chyba że ma to być edytowane przez jakiś nastolatek. Ludzie nie muszą włamywać się do systemu IAP, jeśli mogą po prostu oddać złoto lub coś podobnego, edytując pliki na dysku. Być może szyfrowanie tych plików może zniechęcić pewien segment atakujących.

Na podstawie linku se7ensins wygląda na to, że atakujący może również podważyć twój plik binarny i zepsuć go, aby osiągnąć te same efekty, co edycja pliku plist, lub nawet więcej, ale wymaga to nieco wyższego poziomu umiejętności . Być może ustawienie wykrywania jailbreaku wystarczyłoby, by odstraszyć większość osób, które by się do tego uciekały.

Ta sekcja to w większości spekulacje, ale może pomóc komuś. Rzeczywiście, poziom ochrony, jaki masz, zależy od tego, jak daleko deweloper jest skłonny przejść (w dół króliczej dziury bezpieczeństwa i szyfrowania), aby chronić swoje zyski.