Z poniższego zrzutu ekranu wynika, że serwer sklepu dla e-palaczy e-dym.pl przez pewien czas umożliwiał odczyt wylistowanych na nim plików. Być może przez błędną konfigurację, być może przez brak interpretacji pliku index.php. Jeśli mieliście tam konto to na wszelki wypadek, zachęcamy do zmiany hasła i tam i wszędzie gdzie używaliście tego samego hasła.
Wyciek danych z serwera e-dym.pl
Z informacji docierających od użytkowników forum E-papierosy-forum.pl awaria serwera miała miejce przez wzgląd na urodzinową promocję. Uzytkownicy nie mogąc się doczekać na akcję promocyjną poprzez ciągłe odświeżanie strony, zasymulowali atak DDoS na stronę. W efekcie strona wyświetlała katalog strony www w której znajdował sie między innymi backup bazy danych z sierpnia 2014.
AKTUALIZACJA
Jak słusznie zauważają czytelnicy błąd popełnił administrator źle nazywając plik index.php jako inedx.php. Tym samym nie zostal on zinterpretowany przez PHP i serwer wyswietlił indeks. Wcześniej serwis informował że ma problem z hostingiem.
Komentarze
Gdzie mogę tam zmienić hasło ? Nie mogę tego znaleźć.
Okej już znalazłem.
inedx.php ;)
Swoją drogą, te spaghetti-aplikacje w PHP są śmieszne. Ciekawe kiedy domorośli programiści PHP odkryją dobrodziejstwa frameworków. Przyzwoite technologie istnieją od ~10 lat, a ja wciąż widzę nowe projekty pisane w ten sposób :(
Wsadz sobie w dupe te swoje frame worki, oki ?
W zwiazku z tym do konca swojego zasranego zycia bedziesz to ogladal.
1. Nie do wszystkiego frameworki można „włożyć”
2. Tutaj problemem nie był kod, tylko literówka. Równie dobrze mogła się zdarzyć w frameworku
3. Są zlecenia, w których firma nie życzy sobie otwartych rozwiązań, tylko autorskie, wówczas frameworki odpadają i zaczyna się ból dupy, bo przecież fachowiec sam nigdy, nic nie napisał, tylko wieczne kopiuj-wklej
4. Mimo wszystko, sam napiszesz = masz większą kontrolę.
Oczywiście frameworki mają swoje zalety i tego nie podważam, bo sam czasami używam gotowców. Ale tutaj akurat nie masz racji, bo problemem nie był zły kod, tylko literówka w nazwie pliku.
A od kiedy to atak DDOS powoduje, że strona zaczyna pokazywać swoje kody źródłowe? To raczej nie ma związku.
Atak DDoS to rozproszony atak odmowy usługi. W tym wypadku usługą która „klękła” był zapewne interpreter PHP. Serwer natomiast zamiast np błędu 500 Internal Server Error, wyświetlił indeks katalogu.
eeee, że co? :D Dawno takich głupot nie czytałem :D Apache powinien rzucić 500, a nie listować katalogi :D i interpreter PHP tak sobie nie pada zwłaszcza, że to pewnie apache mod, a nie php-fpm, który mógłby paść bo to jednak osobny proces ( ale takich testów nie wykonywałem ).
Także i Adam raczej trochę przestrzlił z DDOSem, a ty bardzo mocno przestrzeliłeś z interpretacją ;-)
Adama w to nie mieszaj ;), nawarzyłem piwa to je wypiję.
Nie wiemy jaką konfigurację ma serwer. Znam kilka przypadków gdzie błędnie skonfigurowany apache przy próbie ataku DoS wyświetlał indeks katalogu. Jeden z nich to błędnie skonfigurowany memcached, który przy dużym obciążeniu zwracał że pliku index.php nie ma.
Jedno jest pewne – nie powinno się pojawić aktywne listowanie katalogów w konfiguracji serwera.
Adama mieszam tyle, że szukał DDOSa, a jego tam nie ma :-) ;-)
Co do reszty
a) prawda, listing na apachu w defaulcie to zło kompletne… dziwie się, że defaultowa konfiguracja to wspiera.
b) z tym memcached to ciekawe. Ale imho nie znam sytuacji w której pad jakiegoś modułu nie powoduje puszczenia 500 ewentualnie 502, a powoduje puszczenie listingu. Jak masz jakieś info/art to chętnie poczytam. Przydałoby się do pracy :D
Wiemy już gdzie był problem, ale Twoja hipoteza jest ciekawa i coś więcej bym poczytał, także… pics or didn’t happen :D
Ale ja nie byłem autorem artykułu :)
Adam nie szukał DDoS’a :)
b) przykład który mam, pokazać nie mogę, ale wygooglowałem coś:
http://ubuntuforums.org/showthread.php?t=2131687
konkretnego bug requesta niestety znaleźć nie moge.
Gdzie wy tutaj widzicie związek z ddosem? To ewidentnie wina kogoś, kto ma dostęp d o serwera. Apaczi wyświetlił listę plików, bo ktoś omyłkowo zmienił nazwę pliku index.php na idnex.php i dupa. Jakby serwer był poprawnie skonfigurowany to by wyrzucił 404 i cześć, a tak to bieda. Serwisem pewnie zarządzał jakiś niedoświadczony programisto-admin (dumpy baz w docroot…) i takie są tego efekty.
słusznie, dziękuję.
Kolejny przykład, w jak rewelacyjny sposób podchodzą do bezpieczeństwa i przechowywania danych właściciele serwisów. Dump bazy z hasłami w plaintext, wylistowany na Apache’u w wersji z 2012 roku. Za to powinni zabierać „prawo jazdy admina” na 3 miesiące ;).
żadne serwery nie padły, nie było też żadnej awarii home.pl e-dym po prostu nawalił błąd informatyka czy administratora który zrobił literówkę i każdy mógł mieć dostęp do plików i zarazem do bazy która była na serwerze.. i ot to cała sytuacja..!