Search Results

Nadszedł czas, aby pożegnać się z serią jądra Linuksa 6.0, ponieważ jest on teraz oznaczony jako EOL (End of Life) na stronie kernel.org, co oznacza, że ​​nie będzie już aktualizowany. Jądro Linuksa 6.0 zostało wydane około trzy miesiące temu, 2 października 2022 r., z nowymi funkcjami, takimi jak obsługa uwierzytelniania wewnątrzpasmowego NVMe, asynchroniczny buforowany zapis przy użyciu zarówno XFS, jak i io_uring, obsługa transmisji sieciowej typu zero-copy io_uring lub obsługa magistral PCI w architekturach OpenRISC i LoongArch. Wprowadzono również ulepszenia architektur sprzętowych RISC-V i AArch64 (ARM64), nowe i ulepszone funkcje systemów plików Btrfs i OverlayFS, a także nowe i zaktualizowane sterowniki zapewniające najwyższej klasy obsługę sprzętu. Niestety, jądro Linuksa 6.0 jest gałęzią krótkotrwałą, a nie LTS (Long-Term Support), co oznacza, że ​​jest wspierane tylko aktualizacjami konserwacyjnymi przez kilka miesięcy. Dzisiaj jądro Linuksa 6.0 dobiegło końca wraz z aktualizacją 6.0.19, która jest ostatnią stabilną wersją z tej serii. Opiekunowie dystrybucji GNU/Linux i użytkownicy korzystający z serii jądra Linuksa 6.0 są teraz zachęcani przez opiekunów jądra do aktualizacji do nowszej wersji, takiej jak jądro Linuksa 6.1 , które również zostało dzisiaj zaktualizowane do wersji 6.1.5 dla osób zainteresowanych aktualizacją swoich jąder . „Ogłaszam wydanie jądra 6.0.19. Uwaga, jest to OSTATNIA wersja jądra 6.0.y. Wszyscy użytkownicy muszą w tym momencie przejść do gałęzi 6.1.y, ponieważ ta gałąź jest już wycofana z eksploatacji” — powiedział znany opiekun jądra, Greg Kroah-Hartman. Bez zbędnych ceregieli rozważ jak najszybszą aktualizację jądra Linuksa do wersji 6.1. Większość dystrybucji kroczących, takich jak Arch Linux lub openSUSE Tumbleweed (i ich pochodne), już go używa, więc nie powinno to stanowić problemu. Jądro Linuksa 6.1 powinno wkrótce pojawić się w stabilnych repozytoriach oprogramowania Fedory Linux, podczas gdy użytkownicy Ubuntu będą musieli je zainstalować, korzystając z tego samouczka lub jądra XanMod .

W 2019 roku firma Canonical była optymistycznie nastawiona do wspierania kontrowersyjnego systemu plików , wywołując falę wraz z wydaniem Ubuntu 19.10 , które zawierało eksperymentalną opcję instalacji Ubuntu (jądro, pliki systemowe i dane użytkownika) na woluminie ZFS. Ubuntu było pierwszą dużą dystrybucją Linuksa, która przyjęła ZFS, pomimo plątaniny problemów związanych z licencjonowaniem . Ale od tego czasu entuzjazm opadł. W zeszłym roku programiści Ubuntu naciskali na usunięcie Zsys z instalatora Ubiquity Ubuntu. Jest to integralne narzędzie Ubuntu stworzone, aby ułatwić zarządzanie i konserwację instalacji opartych na ZFS. W raporcie o błędzie bez ogródek zauważyli, że „zmiany priorytetów” w zespole komputerowym oznaczają, że Zsys nie jest już czymś, co chcą „reklamować za pomocą”. Zsys miał zostać zdegradowany z nadchodzącego wówczas LTS, ale z nieujawnionych powodów tak się nie stało . W chwili pisania Zsys pozostaje dostępny w archiwach Ubuntu, ale jego rozwój nie wygląda zdrowo. Wkład Canonical skutecznie spadł około kwietnia 2021 r. w oparciu o zobowiązania GitHub, z tylko trywialną poprawką wprowadzoną w kwietniu ubiegłego roku. Codzienne kompilacje nadchodzącej wersji Ubuntu 23.04 są dostarczane z zupełnie nowym instalatorem, który został zbudowany przy użyciu Flutter dokładnie na potrzeby firmy Canonical. Czego ten nowy instalator Ubuntu nie zawiera? Opcja instalacji Ubuntu w systemie plików ZFS. Bez wyraźnego publicznego znaku jakichkolwiek wysiłków na rzecz rozwoju lub ulepszenia Ubuntu ZFS, członkowie Ubuntu całkiem słusznie zastanawiają się: jaki jest obecnie status obsługi ZFS przez Ubuntu? Twoje przypuszczenia są tak samo dobre jak moje — ale sprawy nie wyglądają dobrze: Zsys jest zablokowany i nie ma możliwości zainstalowania najnowszej wersji Ubuntu na ZFS. W związku z tym wygląda na to, że przelotne zauroczenie Ubuntu tym niesławnym systemem plików dobiegło końca, wysiłek wygasł. Dołącz do Ubuntu TV, Ubuntu Phone, Unity 8 i innych zwłok na cmentarzu rozczarowań firmy Canonical. Źródło: https://discourse.ubuntu.com/t/future-of-zfs-on-ubuntu-desktop/33001?u=d0od https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1966773/comments/1 https://github.com/ubuntu/zsys https://ubuntu.com/blog/zfs-licensing-and-linux https://en.wikipedia.org/wiki/ZFS

We wtorek Microsoft wydał łatki dla 98 luk oznaczonych numerami CVE, w tym jednej wykorzystywanej w środowisku naturalnym (CVE-2023-21674) i jednej (CVE-2023-21549), która została ujawniona publicznie. Obie pozwalają atakującym na podniesienie uprawnień na podatnej maszynie. To pierwszy Patch Tuesday w 2023 roku. Warto dodać, że spośród 98 luk jedenaście zostało sklasyfikowanych jako krytyczne. Liczba błędów w każdej kategorii została wymieniona poniżej: 39 luk w zabezpieczeniach podniesienia uprawnień, 4 luki w zabezpieczeniach dotyczące obejścia zabezpieczeń, 33 luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu, 10 luk w zabezpieczeniach związanych z ujawnianiem informacji, 10 luk w zabezpieczeniach związanych z odmową usługi, 2 luki w zabezpieczeniach związane z fałszowaniem (spoofingiem). Uwaga na te luki w bezpieczeństwie CVE-2023-21674 CVE-2023-21674 to luka w zabezpieczeniach systemu Windows Advanced Local Procedure Call (ALPC), która może prowadzić do ucieczki z piaskownicy przeglądarki i umożliwić atakującym uzyskanie uprawnień SYSTEM w wielu różnych instalacjach systemów Windows i Windows Server. „Błędy tego typu są często łączone z jakąś formą wymuszania kodu w celu dostarczenia złośliwego oprogramowania lub oprogramowania ransomware. Biorąc pod uwagę, że zostało to zgłoszone Microsoft przez badaczy z firmy Avast, taki scenariusz wydaje się tutaj prawdopodobny” — zauważył Dustin Childs z firmy Trend Micro. Należy pamiętać, że łatanie tego typu błędów powinno być priorytetem. Na ogół luki w zabezpieczeniach takie jak CVE-2023-21674 są dziełem grup APT w ramach ataków ukierunkowanych. Wykorzystują oni tego typu exploity do atakowania środowisk informatycznych. CVE-2023-21549 Druga publicznie ujawniona luka w zabezpieczeniach, CVE-2023-21549, dotyczy Windows SMB Witness. Jej użycie jest mniej prawdopodobne w najnowszych wersjach systemów Windows i Windows Server, mimo że złożoność ataku i niezbędne uprawnienia są niskie, a interakcja użytkownika nie jest wymagana. „Aby wykorzystać lukę, osoba atakująca może wykonać specjalnie spreparowany złośliwy skrypt, który wykonuje wywołanie RPC do hosta RPC. Może to spowodować podniesienie uprawnień na serwerze. Osoba atakująca, której uda się wykorzystać tę lukę, może wykonać funkcje RPC, które są ograniczone tylko do kont uprzywilejowanych” — wyjaśnia Microsoft. Inne luki Administratorzy odpowiedzialni za łatanie lokalnych serwerów Microsoft Exchange powinni szybko przystąpić do załatania dwóch luk EoP (CVE-2023-21763/CVE-2023-21764), wynikających z nieudanej poprawki wydanej w listopadzie 2022 roku. Pozostałe łaty mają na celu naprawienie luk w Windows Print Spooler (jedna z nich została zgłoszona przez NSA), jądrze Windowsa i innych rozwiązaniach. Istnieją również dwie interesujące luki (CVE-2023-21560, CVE-2023-21563) umożliwiające atakującym ominięcie funkcji BitLocker Device Encryption na systemowym urządzeniu pamięci masowej w celu uzyskania dostępu do zaszyfrowanych danych, ale tylko wtedy, gdy są one fizycznie obecne. Windows 7 i Server 2008/2008 R2 bez wsparcia producenta Przy okazji publikacji informacji o Patch Tuesday warto wspomnieć o ogłoszonym przez Microsoft 10 stycznia końcu wsparcia dla Windows 7 i Server 2008/2008R2. Od teraz korzystanie z tych systemów będzie niosło duże ryzyko, zwłaszcza w kwestii bezpieczeństwa. Źródła: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21674 https://www.zerodayinitiative.com/blog/2023/1/10/the-january-2023-security-update-review https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21549

Podatność: Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability umożliwia zdobycie uprawnień SYSTEM z poziomu zwykłego użytkownika. Microsoft dodaje, że luka może być użyta do wyskoczenia z sandboxa przeglądarkowego. Więc prawdopodobnie jest ona składnikiem łańcucha: wchodzisz na zainfekowaną stronę -> serwowany jest exploit na przeglądarkę -> użyty jest CVE-2023-21674 do otrzymania uprawnień SYSTEM na Twoim komputerze. Podatność była/jest exploitowana w Internecie, więc warto sprawdzić czy macie już wgrane ostatnie łatki.

Mamy kiepskie wiadomości dla właścicieli inteligentnych pojazdów różnych firm. Są to także niechlubne informacje dla branży automotive. Zespół naukowców kierowany przez Sama Curry’ego wziął na tapetę zabezpieczenia aplikacji największych producentów z branży samochodowej i postanowił je przetestować. Podczas przeprowadzonych testów penetracyjnych odkrył wiele błędów w zabezpieczeniach API marek takich jak Ferrari, BMW, Rolls Royce, Porsche i innych. Chciałoby się powiedzieć – technologia do zdalnego zarządzania pojazdem jest czasem jak zbawienie i super „ficzer”, ale może też być niebezpieczna. Jak bardzo – opisujemy poniżej. Znane marki pod lupą badaczy bezpieczeństwa Badacze sprawdzili systemy telemetryczne, interfejsy API używane w motoryzacji oraz infrastrukturę obsługującą samochody. Wyniki testów są porażające i gdyby nie szybka reakcja producentów i naprawa błędów, zalecalibyśmy Ci, Drogi Czytelniku, jak najszybsze odinstalowanie z Twojego smartfona aplikacji i wyłączenie funkcji zdalnego zarządzania Twoim pojazdem. Poniżej prezentujemy jedynie wybrane zrzuty z aplikacji (Mercedes, Ferrari i BMW), do których udało się uzyskać dostęp. Jakie możliwości stwarzają odkryte luki? Na początku tego roku Curry ujawnił, w jaki sposób przestępcy wykorzystali błędy, aby odblokować i uruchomić samochody z omawianymi wadami. Hakerzy mogli wykonywać złośliwe działania za pośrednictwem luk w zabezpieczeniach API u prawie dwudziestu producentów samochodów oraz w usługach, jakie posiadali zaimplementowane w środowisku IT. Możliwości, jakie dają im te błędy, są ogromne. Najważniejsze to: odblokowywanie samochodów, uruchamianie samochodów, śledzenie samochodów, ujawnianie danych osobowych klientów. Wszystkie dwadzieścia marek, u których zaobserwowano podatności, to marki dobrze znane, a błędy znaleziono dodatkowo w usługach przesyłania strumieniowego u producentów bezpośrednio związanych z przemysłem motoryzacyjnym oraz wspomnianymi firmami samochodowymi. Są to firmy takie jak: Spireon, Reviver, SiriusXM. W tej chwili nie są dostępne żadne exploity, ponieważ wszystkie problemy przedstawione w raporcie zostały naprawione przez dostawców. Stwierdzono, że najpoważniejsze wady w API mają BMW i Mercedes-Benz. Marki samochodowe z wykrytymi lukami w zabezpieczeniach U wymienionych poniżej firm z branży motoryzacyjnej zidentyfikowano kilka luk w zabezpieczeniach, które podsumowujemy: Kia, Honda, Infiniti, Nissan, Acura W pełni zdalne blokowanie, odblokowywanie, uruchamianie silnika, zatrzymywanie silnika, precyzyjna lokalizacja, miganie reflektorami i trąbienie pojazdami przy użyciu tylko numeru VIN W pełni zdalne przejęcie konta i ujawnienie PII za pomocą numeru VIN (imię i nazwisko, numer telefonu, adres e-mail, adres zamieszkania właściciela) Możliwość zablokowania użytkownikom opcji zdalnego zarządzania pojazdem, możliwość zmiany właściciela Dodatek od Kii – możliwość uzyskania zdalnego dostępu do kamery 360 stopni i obraz na żywo z samochodu Mercedes-Benz Dostęp do setek aplikacji wewnętrznych o znaczeniu krytycznym za pośrednictwem nieprawidłowo skonfigurowanego logowania jednokrotnego Dostęp do wielu instancji Github za aplikacją SSO Dostęp do wewnętrznego czatu w całej firmie, możliwość dołączenia do niemal każdego kanału Dostęp do SonarQube, Jenkins, różnych wersji serwerów Dostęp do wewnętrznych usług wdrożeniowych w chmurze do zarządzania instancjami AWS Dostęp do interfejsów API związanych z pojazdami wewnętrznymi Zdalne wykonanie kodu na wielu systemach Wycieki pamięci prowadzące do ujawnienia danych osobowych pracownika/klienta oraz dostępu do konta Hyundai, Genesis W pełni zdalne blokowanie, odblokowywanie, uruchamianie i zatrzymywanie silnika, precyzyjne lokalizowanie, miganie reflektorami i trąbienie – wszystko to przy użyciu wyłącznie adresu e-mail ofiary W pełni zdalne przejęcie konta i ujawnienie PII za pośrednictwem adresu e-mail ofiary (imię i nazwisko, numer telefonu, adres e-mail, adres właściciela) Możliwość zablokowania użytkownikom funkcji zdalnego zarządzania pojazdem, możliwość zmiany właściciela. BMW, Rolls-Royce Podstawowe luki w zabezpieczeniach SSO w całej firmie, które umożliwiły nam dostęp do dowolnej aplikacji pracowniczej jako dowolny pracownik Dostęp do wewnętrznych portali dealerskich, gdzie możesz zapytać o dowolny numer VIN, aby pobrać dokumenty sprzedaży BMW Możliwość uzyskania dostępu do dowolnej aplikacji zablokowanej za pomocą logowania jednokrotnego w imieniu dowolnego pracownika, w tym aplikacji używanych przez pracowników zdalnych i dealerów Ferrari Pełne przejęcie konta bez interakcji dla dowolnego konta klienta Ferrari IDOR, aby uzyskać dostęp do wszystkich danych klientów Ferrari Brak kontroli dostępu umożliwiający atakującemu tworzenie, modyfikowanie, usuwanie kont użytkowników, administratorów, „zaplecza” pracowników oraz wszystkich kont użytkowników z możliwością modyfikowania stron internetowych należących do Ferrari za pośrednictwem systemu CMS Możliwość dodawania tras HTTP na api.ferrari.com (łączniki rest) i przeglądania wszystkich istniejących złączy rest i związanych z nimi poufnych danych (nagłówki autoryzacji) Spireon Pełny dostęp administratora do ogólnofirmowego panelu administracyjnego z możliwością wysyłania dowolnych poleceń do około 15,5 miliona pojazdów (odblokowywanie, uruchamianie silnika, wyłączanie rozrusznika itp.), odczytywanie lokalizacji dowolnego urządzenia oraz flashowanie/aktualizacja oprogramowania układowego urządzenia Zdalne wykonywanie kodu w podstawowych systemach do zarządzania kontami użytkowników, urządzeniami i flotami. Możliwość dostępu i zarządzania wszystkimi danymi w całym Spireon Możliwość pełnego przejęcia dowolnej floty (pozwoliłoby nam to śledzić i wyłączać rozruszniki pojazdów policyjnych, karetek pogotowia i organów ścigania w wielu dużych miastach i wysyłać polecenia do tych pojazdów, np. „nawiguj do tej lokalizacji”) Pełny dostęp administracyjny do wszystkich produktów Spireon Dostęp do 15,5 mln urządzeń (głównie pojazdów) Dostęp do 1,2 miliona kont użytkowników (konta użytkowników końcowych, menedżerowie floty itp.) Ford Pełne ujawnienie pamięci w interfejsie API telematyki pojazdu produkcyjnego Ujawnienie danych osobowych klienta i tokenów dostępu do śledzenia i wykonywania poleceń w pojazdach Ujawnienie poświadczeń konfiguracji używanych do usług wewnętrznych związanych z telematyką Możliwość uwierzytelnienia na koncie klienta i uzyskania dostępu do wszystkich danych osobowych oraz wykonywania działań przeciwko pojazdom Przejęcie konta klienta poprzez niewłaściwe parsowanie adresów URL umożliwia atakującemu pełny dostęp do konta ofiary, w tym portalu pojazdu Reviver Pełny superdostęp administracyjny do zarządzania wszystkimi kontami użytkowników i pojazdami dla wszystkich pojazdów podłączonych do Reviver Śledzenie fizycznej lokalizacji GPS i zarządzanie tablicami rejestracyjnymi wszystkich klientów Reviver (np. zmieniając hasło na dole tablicy rejestracyjnej na dowolny tekst) Aktualizowanie dowolnego statusu pojazdu na „SKRADZIONY” – umożliwia aktualizację tablicy rejestracyjnej i informuje władze Uzyskanie dostępu do wszystkich danych użytkowników, w tym posiadanych pojazdów, ich adresu, numeru telefonu i adresu e-mail Możliwość uzyskania dostępu do funkcji zarządzania flotą dla dowolnej firmy, lokalizowanie wszystkich pojazdów we flocie i zarządzanie nimi Porsche Możliwość pobierania lokalizacji pojazdu, wysyłania poleceń dotyczących pojazdu i pobierania informacji o kliencie za pośrednictwem luk w zabezpieczeniach mających wpływ na usługę telematyki pojazdu Toyota IDOR w Toyota Financial, który ujawnia imię i nazwisko, numer telefonu, adres e-mail oraz status pożyczki wszystkich klientów finansowych Toyota Jaguar, Land Rover Identyfikator konta użytkownika ujawniający skrót hasła, imię i nazwisko, numer telefonu, adres właściciela i informacje o pojeździe SiriusXM Wyciekły klucze AWS z pełnym organizacyjnym dostępem do odczytu/zapisu S3, możliwością odzyskania wszystkich plików, w tym baz danych użytkowników, kodu źródłowego i plików konfiguracyjnych dla Syriusza. Używanie GPS-u do śledzenia lokalizacji pojazdu Co więcej, odkryte luki mogły umożliwiać hakerom śledzenie samochodów w czasie rzeczywistym, narażając miliony właścicieli na potencjalne zagrożenia i mogąc naruszyć ich prywatność bez ich wiedzy. „Jedna z luk w systemie telematycznym Porsche umożliwiła atakującym uzyskanie lokalizacji pojazdów, a także wysyłanie poleceń, co czyni tę markę jedną z najbardziej dotkniętych tym problemem!” Wystąpiły również luki w Spireon, oprogramowaniu do śledzenia GPS. Zapewnienie atakującym pełnego dostępu do panelu zdalnego zarządzania firmą sprawia, że mogą oni: odblokowywać samochód, uruchamiać silnik, wyłączać rozrusznik. Ponadto producent cyfrowych tablic rejestracyjnych, Reviver, również okazał się narażony na ataki, a jego panel administracyjny wyjątkowo podatny na nieuwierzytelniony dostęp zdalny. Co powinni zrobić właściciele samochodów? Właściciele mogą zminimalizować ryzyko, upewniając się, że ich pojazdy lub towarzyszące im aplikacje mobilne zawierają tylko ograniczone dane osobowe. Źródło: https://sekurak.pl/pokazali-podatnosciami-w-api-mozna-bylo-przejmowac-konta-pracownikow-dealerow-bmw-rolls-royce-efekt-mieli-mozliwosc-wgladu-w-szczegoly-dokumentacje-serwisowe-samochodow/ https://samcurry.net/web-hackers-vs-the-auto-industry/ https://sekurak.pl/zhackowali-system-kia-pokazali-jak-mozna-przejmowac-samochody-zdalne-otwieranie-uruchamianie-samochodow-dostep-do-kamer/ https://sekurak.pl/prostymi-podatnosciami-wjechal-w-infrastrukture-it-mercedesa-przejecie-wielu-serwerow-rce-bez-uwierzytelnienia-dostep-do-wewnetrznego-chatu/

Zoom, znana aplikacja do przesyłania wiadomości wideo, wydała łatki usuwające wiele luk w zabezpieczeniach. Poprawki są obowiązkowe zarówno dla użytkowników systemów Windows, jak i macOS. Luki w zabezpieczeniach dotyczą produktu Zoom Rooms, przeznaczonego dla przedsiębiorstw. Mogą zostać wykorzystane w atakach polegających na eskalacji uprawnień na wszystkich popularnych platformach. Jest to pierwsza partia łatek na 2023 rok. Obejmuje poprawki trzech luk „o dużej wadze” w Zoom Rooms dla instalatorów Windows, Zoom Rooms dla klientów Windows i Zoom Rooms dla klientów macOS. Oto jak Zoom dokumentuje problemy wysokiego ryzyka: CVE-2022-36930 — lokalna eskalacja uprawnień w Zoom Rooms dla instalatorów systemu Windows (CVSS 8.2/10) — Zoom Rooms dla instalatorów systemu Windows przed wersją 5.13.0 zawiera lukę umożliwiającą lokalne zwiększenie uprawnień. Lokalny użytkownik o niskich uprawnieniach może wykorzystać tę lukę w łańcuchu ataków, aby przekazać swoje uprawnienia użytkownikowi SYSTEM. CVE-2022-36929 — lokalna eskalacja uprawnień w Zoom Rooms dla klientów Windows (CVSS 7.8/10) — Zoom Rooms dla klientów Windows przed wersją 5.12.7 zawiera lukę umożliwiającą lokalne zwiększenie uprawnień. Lokalny użytkownik o niskich uprawnieniach może wykorzystać tę lukę w łańcuchu ataków, aby przekazać swoje uprawnienia użytkownikowi SYSTEM. CVE-2022-36927 — lokalna eskalacja uprawnień w Zoom Rooms dla klientów macOS (CVSS 8.8/10) — Zoom Rooms dla klientów macOS przed wersją 5.11.3 zawierają lukę w zabezpieczeniach umożliwiającą lokalne zwiększenie uprawnień. Lokalny użytkownik o niskich uprawnieniach może wykorzystać tę lukę, aby zwiększyć swoje uprawnienia do uprawnień roota. Zoom wydał również poprawki dla pary błędów średniej wagi w Zoom Rooms dla klientów macOS przed wersją 5.11.4, ostrzegając, że ta wersja oprogramowania zawiera niezabezpieczony mechanizm generowania kluczy. „Klucz szyfrowania używany do IPC między usługą demona Zoom Rooms a klientem Zoom Rooms został wygenerowany przy użyciu parametrów, które można uzyskać za pomocą lokalnej aplikacji o niskich uprawnieniach. Klucz ten może być następnie użyty do interakcji z usługą demona w celu wykonania uprzywilejowanych funkcji i spowodowania lokalnej odmowy usługi”. Zoom naprawił również lukę w zabezpieczeniach związaną z przechodzeniem ścieżki w programie dla klientów Androida, ostrzegając, że aplikacja innej firmy może wykorzystać tę lukę do odczytu i zapisu w katalogu danych aplikacji Zoom.

Udostępnili ~200 milionów rekordów do pobrania. Wyciek brzmi groźnie, ale zawsze warto sprawdzać co dokładnie wyciekło i kiedy. W każdym razie na jednym z forów pojawiły się linki do bazy, a także demo tego co wyciekło: Gdzie sprawdzić czy Twój e-mail wyciekł w tej akcji? Tutaj: https://haveibeenpwned.com/ (Troy Hunt właśnie zaimportował bazę).

Uważajcie na scam na FB promujący oprogramowanie do mierzenia "pedkości" łącza internetowego. Jedynie co ono zmierzy to szybkość w jakim zareagujecie na skradzione dane... a tak na serio to scam. Zdjęcie zapożyczone z portalu sekurak - gdzie został on poddany analizie i link z FaceBook prowadzi do: hxxps://mega(kropka)nz/file/iFlyWAxD#EpqvqJd6ZtgtDrjN1LquBZ3vQWX8hd7rC1N2dztXGcc Virustotal - zgłaszan że jest rozpoznawany tylko przez 11 vendorówna 57. Jak widać coraz wiecej kampani w stylu "wykupimy reklamę by się do Ciebie dobrać". Popularność serwisów FB czy google powoduje że czasami wyłączamy myślenie, a powinno być wręcz przeciwnie. Dajcie znać mniej technicznym kolegą, rodzicom, znajomym. A i też uważajcie na siebie. Oczywiście możemy zgłosić taką reklamę:

Firma NVIDIA udostępniła dzisiaj sterownik graficzny NVIDIA 525.78.01 dla systemów GNU/Linux, FreeBSD i Solaris, aby naprawić kilka błędów w poprzednich wersjach gotowej do produkcji gałęzi zastrzeżonego sterownika wideo. NVIDIA 525.78.01 ma poprawić obsługę aplikacji Vulkan X11, usuwając regresję, która uniemożliwiała wyświetlanie wskaźnika wizualnego zgodnego z G-SYNC/G-SYNC, oraz naprawiając błąd, który mógł powodować awarie aplikacji z błędami Xid 32 podczas korzystania z VK_KHR_present_id rozszerzenie Vulkan. Naprawia również awarię panelu sterowania nvidia-settings, która występowała podczas korzystania z nowszego panelu sterowania ze starszą wersją sterownika graficznego NVIDIA , a także błąd powodujący nadmierne użycie procesora w hybrydowych konfiguracjach graficznych, w których podłączony jest zewnętrzny monitor do oddzielnej karty graficznej NVIDIA i skonfigurowany jako pochłaniacz PRIME Display Offload. Sterownik graficzny NVIDIA 525.78.01 jest już dostępny do pobrania z oficjalnej strony internetowej . Jest oznaczony jako „Najnowsza wersja gałęzi produkcyjnej”, co oznacza, że ​​jest zalecany do instalacji na maszynach produkcyjnych, na których używasz sterownika NVIDIA 525.60.11 lub wcześniejszej wersji. Pliki do pobrania są dostępne dla platform Linux 64-bitowych i ARM64 (AArch64), a także dla 64-bitowych systemów FreeBSD i x64/x86 Solaris. Instrukcje instalacji znajdują się na stronie pobierania dla każdej wersji, jeśli ręcznie instalujesz sterownik karty graficznej NVIDIA. Ci z was, którzy chcą zainstalować moduł jądra GPU typu open source, będą musieli sprawdzić stronę GitHub , aby zapoznać się z otwartymi modułami jądra GPU NVIDIA Linux. Jeśli nie lubisz ręcznej instalacji, będziesz musiał poczekać, aż nowa wersja sterownika pojawi się w stabilnych repozytoriach oprogramowania Twojej ulubionej dystrybucji GNU/Linux, aby ją zaktualizować.

Niedawno dowiedzieliśmy się o problemie z bezpieczeństwem związanym z nieautoryzowanym dostępem do podzbioru repozytoriów kodu Slacka. Klienci nie zostali dotknięci, nie są wymagane żadne działania, a incydent został szybko rozwiązany. Slack udostępniamy szczegóły incydentu. Co się stało 29 grudnia 2022 roku zostaliśmy powiadomieni o podejrzanej aktywności na naszym koncie GitHub. Po przeprowadzeniu dochodzenia odkryliśmy, że ograniczona liczba tokenów pracowniczych Slack została skradziona i niewłaściwie wykorzystana w celu uzyskania dostępu do naszego zewnętrznego repozytorium GitHub. Nasze dochodzenie ujawniło również, że cyberprzestępca pobrał prywatne repozytoria kodu 27 grudnia. Żadne pobrane repozytoria nie zawierały danych klientów, środków dostępu do danych klientów ani podstawowej bazy kodów Slacka. Nasza odpowiedź i dochodzenie Po powiadomieniu o incydencie natychmiast unieważniliśmy skradzione tokeny i rozpoczęliśmy badanie potencjalnego wpływu na naszych klientów. Nasze obecne ustalenia pokazują, że cyberprzestępca nie uzyskał dostępu do innych obszarów środowiska Slack, w tym do środowiska produkcyjnego, ani nie uzyskał dostępu do innych zasobów Slacka ani danych klientów. Nie miało to wpływu na nasz kod ani usługi, a także jako środek ostrożności wymieniliśmy wszystkie odpowiednie dane uwierzytelniające. Na podstawie obecnie dostępnych informacji nieautoryzowany dostęp nie wynikał z luki w zabezpieczeniach Slacka. Będziemy nadal badać i monitorować dalsze narażenie. źródło: https://slack.com/intl/en-au/blog/news/slack-security-update

Masowe kampanie złośliwych reklam w Google – podszywają się Visual Studio, Zooma, Slacka, Grammarly, Malwarebytes, Afterburnera, Audacity, Brave, uTorrent czy Dashlane. Na koniec – infekcja komputera. Na sekuraku dużo ostatnio było o tym informacji - Nasz czytelnik wygooglał pakiet instalacyjny Gimpa. Trafił na fejkową reklamę, zainfekował komputer i stracił dostęp do konta Google Kolejna fałszywa reklama w Google, tym razem MSI Afterburner Nasz czytelnik googlował sterowniki do karty graficznej. Kliknął w reklamę i wylądował na zainfekowanej stronie. Uwaga! Reklama nie przenosi Cię na właściwą stronę - łudząco przypomina tą właściwą. Są także inne reklamy więc warto uważać co pobieramy z internetu przez wyszukiwanie tego w google. Opisywany proceder jest o tyle ciekawy, że na początek reklamowane serwisy są całkiem w porządku (nie serwują malware) – to uspokaja Google. Później jeśli normalnie wchodzimy na dany serwis – również wszystko w porządku. Ale jeśli ktoś kliknie w reklamę, trafia na serwis „proxy”, który automatycznie przekierowuje do serwisu z malware: Finalna strona sugeruje pobranie danego oprogramowania np. z GitHuba. I tutaj znowu mniej zorientowani użytkownicy mogą myśleć – pobiorę coś z GitHuba – to na pewno będzie bezpieczne. Błąd: Ładunek złośliwego oprogramowania Vermux — udostępniany bezpłatnie w serwisie GitHub Ładunek Vermux jest w większości zbudowany w oparciu o trojana Vidar do kontroli i pewną zastrzeżoną kompilację oprogramowania do wydobywania Monero opartego na Pythonie. Pliki są zgodne z zasadami, o których wspominaliśmy wcześniej, co sprawia, że ​​są trudne do wykrycia i wymykają się. Vermux nie tylko nadużywa reputacji i siły propagacyjnej Google Ads, ale także nadużywa reputacji znanych usług udostępniania plików i repozytoriów kodu, takich jak BitBucket, GitHub, Dropbox, OneDrive itp. Oto kilka przykładów takich repozytoriów odkrytych w GitHub: Ale widać że jest tego znacznie więcej: Kilka rad: Zainstalujcie AdBlockera – np. uBlock origin. Dokładnie sprawdzajcie pasek adresu strony, z której pobieracie instalatory. Czasem różnica z oryginałem może być minimalna: Przed instalacją warto przeskanować plik instalacyjny w serwisie virustotal.com Konto Google: pamiętaj o silnym haśle (idealnie > 15 znaków), włącz dwustopniowe uwierzytelnienie oraz wygeneruj kody zapasowe (mogą być one potrzebne do sprawnego odzyskania dostępu do konta, jeśli stracisz do niego dostęp). Wszystko to możesz zrobić na zakładce Security (https://myaccount.google[.]com/security) Rozważ skonfigurowanie Google Advanced Protection. Streszczenie Bezpieczeństwo to kwestia zaufania — dlatego stale polegamy na zaufanych, renomowanych dostawcach w naszych codziennych staraniach w Internecie. Nikt nie jest jednak doskonały i prawdopodobnie jest więcej złych aktorów, którzy chcą wykorzystać te luki w zabezpieczeniach, niż możemy sobie wyobrazić. Tutaj dokładnie to widzimy — nieustanny wyścig szczurów między firmami stojącymi za tymi potężnymi systemami reklamowymi, globalną dostawą treści i infrastrukturą bezpieczeństwa do tych wymijających aktorów, którzy znajdują sposób, by wymknąć się spod radaru i wykorzystać zaufanych innych dla własnych korzyści. Ta koncepcja „masquerAd” jest prosta, ale robi dokładnie to, czego potrzebują ci aktorzy — nadużywa zaufania, które czasami ślepo obdarzamy Google i ich promowane wyniki wyszukiwania. Do tego dochodzi nadużywanie renomowanych serwisów wymiany plików oraz znanych marek oprogramowania, co sprawia, że ​​omijają one nawet najbardziej zaawansowane EDR-y na rynku. Stosowanie bardziej behawioralnego i bezstronnego poziomu ochrony jest nieuniknione — nawet w przypadku najprostszych i najczęstszych czynności, takich jak wyszukanie czegoś w googlach… Nie daj się nabrać na błędne nazwy domen i zawsze dokładnie sprawdzaj, skąd pobierasz pliki!

Curl https://cheat.sh/ Features cheat.sh Has a simple curl/browser/editor interface. Covers 56 programming languages, several DBMSes, and more than 1000 most important UNIX/Linux commands. Provides access to the best community driven cheat sheets repositories in the world, on par with StackOverflow. Available everywhere, no installation needed, but can be installed for offline usage. Ultrafast, returns answers within 100 ms, as a rule. Has a convenient command line client, cht.sh, that is very advantageous and helpful, though not mandatory. Can be used directly from code editors, without opening a browser and not switching your mental context. Supports a special stealth mode where it can be used fully invisibly without ever touching a key and making sounds. Fajne to :)

Mowa o https://whatsmyname.app/ wystarczy wpisać jeden (lub więcej) nicków w pole wyszukiwania https://twitter.com/osintcombine/status/1609375630579372035?s=20&t=ym9b3TVgTD_Cg7cD5yyoOA

Na pewno każdy z Was spotkał się z sytuacją kiedy super promocja posiadała tak naprawdę cenę wyższą, niż ta regularna sprzed promocji. Z tym właśnie ma walczyć nowe prawo, które weszło od 1. stycznia https://sip.lex.pl/akty-prawne/dzu-dziennik-ustaw/informowanie-o-cenach-towarow-i-uslug-18109812/art-4 W każdym przypadku informowania o obniżeniu ceny towaru lub usługi obok informacji o obniżonej cenie uwidacznia się również informację o najniższej cenie tego towaru lub tej usługi jaka obowiązywała w okresie 30 dni przed wprowadzeniem obniżki.

Za nami rok 2022 przed nami nowy rok 2023. Nowe możliwości wyzwania czy okazje. Pamiętajmy jednak że, nadal wiele podstępnych metod na pozyskanie naszych pieniędzy dalej działa w internecie. Pamiętajcie by być czujnym i ostrożnym. Jak zwiększyć swoje bezpieczeństwo, poprzez aplikacje Niebezpiecznika - CyberAlert Uważajcie na podobne metody ataku: Uwaga na SMS-y o zawieszeniu konta Netflix Uwaga klienci mBanku! Uwaga na e-maile od Krajowej Administracji Skarbowej! Uwaga klienci ING! Uwaga, nie płaćcie tego mandatu! Orange ostrzega. Uwaga na fałszywe bramki BLIK używane przez polskich złodziei Przestępcy stosują spoofing SMSów przy oszustwach na OLX. Podszywają się pod InPost czy pod sam OLX „Oddam w dobre ręce laptopa” – czyli jak przestępcy organizują sobie darmowe zakupy. Uważajcie Wystarczy tylko „zatwierdzić wniosek o zwrot podatku” aby otrzymać sporo pieniążków. A nie, czekaj, to oszustwo! Z poprzedniego roku może być jeszcze więcej spersonalizowanych ataków: Twierdzi, że ma bazę z danymi 400 milionów użytkowników Twittera Uwaga użytkownicy aplikacji LastPass! LastPass – o co chodzi w wycieku haseł z tego managera i jaki jest koszt złamania wszystkich Twoich haseł? Punktowy wyciek danych kupujących na Allegro. Dane wystawiono na sprzedaż. Incydent nie ma charakteru masowego. Oczywiście jest to tylko przekrój listopadowo / grudniowy. Miłej lektury. Źródła: sekurak.pl https://zaufanatrzeciastrona.pl/ https://niebezpiecznik.pl/

Za nami już cztery cześci o terraform mojego autorstwa o których przeczytasz tu: Materiał na wstęp i część pierwsza. Część druga Część trzecia Część czwarta A w tym artykule spotykamy się po raz piąty - i porozmawiamy sobie o zmiennych i zobaczymy jak dobre zaplanowanie naszego modułu pozwoli nam skonfigurować nasze środowisko developerskie i produkcyjne na podstawie tego samego modułu. Poprzez nadpisywanie zmiennych. Zatem zapraszam materiał do poczytania i obejrzenia. Małe zmiany by uzyskać elastyczność Finalna konfiguracja z części czwartej pozwala nam utworzyć projekt w DigitalOcean (taki byt w DigitalOcean według, którego można organizować "grupować" swoje zasoby) do tego projektu podpinamy strefe DNS. Tworzymy też VPC - czyli naszą sieć poprzez deklaracje adresu sieciowego dla regionów dostępnych w digitalocean - obecnie jest ich czternaście na czas pisania tego artykułu. Koncepcyjnie dla projektu przyjąłem sieć 10.X.0.0/16 i podzieliłem ją na pod sieć 10.X.0.0/20. Pozwoliło mi to pokryć każdy region i pozostawiło mi jeszcze dodatkowe dwa adresy sieci dla moich podsieci jako rezerwowe. Gdybym chciał bazując na tej konfiguracji stworzyc nowy projekt - czyli wykorzystać utworzony moduł. Byłoby to problematyczne ponieważ dużo wartości konfiguracyjnych zdefiniowałem jako stałe wpisy. Postarajmy się przerobić naszą konfiguracje tak by udało się elastycznie tworzyć drugie środowisko w naszym terraform na DigitalOcean. Zacznijmy od zasobu projekt w naszej konfiguracji. Plik procject.tf prezentuje się następująco: Będziemy musieli dodać tak jak to jest w polu name odwołanie do naszej zmiennej która, będzie wstawiać właściwą wartość w odpowiednim polu. Dodajmy zatem naszą odpowiednią zmienną: variable "digitalocean_project" { description = "" type = object({ name = string description = string purpose = string environment = string }) default = { description = "Project for YouTube Channel" environment = "development" name = "YoutubeProject" purpose = "Learning" } } Zmienna już dekralowaliśmy więc nie jest to dla nas jakaś nowość. Nowością może być fakt że nasze wartości które opisują projekt są w jednej zmiennej obiektowej z odpowiednimi własnościami. Deklarując taką zmienną w: type - wpisujemy rodzaj naszej zmiennej, tym razem będzie ona typu obiektowego co pozwoli nam zdefiniować dodatkowe pola i określić typ tych pól. I mamy tu name, description, purpose, environment typu string. default - tu możemy jak poprzednio zdefiniować wartości domyślne dla naszych zmiennych, tak by zabezpieczyć się przed tym jakby, ktoś podczas importowania/używania naszego modułu nie wskazał wartości dla tych zmiennych. Odwołanie teraz do tych zmiennych też już znamy. Dochodzi tutaj tylko aspekt jak odwołać się do poszczególnych wartości w tym obiekcie. Możemy to zrobić za pomocą kropki - czyli: var.digitalocean_project.name Po wprowadzeniu zmiany nasz zasób będzie wyglądał następująco: resource "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name description = var.digitalocean_project.description purpose = var.digitalocean_project.purpose environment = var.digitalocean_project.environment } Możemy już teraz sprawdzić poprzez polecenie terraform plan czy nasza modyfikacja nie wprowadza żadnych zmian w stanie naszego terraforma. Pamiętamy że, w stanie terraform nie są przechowywane zmienne tylko juz wartości tych zmiennych, zatem terraform plan powinien pokazać że nie ma żadnych zmian: Teraz możemy te zmienne użyć w naszym module - a dokładnie w jego deklaracji w pliku main.tf - może to wygladać tak: module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } } Zatem widzimy i wcześniej już to pokazywałem przez deklaracje naszego modułu możemy nadpisywać zadeklarowane zmienne - lub podawac ich wartości jeżeli nasze zmienne były by bez wartości default. Znów uruchomienie terraform plan nic nie zmieni - bo stan zgadza się z tym co jest w naszym backend ze stanem terraform. Możemy też gdybyśmy chcieli zmienić te wartości sprawdzic jak sie zachowa nasz terraform plan gdy taka zamianę testowo wprowadzimy do naszego pliku konfiguracyjnego. Terraform wykrywa zmiany i jak widzimy modyfikuje te wartości które zmieniamy - reszta pozostaje bez zmian i po stronie digitalocean odbywa to się w formie modyfikacji zasobu nie jego usunięcia. Bo i takie modyfikacje sie zdarzają by coś zmienić trzeba zasób najpierw usunąć a potem go dodać na nowo. Oczywiście terraform to robi automatycznie i nasz w podsumowaniu planu o tym informuje. Poprawiamy VPC Zmiana ta będzie zmiana dająca nam elastyczność również w przypadku tworzenia sieci. Obecnie tego nie mamy bo wartość adresu sieciowego tworzonego dla naszego regionu i danego VPC jest podawana na stałe. Musimy zmodyfikować naszą wartość dla pola ip_range na taką by była generowana dynamicznie. Możemy się wzorować na tym co mamy w polu name dla tego zasobu - resource "digitalocean_vpc" "sfo1" {}. Tu będziemy potrzebować dodatkowej zmiennej i musimy ją zadeklarować: variable "secound_octet_number" { description = "value" type = string default = "0" } Po deklaracji jej w naszym pliku vars.tf - mozemy ja wykorzystać w naszej konfiguracji i pliku vpc.tf. Przykład dla jednego regionu: A tu dla kompletnego pokrycia wszystkich regionów: resource "digitalocean_vpc" "nyc1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc1-vpc" region = "nyc1" ip_range = "10.${var.secound_octet_number}.0.0/20" } resource "digitalocean_vpc" "nyc2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc2-vpc" region = "nyc2" ip_range = "10.${var.secound_octet_number}.16.0/20" } resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.${var.secound_octet_number}.32.0/20" } resource "digitalocean_vpc" "sfo1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo1-vpc" region = "sfo1" ip_range = "10.${var.secound_octet_number}.48.0/20" } resource "digitalocean_vpc" "sfo2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo2-vpc" region = "sfo2" ip_range = "10.${var.secound_octet_number}.64.0/20" } resource "digitalocean_vpc" "sfo3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo3-vpc" region = "sfo3" ip_range = "10.${var.secound_octet_number}.80.0/20" } resource "digitalocean_vpc" "tor1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-tor1-vpc" region = "tor1" ip_range = "10.${var.secound_octet_number}.96.0/20" } resource "digitalocean_vpc" "lon1" { name = "terraform-${var.type_env}-${var.name_env}-europe-lon1-vpc" region = "lon1" ip_range = "10.${var.secound_octet_number}.112.0/20" } resource "digitalocean_vpc" "ams2" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams2-vpc" region = "ams2" ip_range = "10.${var.secound_octet_number}.128.0/20" } resource "digitalocean_vpc" "ams3" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams3-vpc" region = "ams3" ip_range = "10.${var.secound_octet_number}.144.0/20" } resource "digitalocean_vpc" "fra1" { name = "terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc" region = "fra1" ip_range = "10.${var.secound_octet_number}.160.0/20" } resource "digitalocean_vpc" "sgp1" { name = "terraform-${var.type_env}-${var.name_env}-asia-sgp1-vpc" region = "sgp1" ip_range = "10.${var.secound_octet_number}.176.0/20" } resource "digitalocean_vpc" "blr1" { name = "terraform-${var.type_env}-${var.name_env}-asia-blr1-vpc" region = "blr1" ip_range = "10.${var.secound_octet_number}.192.0/20" } resource "digitalocean_vpc" "syd1" { name = "terraform-${var.type_env}-${var.name_env}-australia-syd1-vpc" region = "syd1" ip_range = "10.${var.secound_octet_number}.208.0/20" } Mamy nasze VPC obsłużone - zostało nam jeszcze do modyfikacji lekkiej plik domain.tf tak by odwołać się do właściwej nazwy projektu w naszym data - będzie to dokładnie: data "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name } a całość prezentuje się w następujący sposób: data "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name } resource "digitalocean_project_resources" "domain" { project = data.digitalocean_project.youtube-project.id resources = [ digitalocean_domain.dev-technicznie-nietechnicznie-cloud.urn ] } resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" { name = "${var.app_env}.technicznie-nietechnicznie.cloud" } I teraz kompletny plik main.tf module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } type_env = "development" secound_octet_number = "1" name_env = "youtube" app_env = "dev" } Sprawdzamy i znów terraform plan nie pokazuje żadnych zmian. Czas zatem je wprowadzić w postaci uruchomienia nowego projektu na podstawie naszego moduły. Plik main.tf bedzie wyglądał nastepująco: module "myovh" { source = "./modules/myovh" } module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } type_env = "development" secound_octet_number = "1" name_env = "youtube" app_env = "dev" } module "digitalocean-youtube2" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "ProdYoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "production" } type_env = "production" secound_octet_number = "2" name_env = "newyoutube" app_env = "prod" } Sprawdźmy zatem ile i jakie zmiany dokonają się w naszym stanie i na naszym DigitalOcean. wydajemy polecenie terraform init i potem terraform plan Jak widzimy w podsumowaniu zostanie dodanych siedemnaście zasobów w digitalocean jako nowe - czyli nasz poprzedni moduł i utworzone zasoby nie zostaną w żaden sposób zmodyfikowane. Możemy teraz to zweryfikować po stronie DigitalOcean i pokaże nam się nowy projekt: W projekcie nowo utworzonym widzimy że, nasza domena została prawidłowo podpieta I sieci zostały po tworzone dla naszych regionów - vpc nie mozna przypisac do projektu dlatego widoczne są też te wcześniej tworzone dla poprzedniego modułu w terraform. Jak widać wszystko działa i zachowuje się według ustalonej konfiguracji. W tym artykule to wszystko. Daj znać czy taka seria Ci się podoba. Pozdrawiam.

Niestety przed samymi świętami (23 grudnia) zdarzyło się to, czego najbardziej obawiają się administratorzy systemów – ujawniono poważną lukę bezpieczeństwa w systemach Linux. Zero Day Initiative (ZDI), firma zajmująca się badaniami nad podatnościami typu zero-day, ogłosiła nowy błąd jądra Linuksa. Luka umożliwia uwierzytelnionym użytkownikom zdalne ujawnianie poufnych informacji oraz uruchamianie kodu w podatnych na ataki wersjach jądra. Zródło: https://nakedsecurity.sophos.com/2022/12/27/critical-10-out-of-10-linux-kernel-smb-hole-should-you-worry/ Any Linux from 5.15.61 on, or any 6.x, is already patched. Pierwotnie ZDI oceniło podatność jako krytyczne 10 w skali od 0 do 10 powszechnego CVSS. Teraz luka ma „tylko” 9.6, co w praktyce nadal oznacza „załataj najszybciej, jak się da!”. Problem dotyczy programu ksmbd, wersji jądra 5.15 usługi Server Message Block (SMB). Konkretnie podatność występuje w przetwarzaniu poleceń SMB2_TREE_DISCONNECT i wynika z braku walidacji istnienia obiektu przed wykonaniem na nim operacji. Osoba atakująca może wykorzystać tę lukę do wykonania kodu w kontekście jądra. Nowy moduł SMB, opracowany przez firmę Samsung, został wprowadzony do jądra Linux w 2021 roku. Jego celem było zapewnienie wysokiej wydajności w obsłudze plików SMB v3. Jak wiadomo, protokół SMB używany jest w systemie Windows, a w systemie Linux – jako nadrzędny protokół wymiany plików za pośrednictwem Samby. Podatny moduł ksmbd nie ma na celu zastąpienia Samby, ale jej uzupełnienie. Deweloperzy Samby i ksmbd pracują nad tym, aby programy działały wspólnie. Jeremy Allison, współtwórca Samby, zauważa: „ksmbd nie współdzieli kodu z produkcyjną wersją protokołu Samba. Jest napisany całkowicie od zera. Tak więc obecna sytuacja nie ma nic wspólnego z serwerem plików Samba, który można bez obaw uruchamiać w swoich systemach”. Każda dystrybucja korzystająca z jądra Linuksa 5.15 lub nowszego jest potencjalnie podatna na ataki. Obejmuje to Ubuntu 22.04 i jego następców oraz Deepin Linux 20.3. Jeśli chodzi o serwery, Ubuntu jest najbardziej niepokojące. Inne dystrybucje wykorzystywane przemysłowo, takie jak rodzina Red Hat Enterprise Linux (RHEL), nie używają jądra 5.15. Aby zweryfikować, czy na konkretnej dystrybucji Linuksa uruchomiona jest podatna usługa, należy wykonać: $ uname -r aby zobaczyć, której wersji jądra używasz; $ modinfo ksmb – aby sprawdzić, czy podatny moduł jest obecny w systemie i uruchomiony. Any Linux from 5.15.61 on, or any 6.x, is already patched. To check your Linux version: $ uname -o -r 6.1.1 GNU/Linux To see if this kernel feature is compiled in, you can dump the compile-time configuration of the running kernel: $ zcat /proc/config.gz | grep SMB_SERVER # CONFIG_SMB_SERVER is not set If this compile-time configuration setting is unset, or set to "n" for no, the feature wasn't built at all. If it says "y" for yes, then the kernel SMB server is compiled right into your kernel, so ensure you have a patched version. If it says "m" for module, then the kernel build probably includes a run-time module that can be loaded on demand. To see if your kernel has a loadable module available: $ /sbin/modprobe --show ksmbd modprobe: FATAL: Module ksmbd not found in directory /lib/modules/6.1.1 Note that "--show" means "never actually do it, just show if loading it would work or not". To see if your system has the ksmbd module already active: $ lsmod | grep ksmbd If you see no output, the module wasn't matched in the list. To stop the module loading inadvertently in case it ever shows up, add a file with a name such as ksmbd.conf to the directory /lib/modules.d or /etc/modules.d with these lines in it: blacklist ksmbd install ksmbd /bin/false To, co chcemy zobaczyć, to to, że moduł nie został znaleziony. Jeśli jest załadowany do pamięci, powinniśmy natychmiast wykonać aktualizację jądra Linux do wersji przynajmniej 5.15.61. Niestety nie wszystkie dystrybucje otrzymały już aktualizacje. Lista jest dostępna tutaj. Niektórzy zastanawiają się, czy omawiana podatność jest rzeczywiście tak poważna, jeśli nie nadano jej nawet numeru CVE. Greg Kroah-Hartmann, opiekun jądra Linuksa, wyjaśnił: „…programiści jądra w ogóle nie pracują z CVE, ponieważ w większości nie są one odwzorowaniem konkretnych problemów”. To prawda, że „niektóre organizacje linuksowe nadal nalegają na przypisywanie CVE, ale ma to przede wszystkim na celu umożliwienie wewnętrznych procesów inżynieryjnych”. Warto pamiętać, że implementacje Windows SMB mają długą, brzydką historię swoich zabezpieczeń. Rozpoczynając od podatnego i nieużywanego już SMB v1 (WannaCry), a kończąc na SMBGhost, który otworzył komputery z systemem Windows 10 na ataki bez uwierzytelnienia. Nie tylko osoby z zewnątrz martwią się o bezpieczeństwo ksmbd. Kees Cook, starszy programista zajmujący się bezpieczeństwem jądra Linuksa, napisał: „Niektóre z tych luk to dość fundamentalne właściwości bezpieczeństwa systemu plików, których nie testowano pod tym kątem”. Podsumował: „Martwię się tutaj o jakość kodu i myślę, że coś musi się zmienić w procesach recenzji i testowania”. Taka wypowiedź świadczy o tym, że zawodzą wewnętrzne procedury testów bezpieczeństwa, które powinny być pierwszym etapem znajdowania i naprawiania takich właśnie błędów. Aktualizacje z poprawkami są dostępne, ale sytuacja pokazuje, że kod wymaga dokładniejszego przeglądu i zabezpieczenia, zanim wszyscy będziemy w stanie zaufać mu w pełni na produkcji. Rozsądnie byłoby na razie załatanie jądra i wstrzymanie się z jego używaniem na rzecz funkcjonalności Samba.

Jak dowiedział się Dziennik Gazeta Prawna, planowane są nowe zmiany m.in. w Prawie Telekomunikacyjnym. Rząd chce zaproponować stworzenie katalogu zastrzeżonych nadpisów dla instytucji publicznych. Operatorzy telekomunikacyjni mieliby obowiązek blokowania SMS-ów, które korzystałyby z nadpisu znajdującego się we wspomnianym katalogu, a wychodzących z innego systemu (tzw. bramki SMS) niż tego zarządzanego przez państwo. Nadpis to nic innego jak nazwa nadawcy, którą widać na górze SMSa (w tym przypadku to InPost). Oczywiście ostatni SMS nie przyszedł wcale od InPostu, a jedynie przestępca wysyłając wiadomość podał nazwę nadawcy: InPost (sieci komórkowe pozwalają obecnie na takie „akcje”). I właśnie z tym ma walczyć nowe prawo. Wracając do oryginalnego cytatu, być może możliwość zastrzeżenia nazwy nadawcy będą miały tylko instytucje rządowe: (…) obowiązek blokowania SMS-ów, które korzystałyby z nadpisu znajdującego się we wspomnianym katalogu, a wychodzących z innego systemu (tzw. bramki SMS) niż tego zarządzanego przez państwo. Regulacja ta ma wprowadzić możliwość nieodpłatnego wysyłania SMS-ów m.in. przez organy administracji rządowej, sądy, prokuraturę, samorządy, NFZ, ZUS czy KRUS. Czy więc – jak zresztą wskazują eksperci cytowani w opracowaniu DGP – czeka nas teraz fala SMSów z ZUSu, sądów czy innych instytucji rządowych? Niby lepiej dostać SMSa informującego, że coś mam sprawdzić w ZUSie (niż zwykłą pocztę „za pobraniem”), ale z drugiej strony może to skusić przestępców do podszywania się pod te instytucje („wiadomo przecież że ZUS pisze SMSy”). Czekamy na rozwój sytuacji, w tym kwestii czy również prywatne instytucje (np. InPost) mogłyby być włączone do takiego rejestru.

Okta, producent rozwiązań Identity and Access Management (IAM), w swoim oświadczeniu napisało, że zostali zhackowani w tym miesiącu. W wyniku ataku zostały wykradzione kody źródłowe z repozytoriów platformy GitHub. Niestety w tym roku to nie pierwszy przypadek, więcej poczytać możesz na sekuraku: Pierwszy przypadek włamania do okta w tym roku: https://sekurak.pl/wlamanie-do-okta-swiatowego-lidera-w-zarzadzaniu-tozsamoscia/ Zatakowała grupa LAPSUS$ https://sekurak.pl/lapsus-dobralismy-sie-kodow-zrodlowych-microsoftu-bing-bing-maps-cortana/ GitHub poinformował dostawcę o “podejrzanej aktywności” z początkiem miesiąca. Okta zablokowało dostęp do swoich repozytoriów, weryfikując wszystkie dostępy. Następnie stwierdzili, że cyberprzestępcy uzyskali dostęp do kodów źródłowych rozwiązania Workforce Identity Cloud (WIC) – czyli rozwiązania bezpieczeństwa klasy enterprise będącego w ofercie Okta. Jednocześnie wskazali, że nie doszło do naruszenia bezpieczeństwa usług związanych z danymi klientów i Auth0, które zostało zakupione w 2021. źródło: https://sec.okta.com/articles/2022/12/okta-code-repositories https://sekurak.pl/okta-ponownie-z-incydentem-skradzione-kody-zrodlowe/

W kolejnej czwartej części zajmiemy się konfiguracja naszego Digital Ocean i tu skonfigurujemy nasze sieci (Networking) - czyli VPC dla adresu sieciowego 10.1.0.0/16 z podziałem na podsieci, oraz skonfigurujemy strefa DNS (Domain) dla dev.technicznie-nietechnicznie.cloud. Dodamy też trochę zmiennych tak by nasza konfiguracja była bardziej elastyczna. Jeżeli trafiłeś tu i nie znasz poprzednich materiałów poniżej mały spis (poroponowana kolejność czytania): część pierwsza - Infrastruktura jako kod (IaaC) - cześć 1 część druga - Zmieńmy naszą konfigurację na moduł. Infrastruktura jako kod (IaaC) - cześć 2 część trzecia - Infrastruktura w Kodzie (IaaC) - Digital Ocean, prosty cloud na start - część trzecia. Wstępniak teoretyczny: Terreform - początki (czysto teoretyczne) Dodajmy zmienne W terraform często będziemy wykorzystywać zmienne lub się do nich odnosić na różne sposoby. Będziemy też wykorzystywać wartości, które wygeneruje nam pewien zasób (resources) stworzony w Digital Ocean, a że nie znamy jego nazwy przed stworzeniem czy identyfikatora będziemy musieli się do niego jakoś odnieść - po przez właśnie zmienne lub "kotwice". Zadeklarujemy sobie kilka zmiennych na początek. Tworzymy plik vars.tf - jego konstrukcja bedzie nastepująca: variable "type_env" { description = "Type enviroment example: development, staging or production." type = string default = "development" } variable "name_env" { description = "Name enviroment." type = string default = "youtube" } variable "app_name_type" { description = "Application name" type = string default = "dev" } variable "app_name" { description = "Application name" type = string default = "Application" } Nie pierwszy raz już deklarujemy nasze zmienne więc sposób deklaracji ich w terraform nie powinien być dla nas zaskoczeniem. Spojrzymy tylko na nowe elementy: type - określa jakiego typu jest to zmienna - w tym przypadku jest to string - isinieje jeszcze kilka innych typów. default - określa domyślna wartość w przypadku nie podania tej zmiennej przez użytkownika terafforma (operatora). Pierwszą zmienna z naszej listy type_env możemy wykorzystać już w poprzednio naszym utworzonym pliku project.tf - wykorzystanie bedzie bardzo proste wskazujemy jaki obiekt nas interesuje w tym przypadku var a po kropce odwołujemy się do nazwy naszej zmiennej - całość prezentuje się tak resource "digitalocean_project" "youtube-project" { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = var.type_env } Naszą zmienna type_env użyjemy w wartości enviroment. Dzięki temu będziemy mogli później przez nasz moduł nadpisywać te zmienne i uruchomić przykładowo takie samo środowisko produkcyjne w naszej konfiguracji. Po prostu tworząc nowy moduł a w nim tylko nadpisując zmienne. Przykład poniżej: module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } type_env = "production" } Tak uruchomiony kod w Terraform dla mojej aktualnej konfiguracji oczywiście spowodowałby zmiany ponieważ ja już mam skonfigurowany projekt w DigitalOcean z wartości development dla enviroment w resources "digitalocean_project" "youtube-project". Sprawdzenie potwierdziło, że funkcjonalność działa tak jak należy. Konfigurujemy sieć dla naszych regionów Regionów w digitalocean nie jest tak dużo jak w AWS czy Azure, ale liczba 14 regionów i konieczność ręcznej konfiguracji sieci w każdym z tych regionów byłaby męcząca. Wezmę sieć 10.1.0.0/16 i podzielę ja na podsieci z maską 10.1.X.X/20 (cidr). Da to mi w moim przypadku podział na 16 podsieci czyli przy 14 regionach jest to idealny podział. W digitalocean regiony mamy następujące: North America: NYC1 NYC2 NYC3 SFO1 SFO2 SFO3 TOR1 Europe: LON1 AMS2 AMS3 FRA1 Asia: SGP1 BLR1 Australia: SYD1: Konfiguracja sieci odbywać się będzie w następujący sposób poprzez resources "digitalocean_vpc" poniżej przykład dla jednego regionu: resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.1.32.0/20" } Gdzie odpowiednie pola: name - to nazwa naszej sieci (vpc) region - to informacja dla jakiego regiony bedzie dostepna ta konkretna sieć ip_range - tu podział na moje subnety A tak prezentuje się całościowo plik konfiguracyjny vpc.tf: resource "digitalocean_vpc" "nyc1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc1-vpc" region = "nyc1" ip_range = "10.1.0.0/20" } resource "digitalocean_vpc" "nyc2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc2-vpc" region = "nyc2" ip_range = "10.1.16.0/20" } resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.1.32.0/20" } resource "digitalocean_vpc" "sfo1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo1-vpc" region = "sfo1" ip_range = "10.1.48.0/20" } resource "digitalocean_vpc" "sfo2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo2-vpc" region = "sfo2" ip_range = "10.1.64.0/20" } resource "digitalocean_vpc" "sfo3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo3-vpc" region = "sfo3" ip_range = "10.1.80.0/20" } resource "digitalocean_vpc" "tor1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-tor1-vpc" region = "tor1" ip_range = "10.1.96.0/20" } resource "digitalocean_vpc" "lon1" { name = "terraform-${var.type_env}-${var.name_env}-europe-lon1-vpc" region = "lon1" ip_range = "10.1.112.0/20" } resource "digitalocean_vpc" "ams2" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams2-vpc" region = "ams2" ip_range = "10.1.128.0/20" } resource "digitalocean_vpc" "ams3" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams3-vpc" region = "ams3" ip_range = "10.1.144.0/20" } resource "digitalocean_vpc" "fra1" { name = "terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc" region = "fra1" ip_range = "10.1.160.0/20" } resource "digitalocean_vpc" "sgp1" { name = "terraform-${var.type_env}-${var.name_env}-asia-sgp1-vpc" region = "sgp1" ip_range = "10.1.176.0/20" } resource "digitalocean_vpc" "blr1" { name = "terraform-${var.type_env}-${var.name_env}-asia-blr1-vpc" region = "blr1" ip_range = "10.1.192.0/20" } resource "digitalocean_vpc" "syd1" { name = "terraform-${var.type_env}-${var.name_env}-australia-syd1-vpc" region = "syd1" ip_range = "10.1.208.0/20" } Wartość ta terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc jest niczym innym jak generowaną nazwa dla vpc na podstawie stałych elementów + uzupełniona z wcześniej zadeklarowanych zmiennych wartościami. Możemy teraz uruchomić terraform plan i sprawdzić czy wszystko będzie dodane prawidłowo. Komunikat o 14 dodanych zasobach jest poprawnym komunikatem. Terraform apply i możemy weryfikować po stronie DigitalOcean czy mamy wszystkie VPC stworzone. DNS po stronie Digital Ocean - działamy z modułem OVH Dobrze mieć naszą konfigurację tak ustawiona dla naszych maszyn wirtualnych że, będa one automatycznie otrzymywać nazwy FQDN. Tworząc zasób w digital ocean oprócz IP będę też mu przydzielał łatwiejszą do zapamiętania nazwę kanoniczna. W głowie wolę pamiętać numery telefonów a nie adresy IP :) Muszę zatem wykierować moją subdomenę z OVH do DigitalOcean. Dlatego też stworzony wczesniej moduł OVH i obsługiwany w terraform wykorzystam do tego. Mogę szybko tą zmianę zrobić z poziomu mojego kodu. Tworzę trzy rekordy NS kierujące na moją zone w DigitalOcean. resource "ovh_domain_zone_record" "ns1-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns1.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } resource "ovh_domain_zone_record" "ns2-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns2.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } resource "ovh_domain_zone_record" "ns3-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns3.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } Konfiguracja po stronie DigitalOcean będzie wyglądać następująco - tworzymy nowy plik domain.tf data "digitalocean_project" "youtube-project" { name = "YoutubeProject" } resource "digitalocean_project_resources" "domain" { project = data.digitalocean_project.youtube-project.id resources = [ digitalocean_domain.dev-technicznie-nietechnicznie-cloud.urn ] } resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" { name = "${var.app_name_type}.technicznie-nietechnicznie.cloud" } Pojawiły nam się trzy nowe obiekty oraz nowy typ w terraform, data - dostępny z naszego providera digitalocean. data "digitalocean_project" "youtube-project" - to wartość, która pobierze nam kilka pól z projektu o nazwie "YoutubeProject" ale nas będzie głownie interesować ID naszego projektu. Potrzebny będzie ono nam do połączenia URN Domeny z ID projektu i w ten sposób zapięcia Domeny w DigitalOcean do naszego projektu który stworzyliśmy. resource "digitalocean_project_resources" "domain" - zasób ten właśnie robi nam połączenia i w ten sposób Projekt w Digital Ocean wie że domena dev.technicznie-nietechnicznie.cloud należy do tego własnie projektu jakim jest "YoutubeProject" resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" - to już deklaracja samej naszej Zony jeszcze bez rekordów, nie licząc trzech rekordów NS) Już na tym etapie wiemy co robimy :) wiec po naszym terraform plan, terraform apply sprawdzamy czy mamy naszą zone w digitalocean. Projekt pokazuje nam naszą zone - zatem wszystko mamy skonfigurowane jak należy. W tym artykule to tyle, w kolejnym materiale uruchomimy naszą pierwsza aplikacje skonfigurowana w terraform.