5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - Wersja do druku +- SafeGroup (https://safegroup.pl) +-- Dział: Bezpieczeństwo (https://safegroup.pl/forum-10.html) +--- Dział: Inne (https://safegroup.pl/forum-15.html) +--- Wątek: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów (/thread-11269.html) |
5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - ichito - 12.12.2017 Jak wiemy błędy i podatności w aplikacjach, to skutek niedoskonałości w ich kodzie, a skutki tego doświadczamy wielokrotnie na własnej skórze walcząc ze szkodnikami. Tym razem mowa jednak będzie o błędach w samych językach programowania, o czym powiadomiono na ostatniej konferencji Black Hat Europe 2017, która się zakończyła kilka dni temu. Praca pt. "Exposing Hidden Exploitable Behaviors in Programming Languages U sing Differential Fuzzing" wskazuje na bardzo poważne znalezione podatności we wszystkich przeanalizowanych językach -JavaScript, Perl, PHP, Python i Ruby. Opis poatności poniżej Cytat:1. PythonŹródło [Aby zobaczyć linki, zarejestruj się tutaj] Oryginalny artykuł z dokładnymi informacjami[Aby zobaczyć linki, zarejestruj się tutaj] RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - Tajny Współpracownik - 12.12.2017 PHP chyba wstawili żeby była "ładna" liczba języków, bo skoro potencjalna dziura jest zależna od implementacji, to znaczy że język jako narzędzie sam w sobie nie stanowi zagrożenia. Gdybyśmy szli krokiem autorów, moglibyśmy stwierdzić, że każdy język stanowi zagrożenie. Przecież to jest absurd.... RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - ichito - 12.12.2017 Nie jestem specjalistą w tej dziedzinie, więc nie komentuję nawet...mam nadzieję, że dla części z Was informacja może być istotna ze względu na to, jakie konsekwencje mogę mieć te luki RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - M'cin - 12.12.2017 Też nie jestem ekspertem od serwerów czy PHP, ale pobieżna lektura dzienników popularnoinformatycznych pozwala stwierdzić, że shell_exec() to chyba domyślnie się blokuje w implementacjach. RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - Konto usunięte - 12.12.2017 Moge się wypowiedzieć jako dev PHP i powiem tak - to odnośnie tego języka to brednie. Kilka informacji: 1. shell_exec może być wyłączone przy pomocy ustawienia disable_functions, choć często jest domyślnie włączone (np. PHP z repo debianowych / ubuntu (wraz z ppa) czy na centosie). Dlaczego? Bo nie ma powodu go wyłączać. 2. Polecenie to służy do odpalania poleceń shellowych (systemowych), a więc daje ogromne możliwości - choć wpływ na to ma masę kwestii (patrz niżej). 3. W PHP mamy do dyspozycji coś takiego jak open_basedir, które limituje nam "widoczność" drzewa katalogów dla PHP i operacji na nich. W efekcie ustawieniem tym - mocno to upraszczając - możemy "zamknąć" interpretatory PHP w np. katalogu witryny aby nie miały nawet możliwości odczytywania tego, co jest wyżej. 4. Nawet jeśli nie ustawimy powyższe, w grę wchodzą ustawienia dostępu do plików, nadal respektowane. 5. Jeśli zechcemy, możemy odpalać PHP (i cały serwer webowy) ze zmienionym katalogiem głównym przy pomocy chroota, co powoduje, że także wszystko w shell_exec jest ograniczone. 6. Na koniec najważniejsze - w dokumencie przedstawiono kod który opiera się na tym, że możemy sobie zdefiniować jakąś stałą, a następnie próbujemy jej użyć gdzieś, gdzie nie mamy jej zdefiniowanej (ot, jesteśmy idiotami i zapomnieliśmy, zdarza się) w shell_exec wraz z danymi lecącymi jako coś wprowadzane przez użytkownika bez filtrowania tego (jak już wspomniałem, jesteśmy idiotami). No i w efekcie tego, że zapomnieliśmy się, nasza nieistniejąca stała wywoła notice z PHP, ale zostanie zamieniona na ciąg znaków, złączona z tym czymś od usera i wykonana. Jak już wspomiałem, byliśmy idiotami, więc na pewno nazwaliśmy ją np. "bash", "sh" itp. no bo przecież właśnie tego potrzebowaliśmy. Założenia są tak masakrycznie absurdalne, że szkoda tego czytać. Na podobnej zasadzie można powiedzieć: - że PHP jest niebezpieczne, bo ktoś używał md5/sha1 do hashowania haseł zamiast bcrypta z password_hash (albo może sam wymyślił swój "algorytm"?) - że PHP jest niebezpieczne, bo ktoś nam zrobił SQL Injection - przecież tylko wrzuciliśmy input z formularza prosto w zapytanie, co w tym złego, prawda? - że PHP jest niebezpieczne, bo na podstawie parametru podanego przez użytkownika chcieliśmy odczytać jakiś plik np. include('../' . $_GET['user_input']) - że PHP jest niebezpieczne, bo mielismy komentarze na stronie, ale nie filtrowaliśmy i za sprawą XSS ktoś nam wrzucił kod JS z koparką BTC - że PHP jest niebezpieczne, bo ktoś nam zrobił kuku z CSRF i np. klientom nawrzucał rzeczy do koszyka w sklepie internetowym bo kurcze, przecież nie wiemy nic o tokenach To nie są błędy języka. To są błędy i niewiedza programistów. RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - Tajny Współpracownik - 13.12.2017 A ten serwis taki ładny był, amerykański, szkoda RE: 5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów - ichito - 14.12.2017 To takie nasze..."polskie"...no to zachowam konwencję Cytat:Dziękuję Ci, Panie, że moją ręką pokarał Kargula, i przysięgam na wszystko, co ma moc nade mną, że drogi do domu nie zaślepię i po ziemię wrócę. Żeby kości nasze nie szukali się po świecie. A na całe Kargulowe plemię i pole spuść, dobry Panie, wszystkie plagi egipskie. Tylko się nie pomyl i nas, Pawlaków, sąsiadów Kargulowych, nie doświadczaj, bo my się swojej miedzy trzymamy. |