P

atryk Sondej oraz Piotr Krysiuk zgłosili lukę w jądrze Linuksa pozwalającą lokalnym użytkownikom na eskalację ich uprawnień do poziomu administratora, co pozwala na przejęcie pełnej kontroli nad systemem. Błąd use-after-free występuje w komponencie netfilter nf_tables podczas przetwarzania żądań wsadowych aktualizujących konfigurację i może zostać nadużyty do wykonania dowolnego odczytu i zapisu pamięci jądra. Dla przypomnienia: netfilter to wbudowany w jądro Linuksa framework do filtrowania pakietów i translacji adresów sieciowych (ang. Network Address Translation), który jest zarządzany przez takie narzędzia jak iptables / nftables i UFW (ang. Uncomplicated Firewall).
[ czytaj całość… ]

B

ardzo wiele firm utrzymuje repozytoria publicznych projektów na popularnych serwisach takich jak Github oraz Gitlab. Na przykład listę loginów poszczególnych użytkowników w serwisie Github można uzyskać bardzo łatwo – wystarczy odwiedzić adres: https://github.com/orgs/$firma/people.

Plus iterując po poszczególnych projektach: https://github.com/$firma/$projekt/graphs/contributors można zebrać dość dużą ilość unikatowych użytkowników. Gdzie następuje wyciek? Otóż Github używa adresów e-mail powiązanych z kontem Github (można mieć ich więcej niż jeden – a często na jednym koncie łączy się prywatne i firmowe adresy) przy zatwierdzaniu kodu (ang. commit) oraz innych aktywnościach w profilu użytkownika. Kiedy użytkownik zatwierdza kod w publicznym repozytorium jego adres e-mail jest publikowany i staje się publicznie dostępny.
[ czytaj całość… ]

Znalazłeś w repozytorium X prywatny klucz SSH i chciałbyś się dowiedzieć do kogo należy? Nic prostszego:

ssh -i znajda.key git@github.com

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi nfsec! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Działa również z gitlab.com, bitbucket.org i zapewne innymi.

Więcej informacji: GNU/JUSTIN

N

a samym początku należy zaznaczyć, że stanowisko projektu WordPress jest jednoznaczne w tej sprawie: nie uznaje nazw użytkowników ani identyfikatorów użytkowników za prywatne lub bezpieczne informacje. Nazwa użytkownika jest częścią Twojej tożsamości online. Ma na celu identyfikację, a nie weryfikację tego, kim jesteś. Weryfikacja jest zadaniem hasła. Ogólnie rzecz biorąc, ludzie nie uważają nazw użytkowników za tajne, często udostępniając je otwarcie. Ponadto wiele dużych firm internetowych – takich jak Google i Facebook – zrezygnowało z nazw użytkowników na rzecz adresów e-mail, które są udostępniane w sposób ciągły i swobodny. WordPress również przeniósł się na ten sposób, umożliwiając użytkownikom logowanie się przy użyciu adresu e-mail lub nazwy użytkownika od wersji 4.5.
[ czytaj całość… ]

P

otężny administrator systemu postanowił stworzyć bramę do ukrytego wymiaru. Dla niepoznaki zrobił to w katalogu domowym zwykłego użytkownika. By chronić portal przed różnymi daemonami rzucił na niego zaklęcie zdejmujące wszystkie prawa dostępu:

:~# bash -c "echo 'Niedostrzegalne barwy - czarne wodospady' > \
/home/agresor/ukryty_wymiar"
:~# chmod 0000 /home/agresor/ukryty_wymiar

Podczas powrotu do swojego katalogu ($HOME) użytkownik zauważył dziwne wrota:

agresor@darkstar:~$ ls -lah ukryty_wymiar
---------- 1 root root 39 Aug 24 21:01 ukryty_wymiar

Dookoła nich krążyły już Kerberos, Sphinx oraz sam Dracula. Widząc to, w użytkowniku wezbrał niepohamowany gniew, który przekształcił w ukrytą moc zniszczenia. Użytkownik wiedział, że bez księgi sudo nie jest w stanie zniszczyć portalu potężnego administratora, ale postanowił chociaż spróbować:
[ czytaj całość… ]

J

eśli zainstalujemy natywną paczkę MongoDB w dystrybucji Ubuntu 16.04 LTS w wersji 2.6.10 i po jej uruchomieniu przejdziemy do katalogu, gdzie są przechowywane metadane i bazy – wówczas prawa dostępu do plików i katalogów będą wyglądać tak. Niestety jeśli podążymy drogą oficjalnej instrukcji instalacji dla wersji 3.4 (tutaj 3.4.6) to już prawa dostępu będą wyglądać tak. Od razu widać, że uprawnienia te są zbyt szerokie i każdy użytkownik posiadający konto na serwerze jest w stanie wykonać pełną kopie wszystkich danych z tego katalogu (np. za pomocą programu tar). Okazuje się, że błąd ten jest znany od 2015 roku. Stanowić to może poważny problem bezpieczeństwa dla hostingu oraz usług współdzielonych oferujących tego typu bazę. Każdy użytkownik jest w stanie pozyskać dane “sąsiadów” i nie musi nawet posiadać konta z aktywną powłoką – zawsze może uruchomić zadanie cron, które skopiuje mu dane do jego katalogu przewidzianego dla strony www, później pobierając je przy pomocy HTTP, czy FTP. Rozwiązaniem tego błędu jest przywrócenie poprawnych praw dostępu do katalogu /var/lib/mongodb:

chmod o-rx /var/lib/mongodb

oraz modyfikacji umask dla użytkownika mongodb.

Więcej informacji: MongoDB at shared hosting: security surprises

A

więc firma, na którą dostaliśmy zlecenie audytu posiada na swojej stronie listę kilku pracowników z imienia i nazwiska, a jej rekordy DNS typu MX sugerują, że używa Google Apps dla firmowej domeny. Jak potwierdzić fakt, że dany pracownik posiada adres w formacie: imie.nazwisko@startup.pl i jest istniejącym kontem w usłudze Gmail? Oczywiście możemy wysłać wiadomość e-mail z jakiegoś jednorazowego konta e-mail i oczekiwać na zwrotkę w przypadku pomyłki, ale równie dobrze możemy trafić na jakiś adres typu catch-all lub alias prowadzący do innego odbiorcy, a to już komplikuje nam nasze intencje.
[ czytaj całość… ]