Exploit Moodle

Eksportowanie kursów z moodle’a jest bardzo niebezpieczne. Okazało się, że został opublikowany exploit (łamiąc oczywiście zasady polityki bezpieczeństwa moodle http://moodle.org/security), który z użytkownika posiadającego prawa nauczyciela, może zrobić administratora.

Przechodząc do szczegółów, nie musimy się bać jeśli nasi nauczyciele nie mają możliwości eksportu kursów. Niemniej jednak w moodle od wersji 1.9.6 przy tworzeniu kopii zapasowych zapisywane są dane użytkowników zapisanych na kurs. Opcja ta pozwala zachować spójność danych, co jest ważne zwłaszcza przy odtwarzaniu kursów w innym środowisku niż źródłowe.

Oczywiście dane o użytkownikach, a zwłaszcza ich hasła są zakodowane (hash md5) i przykładowe hasło wygląda np. tak: e4d909c290d0fb1ca068ffaddf22cbd0. Nie pozwala to oczywiście na bezpośrednie odkodowanie hasła, więc do pewnego momentu wydawało się to wystarczającą metodą zabezpieczającą. Niestety okazało się, że istnieje sposób (reverse mapping) na odnalezienie realnego hasła odpowiadającego zakodowanej wersji. Zwłaszcza dotyczy to bardzo prostych haseł.

Odnaleziony exploit wykorzystując konto nauczyciela z prawami do tworzenia kopii zapasowej, tworzy ją i odczytuje dane nt. użytkowników, a następnie porównuje je z bazami danych, zawierającymi zestawienia hasło realne – hasło zakodowane md5. Niebezpieczeństwo pojawia się, gdy wśród nauczycieli mających prawo do tworzenia kopii zapasowych jest osoba, która użyje exploita, a
administrator wykorzystuje słabe hasło i był zapisany na dany kurs.

Błąd ten wykorzystuje moim zdaniem lukę w polityce bezpieczeństwa tworzenia moodle, zakładającą, że ufamy nauczycielowi. Uważam jednak, że nie możemy ufać użytkownikom, oczywiście trochę możemy zaufać sobie, ale też nie zaszkodzi stosować się do zasad bezpieczeństwa.

Jesli wykorzystujemy moodle’a na szeroką skalę i nasi nauczyciele mają prawo do tworzenia kopii zapasowych to sprawa jest bardzo poważna. Co można zrobić już…

1) Czekać na nowe wersje :), bo społeczność developerów moodle pracuje już bardzo intensywnie nad stworzeniem łatek, które ukażą się w rozwijanych wersjach 1.9.7 i 1.8.11.

2) Wyłączyć funkcję tworzenia kopii zapasowych, przynajmniej do momentu, kiedy p. 1. nie stanie się rzeczywistością. Zrobić to można bardzo prosto. Przechodzimy do edycji uprawnień i blokujemy możliwość tworzenia kopii zapasowej.

3) Włączyć opcję tzw. salting’u, czyli dodatkowego zabezpieczenia kodowania md5 (opcja dostępna od wersji 1.6), który na język polski jest tłumaczony, jak zwykle zgrabnie, jako: losowy modyfikator klucza. To rozwiązanie, moim zdaniem najlepsze i jedyne w tej chwili skuteczne zabezpiecza nas niemalże w 100% przed opisywanym tu exploitem. Niestety strony księżyca są dwie i tą ciemniejszą jest to, że uaktywnienie tej opcji spowoduje problem z możliwością przenoszenia kopii kursów. Otóż opcja ta będzie musiała być włączona w moodle’u źródłowym i docelowym, w innym przypadku przenoszenie kursów wraz z zapisanymi uczestnikami (sprostowanie dzięki komentarzowi Przemysława, dziękuję) nie będzie możliwe. A teraz jak to zrobić: – edytujemy plik config.php dodając następującą linijkę

$CFG->passwordsaltmain = ‘jakiś długi string który będzie dobrym modyfikatorem’;

Pozostałe dwie aktywności dodaję tu dla odważnych, którzy nie zrobili tego instalując moodle :
Pierwsza to uruchomienie odpowiedniej polityki tworzenia haseł. Takiej, która będzie wymuszała długie i skomplikowane hasła.
Druga to możliwie częsta zmiana haseł administracyjnych, przy zachowaniu odpowiedniego stopnia ich skomplikowania.
—
Exploit to program mający na celu wykorzystanie błędów w oprogramowaniu.