Artykuły dotyczące tematu: programowanie

dodany: 11.02.2013 | tagi: , ,

Dzieciaki złośliwie hakują

0

Nie spodziewałabym się, że dzieciaki w wieku ok. 11 lat (a znam takich kilkoro) byłyby w stanie napisać złośliwe oprogramowanie. Mało tego, większość z nich pewnie nie do końca wie, o czym bym do nich mówiła, gdybym zapytała. Ale podchodząc do tematu w ten sposób można by odbić piłeczkę, że nie każdy jedenastolatek wie, kim jest Monster High. Nie zmienia to jednak faktu, że mało który rodzic zdaje sobie sprawę, że jego dziecko w tym wieku może być w stanie napisać złośliwy kod (kwestię geniuszy pomijam).

A być może powinien. Zespół AVG Labs odkrył dowody potwierdzające, że jedenastoletnie dzieciaki są w stanie napisać złośliwy kod – często dla zabawy i zrobienia komuś głupiego kawału. Tylko, że taki głupi kawał może mieć poważne konsekwencje.

hacking-kid1

Źródło: filmzrus.com

Dzieciaki piszą złośliwe oprogramowanie po to, żeby podnieść swoją reputację, „wylansować się”. Młody, gniewny hakier – cała podstawówka jego! Wszyscy grający trzęsą portkami przed kradzieżą loginów i haseł do gier czy drogiego fejsunia. Wydaje się trywialne i śmieszne, ale co w sytuacji, gdy do konta gry online jest „przypisana” karta kredytowa umożliwiająca zakupy w grze? Raport zakłada taką możliwość, ale dotyczy ona małej liczby młodych hakerów. Większości zależy na przechytrzeniu swoich rówieśników i podziwie czule łechczącym ich wyolbrzymione ego.

Eksperci z AVG Labs znaleźli przykład złośliwego oprogramowania napisanego przez jedenastolatka z Kanady. Kod zazwyczaj przybiera formę podstawowego trojana pisanego przy użyciu .NET Framework, który może być na tyle łatwy dla początkujących, co prosty do wdrożenia przez link w wiadomości e-mail czy umieszczenie na wallu na którymś z portali społecznościowych.

Zastanawia mnie tylko jedno – co jest gorsze: niewiedza rodziców czy wyrafinowane możliwości komputerowe takich dzieciaków?

Dziś dzieciaki są od małego wychowywane niejako „przy komputerze”, przykład: niespełna dwulatek maszerujący z płytą CD prosto do CD-ROM-u swojego starszego brata, czy pięcioletnia dziewczynka serfująca po YouTube lepiej niż jej mama.

Zdaje się, że nadszedł czas, aby to rodzice doganiali technologicznie swoje pociechy. A młodym koderom życzę konsekwencji w kodowaniu, bo bycie programistą to nie taka zła robota jest. Oczywiście pisanie złośliwego oprogramowania, a raczej jego wykorzystanie przez dzieciaki powinno być obarczone konsekwencjami, bo jest to przestępstwo, jak każde inne, ale nie chciałabym, żeby po upublicznieniu takich informacji nagle ruszyło pospolite ruszenie rodem z bajki o księdzu Natanku. Wiedzcie, że coś się dzieje!

W dziale wideo znajdziecie świetną prelekcję Mitcha Resnicka, który całkiem logicznie przedstawia korzyści wynikające z kodowania przez dzieciaki.

dodany: 12.10.2012 | tagi: , ,

Bezpieczeństwo aplikacji webowych – wprowadzenie

2
www

Po kilku miesiącach prac nad zaawansowaną aplikacją CRM, zespół programistów uruchomił produkcyjnie finalną wersję systemu. Projekt został zamknięty na ponad 3 tygodnie przed wyznaczonym terminem, więc dział sprzedaży nie posiadał się z radości. Pierwsze opinie klientów były bardzo pozytywne i dobrze rokowały całemu przedsięwzięciu. Aplikacja została bardzo ciepło przyjęta na rynku. Obroty firmy zaczęły rosnąć z kwartału na kwartał. Zespół cały czas zajmował się implementacją nowych funkcjonalności, o które dopominali się użytkownicy i managerowie projektu. Nic nie zapowiadało nadciągających problemów…

Pierwsze zgłoszenia o braku spójności danych lub ich znikaniu z systemu pojawiały się sporadycznie i były traktowane przez pracowników działu supportu z przymrużeniem oka. Tłumaczono to np. brakiem uwagi użytkownika, który mógł przecież nie pamiętać, gdzie klikał i czy faktycznie usunął coś ze swojego konta czy nie. Tym bardziej, że administratorzy serwerów nie doszukali się w logach niczego niepokojącego. Ot, standardowa wymiana informacji pomiędzy przeglądarkami użytkowników a serwerami aplikacji.

Jednak wraz z upływem czasu liczba podobnych zgłoszeń rosła, a kilku klientów straciło nawet całość zgromadzonych przez siebie danych. W całym tym zamieszaniu najgorszy był fakt, iż konkurent najważniejszego klienta firmy w nieznany sposób wszedł w posiadanie informacji o jego nowym produkcie na miesiąc przed oficjalną premierą…

Nie jest to może scenariusz na film na miarę Hitchcocka, zaczynający się od trzęsienia ziemi i w którym następnie napięcie nieprzerwanie rośnie, ale historia budzi grozę, ponieważ jest bardzo prawdopodobna.

Zamiast aplikacji CRM mógłbym równie dobrze wykorzystać w niej nowy serwis społecznościowy, aukcyjny czy crowdfoundingowy, dopasowując tylko rodzaj utraconych przez użytkowników informacji. Zaznaczam, że w niektórych miejscach opowieść trochę podkolorowałem.

Zrobiłem to celowo – dla  zwrócenia uwagi na wspólny mianownik wszystkich historii, które wejdą w skład cyklu tekstów dotyczących sposobów ataków i ochrony aplikacji internetowych przed potencjalnymi zagrożeniami, jakim jest bezpieczeństwo aplikacji webowej.

W moich tekstach przewija się wojenna terminologia. Dlaczego? Moim zdaniem bez niej nie da się pisać o cyberatakach. Przykład? Każdy podpięty do Internetu serwer jest potencjalnym celem dla wszelkiego rodzaju skryptów, bot-netów czy hakerów, dla których jedyną motywacją może być np. sam fakt udanego włamania na serwer lub też jego przeciążenia. Im szczelniejsza będzie ochrona serwera i działającej na nim aplikacji, tym bezpieczniejsze będą jej dane i prowadzony w oparciu o nie biznes. System jest tak słaby, jak jego najsłabsze ogniwo.

Przykłady włamań wynikających z luk w bezpieczeństwie serwerów lub aplikacji można niestety mnożyć prawie w nieskończoność. 19 marca 2011 roku zespół odpowiedzialny za rozwój PHP poinformował na swojej oficjalnej stronie o włamaniu na jeden ze swoich serwerów. Atakujący wykorzystali do tego błąd w zabezpieczeniach oprogramowania Wiki i tzw. root exploita, dzięki czemu uzyskali dostęp do konsoli administracyjnej całej maszyny. Choć w tym wypadku nie utracono żadnych danych, zespół poświęcił sporo czasu na zmianę haseł wszystkich kont svn oraz intensywny audyt wszystkich ostatnio wprowadzonych zmian w kodzie, aby wyeliminować niebezpieczeństwo wstrzyknięcia złośliwego kodu do źródeł samego języka PHP.

Inna historia z życia wzięta… Pewnego wieczoru właściciel jednego z serwisów www utracił dostęp do serwera hostującego aplikację www. Co gorsza, serwer po fizycznym restarcie nie potrafił się automatycznie podnieść. Kilkunastogodzinny downtime aplikacji został zakończony przy udziale pracownika supportu poprzez odtworzenie części plików systemowych. W tym przypadku także zawiniło oprogramowanie, za pomocą którego atakującemu udało się umieścić na serwerze skrypty w języku Perl, a następnie doprowadzić do ich uruchomienia.

Luka w znanym oprogramowaniu e-commerce umożliwiała złożenie zamówienia na półtora zegarka lub minus 2 pralki. Choć u niejednego czytelnika informacja ta wywołała uśmiech na twarzy, to zapewne właścicielom sklepów dotkniętych tym problemem nie było do śmiechu. Zwłaszcza, gdy przez nieuwagę zrealizowali kilka takich zamówień.

Jak widać, bezpieczeństwo rozwiązań IT można analizować na kilku osobnych płaszczyznach. Najniższą, pierwszą warstwę stanowi infrastruktura sprzętowa, tj. fizyczne serwery i elementy sieciowe. Stanowią one podstawę warstwy drugiej, czyli systemu operacyjnego, w ramach którego funkcjonuje najważniejsza dla nas aplikacja webowa. Najwyższą i jednocześnie ostatnią warstwę stanowią sami użytkownicy, których wbrew pozorom trzeba wspierać i chronić przed skutkami ich własnych działań…  Dla nas interesujące będą tylko  dwie środkowe warstwy, a więc system operacyjny i aplikacja – ze szczególnym uwzględnieniem aspektów programistycznych tej drugiej. Chwilę uwagi poświęcimy także tematowi zachowań użytkowników, choć osoby szerzej zainteresowane tym tematem od razu odsyłam do klasyki gatunku, czyli książki Kevina Mitnicka pod tytułem „Sztuka podstępu. Łamałem ludzi, nie hasła”.

We wszystkich częściach cyklu przedmiotem mojego zainteresowania będzie prosta aplikacja – typowy serwis społecznościowy, zaimplementowany w oparciu o język PHP i bazę danych MySQL. W pierwszych artykułach z cyklu badana aplikacja będzie wyglądać jak kawałek sera szwajcarskiego – tylko że zamiast dziur będzie miała sporą ilość luk w zabezpieczeniach. Stopniowo będzie jednak uzupełniana o kolejne zabezpieczenia tak, aby finalna wersja nadawała się do udostępnienia użytkownikom.

Przedstawione zagadnienia i techniki będzie można oczywiście z powodzeniem zastosować w projektach opartych o np. język Ruby czy Python – jest to tylko kwestia trochę odmiennej implementacji.

Na pierwszy ogień pójdzie wstrzykiwanie kodu SQL, czyli popularny SQL Injection, o czym już wkrótce…