10:04
24/6/2010

Hiszpański odpowiednik FBI bada sprawę firmy, która celowo wprowadzała błędy programistyczne w sprzedawanej przez siebie aplikacji. Kiedy program się zawieszał, klient musiał skorzystać z płatnej pomocy technicznej. Brzmi jak wspaniały business-model, prawda?

Bomby czasowe

Stosowaniem “czasowych bomb” (ang. time-bomb) hiszpańska firma o uroczej nazwie CIPSA, wydymała 1000 klientów ;-) Kiedy nadchodził zdefiniowany w programie czas, aplikacja wysypywała się i polecała skorzystać z supportu — oczywiście płatnego. Ten błąd naprawiał, ale do systemu wprowadzał kolejny błąd…

Sielanka firmy trwała od 1998 roku. Po anonimowym zgłoszeniu, sprawą zajęło się hiszpańskie FBI i CIPSY dostały wyroki. Jedno mnie zastanawia, firma przez 10 lat dorobiła się tylko 1000 klientów? Ten soft musiał się cieszyć naprawdę dobrą opinią :>

Popularna praktyka programistów?

Kilku internautów komentujących to wydarzenie przyznało się do stosowania czasowych bomb w swoich programach. Pierwszy z przypadków dotyczył sprzedaży oprogramowania do afrykańskiego kraju, który wymigiwał się od zapłacenia za program w całości (tłumacząc się, że nie przynosi on przewidywanych zysków). Drugi dotyczył programisty, którego klient co chwila prosił o nowe funkcje, ale z płatnościami spóźniał się przez kilka miesięcy. W obu przypadkach aktywacja bomby spowodowała natychmiastową spłatę zaległości

P.S. Jak mi ktoś w komentarzach napisze, że gdyby ten soft był Open Source, to nie byłoby takiego problemu, to polecam do analizy poniższy fragment “otwartego” kodu:

*(&z + z) |= ~tqq + m ? u9 >> 2: 741 | w & 0x8F ? ~(~t11) : foo

Od razu wiadomo, o co chodzi, prawda? :-)


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

24 komentarzy

Dodaj komentarz
  1. To oczywiste, że problem dalej by był. Sprzedawałem już soft opensource, zgadnij, czy klient zaglądał do źródeł? Pewnie dlatego zatrudnili kolesia do pisania. :)
    A propos klientów, jeśli sprzedajesz na przykład soft klasy ERP, ERPII, to tysiąc klientów jest moim zdaniem dość sporą liczbą. Koszt oprogramowania może sięgnąć kilkuset tysięcy euro, włącznie z wdrożeniem w dużej firmie może przekroczyć miliony.

  2. Ten Open Source’owy przykład to coś z Klingońskiego? :)

    No ale pomysł na biznes goście mieli niezły :) Ciekawe ilu takich biznesmenów mamy w kraju :)

  3. 1000 klientów to może być sporo – wszystko zależy od tego jakie to było oprogramowanie.

    Przykładowy kod jest strasznie zaciemniony i tylko fragmentaryczny – wątpię czy jakikolwiek projekt open source przyjął taki kod.

  4. Nasunęło mi się skojarzenie w związku z P.S.em:
    http://en.wikipedia.org/wiki/Obfuscated_Perl_Contest
    I jak tu nie wierzyć, że ten język powstał przez rzucenie kotem na klawiaturę…

  5. vi.curry pracuje w korpo, które sprzedaje 1000 licencji na soft dziennie, więc ma trochę zaburzony punkt odniesienia ;P

  6. swoja droga, ciekawe, czy np. microsoft nie wprowadza do zrodel exploitowalnych bledow na zlecenie NSA/CIA, etc — nikt nie moze ich wtedy oskarzyc o instalowanie backdoorow, a efekt jest ten sam :)

  7. @PK. Można pracować gdziekolwiek, ale horyzonty myslowe zachowac w miare ogólne. Te “hiszpańskie FBI” to też jakiś dziwny tekst, jakby punktem odniesienia było oglądanie seriali kryminalnych.

  8. @zaciemniony przykład

    Nazwa jednej ze zmiennych sugeruje, że przykład jest sztuczny. No chyba, że ktoś się zasugerował lekturą podrecznikow i zaczął w praktycznym kodzie nazywać zmienne foo i bar. :)

    Nie trzeba zaraz takiego bełkotu. Wystarczy, że kodu jest dużo, zależności jest dużo i do ogarnięcia potrzeba wiele czasu. Można celowo zabugowac kod, który wygląda “czysto”. Nie musi to być jakiś wskaźnikowy, obfuscatorowy hardcore.

  9. To już teraz wiem po co są(rekrutacja) konkursy na złośliwy kod wyglądający możliwie poprawnie i prosto, tak, że nawet jakby ktoś błąd znalazł to można się wytłumaczyć jakimś częstym błędem.

  10. Taki błąd pewnie można łatwo wprowadzić. Wystarczy instrukcja warunkowa, gdzie “omyłkowo” użyje się zamiast operatora porównania operator przypisania. = zamiast == Ot – literówka.

  11. Ja uwielbiam takie dawniejsze, niesamowicie przejrzyste programy:
    http://tajemnice.atari8.info/8_91/czekaj.gif

  12. Pomysł na biznes nie zbyt błyskotliwy. I na pewno niezbyt etyczny.

    Nie wiem, ale wydaje mi się, że bardzo duży odsetek programistów zostawia sobie backdoory. Raz, to z poczucia satysfakcji a dwa, że może to rzeczywiście być to dobry bat na niewypłacalnych.

    Ale co innego backdoor a co innego specjalnie zostawiony bug by wyłudzić kolejne pieniądze.

    Dlaczego napisałem, że to niezbyt błyskotliwy pomysł? – Myślę, że takie rozwiązanie przynajmniej raz przyszło do głowy każdemu tyle, że nie każdy od razu ma zamiar to wykorzystać.

  13. przeciez microsoft to samo robi. W dodatku myslicie dlaczego systemy operacyjne wypuszczane tak często (srednio co 2 lata) – zamiast dopracowac w pelni system – chodzi o kase. Firmy wykupują support bo ciągle cos sie w nich sypie..

  14. o wlasnie “pytajnik” wyjał mi słowa spod palcy! wystarczy wiecej wyrafinowania i przekret jest juz “legalny”

  15. @pytajnik
    Masz rację! To oburzające aby komercyjna firma chciała zarobić! Powinni brać przykład z open source i wydawać nowe wersje tak rzadko jak np. robi to Canonical Ltd z ich systemem! I nie powinni dodawać exploitowalnych fragmentów kodu! Ponownie, niech biorą przykład np. z FreeBSD czy OSX w których błędów exploitowalnych nie uświadczysz! Im chodzi tylko o kasę…

    ;DDDDDD

  16. Piotrze: ale ten kod OpenSource przynajmniej MOŻESZ przeanalizować (bez sięgania do assemblera). Poza tym byle uczniak jest wstanie powiedzieć, co tam jest w tej linijce ;) Co ona robi – tego nie da się powiedzieć bez znajomości reszty kodu.

  17. Niestety obawiam się, że to co robiły CIPSY to dość częsta i powszechna praktyka. Co więcej, stosowana z całej masy przyczyn:
    – przez firmy uczciwe inaczej (jak w przypadku opisanym),
    – przez firmy mające podpisane stosowne umowy z agendami rządowymi (dotyczy dużych korporacji, które bronią w ten sposób takiego czy innego “bezpieczeństwa narodowego”),
    – przez programistów, którzy nie widzą innej szansy na zapewnienie, że pieniądze za swoją pracę jednak otrzymają… (nawet murarze mają podobny patent: wmurowują kurze jajo w sobie znane miejsce w ścianie np. salonu w domu klienta.. jeśli ten ich wyrzuci i nie zapłaci.. zapominają o jaju.. zgadnijcie co się dzieje w takim salonie za jakiś czas? ;-))))

    • Już dawno nie słyszałem tej bajki o wmurowywaniu jajka ale jednak się uchowała :)

    • a jak im zapłaci to kują mu salon i wkładają poprawną cegiełkę bez jaja, malowanie i gładzie tak ot gratis drugi raz? :-)

  18. […] Nota bene, na programistów też warto uważać — lubią zostawiać tzw. bomby czasowe w kodzie… […]

  19. I co, teraz wszyscy się oburzają jak to źle?
    A jak producenci różnego rodzaju sprzętu robią tandetę albo specjalnie dają jakiś jeden element, który łamie się zaraz po gwarancji to co innego jest??

  20. Phi, wielki mi przekręt… po prostu kontrolowana trwałość produktu, jak ze wszystkim co dzisiaj się produkuje, zaczynając od żarówek, na samochodach kończąc. Nihil novi :)

  21. Kontrolowana trwałość? W sumie coś w tym jest. Jak sprzedajesz coś z wieloletnimi aktualizacjami to niestety trzeba liczyć się z tym, że klient zapłaci raz i ma produkt na wiele lat. Minus jest taki, że trzeba wciąż szukać nowych klientów, co na ograniczonym rynku (np. niszowym) prowadzi do bankructwa firmy producenta. Z drugiej strony wkładanie “bomb czasowych” do softu to chwyt poniżej pasa i powinno być piętnowane.

    Choć co do zabezpieczenia oprogramowania w przypadku opóźnionych płatności? Niestety są przypadki, że jest to wręcz konieczne. Sam stosowałem zabezpieczenia czasowe, ale z informacjami – wersja wygasła czy cos w tym stylu. Albo autoryzacja przez sieć przy każdorazowym uruchamianiu. Wtedy miałem największą szansę na uzyskanie płatności za program. Ten system się sprawdza, bo w przypadku jego braku można się liczyć praktycznie z brakiem zapłaty.

    Praktycznie za każdym razem gdy klient chciał płacić później a system był wyposażony w opcję weryfikacji czy system pracuje legalnie (opłacony), odpowiedni komunikat i blok programu się sprawdził. Niestety, bo monity i pisanie wielu maili i pism nie działa tak dobrze jak blok.

    Oczywiście zabezpieczenia tez można przełamać (np. oszukać serwer autoryzacyjny), więc niestety są przypadki, że trzeba poświęcić więcej czasu na tego typu kwestie. Zetknąłem się parę lat temu z sytuacją, iż miałem system zabezpieczający (podstawowy) i niestety właśnie został przez cwaniaka “przełamany” poprzez fałszywy serwer. Projekt się nie zwrócił (gość korzystał z wersji komercyjnej bez zapłaty), koszty spore, postępowanie ws. cwaniaka prowadzone nieudolnie przez parę lat i w końcu umorzone – tak właśnie wygląda “wspieranie twórców przez państwo”.

    Więc w sumie trudno się dziwić niektórym, że idą na łatwiznę i robią robaki w sofcie. przynajmniej nie muszą się martwić za co zapłacić podatki i rachunki w nast. miesiącu :P

  22. […] Linusa, IPSec w OpenBSD, TPM-a w Windowsie 8, a backdoory w oprogramowaniu znanych firm to jak przyznają sami programiści — często celowe zagranie.. Przywołajmy chociażby drukarki Samsunga, macierze HP, loadbalancery F5, routery D-Linka czy […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: