5 języków programowania z ukrytymi wadami pozwalającymi na atak hakerów
#1
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
Currently enjoying a surge in usage, Python is regularly used by web and desktop developers, sysadmin/devops, and more recently by data scientists and machine-learning engineers.

The IOActive paper found that Python contains undocumented methods and local environment variables that can be used to execute operating-system commands.

Both Python's mimetools and pydoc libraries have undocumented methods that can be exploited in this way, which IOActive used to run Linux's id command.

2. Perl
Popular for web server scripting, sysadmin jobs, network programming and automating various tasks, Perl has been in use since the late 1980s.

IOActive highlights the fact that Perl contains a function that will attempt to execute one of the arguments passed to it as Perl code. It describes the practice as a "hidden feature" within a default Perl function for handling typemaps.

3. NodeJS
NodeJS provides a server-side environment for executing JavaScript, the language commonly used for scripting in web browsers.

IOActive found that NodeJS' built-in error messages for its require function could be exploited to determine whether a file name existed on the machine and to leak the first line of files on a system—potentially useful information for an attacker.

4. JRuby
The Java implementation of the Ruby programming language was found to allow remote code execution in a way that isn't possible in Ruby as a base language.

By calling executable Ruby code using a specific function in JRuby, IOActive was able to get the function to execute an operating system command, the Linux command id, by loading a file on a remote server.

5. PHP
The venerable server scripting language was used to call an operating system command, again the Linux command id, using the shell_exec() function and by exploiting the way PHP handles the names of constants.

"Depending on how the PHP application has been developed, this may lead to remote command execution," say researchers.

That said, many web admins have long known the potential risk posed by PHP's shell_exec() function, and how to disable it.
Źródło

[Aby zobaczyć linki, zarejestruj się tutaj]

Oryginalny artykuł z dokładnymi informacjami

[Aby zobaczyć linki, zarejestruj się tutaj]

"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#2
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....
1. Zawsze mam rację.
2. Jeśli nie mam racji, patrz pkt 1.
Odpowiedz
#3
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 Wink
"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#4
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.
Człowiek, któremu zazdroszczą najlepszych pomysłów na sygnatury...
Odpowiedz
#5
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.
Odpowiedz
#6
A ten serwis taki ładny był, amerykański, szkoda Cool
1. Zawsze mam rację.
2. Jeśli nie mam racji, patrz pkt 1.
Odpowiedz
#7
To takie nasze..."polskie"...no to zachowam konwencję Lol

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.
"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości