S3 Ep108: HÁROMMILLIÁRD dollárt rejtett egy pattogatott kukorica dobozba?

Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.

DOUG.  Twitter-csalások, Patch Kedd és bűnözők feltörése.

Mindez és még sok más a Naked Security podcastban.

[ZENEI MODEM]

Üdvözlünk mindenkit a podcastban.

Doug vagyok.

Ő Paul Ducklin.

Paul, hogy vagy ma?

---

KACSA.  Nagyon jól, Doug.

Nálunk Angliában nem volt holdfogyatkozás, de rövid bepillantást kaptam a *teli* teliholdba a felhők egy apró résén keresztül, amely az egyetlen lyukként jelent meg az egész felhőrétegben abban a pillanatban, amikor kimentem. vessen egy pillantást!

De nálunk nem volt az a narancssárga hold, mint nektek Massachusettsben.

---

DOUG.  Kezdjük ezzel az előadást Ezen a héten a technikatörténetben… ez egészen régre nyúlik vissza.

Ezen a héten, 08. november 1895-án Wilhelm Röntgen német fizikaprofesszor a sugárzás egy még fel nem fedezett formájára bukkant, ami arra késztette, hogy ezt a sugárzást egyszerűen „X”-nek nevezze.

Mint a röntgennél.

Mit szólnál ehhez… a röntgensugarak véletlen felfedezéséhez?

---

KACSA.  Egészen elképesztő.

Emlékszem, anyám azt mondta nekem: az 1950-es években (az Egyesült Államokban biztosan így volt), nyilván cipőboltokban…

---

DOUG.  [TUDJA MI JÖN] Igen! [NEvet]

---

KACSA.  Az emberek bevinnék a gyerekeiket... beálltál ebbe a gépbe, felvennéd a cipőt, és ahelyett, hogy csak azt mondanád: „Sétálj, szűkek? Csípnek?” – ültél be egy röntgenkészülékbe, amely lényegében röntgensugárzásban fürdött meg, és készített egy élőképet, és azt mondta: „Ó, igen, a méretük megfelelő.”

---

DOUG.  Igen, egyszerűbb idők. Kicsit veszélyes, de…

---

KACSA.  KICSIT VESZÉLYES?

El tudod képzelni azokat az embereket, akik a cipőboltokban dolgoztak?

Biztosan végig a röntgenben fürödtek.

---

DOUG.  Abszolút… nos, ma egy kicsit nagyobb biztonságban vagyunk.

És ami a biztonságot illeti, a hónap első keddje a Microsoft javítási keddje.

So mit tanultunk ez a Patch Kedd itt 2022 novemberében?

Csere 0 napos fix (végre) – plusz 4 vadonatúj Patch Kedd 0 nap!

---

KACSA.  Nos, az a szuperizgalmas dolog, Doug, hogy technikailag a Patch Tuesday nem egy, nem kettő, nem három… hanem *négy* nulla napot javított ki.

De valójában a Microsoft-termékekhez kedden beszerezhető javítások *hat* nulla napot rögzítettek.

Emlékezzen azokra az Exchange nulladik napokra, amelyeket köztudottan nem javítottak ki a legutóbbi javítási kedden: CVE-2002-41040 és CVE-2022-41082, amelyek az ún. ProxyNotShell?

S3 Ep102.5: „ProxyNotShell” Exchange-hibák – egy szakértő beszél [Hang + szöveg]

Nos, ezeket javították, de lényegében a Patch Tuesday külön „mellékletében”: az Exchange 2022 novemberi SU-ban vagy a szoftverfrissítésben, amely csak annyit mond:

A 2022. novemberi Exchange szoftverfrissítések javításokat tartalmaznak a 29. szeptember 2022-én nyilvánosan bejelentett nulladik napi sebezhetőségekhez.

Csak frissítenie kell az Exchange-et.

Hű, köszönöm Microsoft… Azt hiszem, tudtuk, hogy ezt kell tennünk, amikor végre megjelentek a javítások!

Tehát *kikerültek*, és két nulla nap van rögzítve, de ezek nem újak, és technikailag sem szerepelnek a „Patch Tuesday” részben.

Ott van még négy nulladik napunk.

És ha hiszel a javítások rangsorolásában, akkor nyilvánvalóan ezekkel akarsz először foglalkozni, mert valaki már tudja, hogyan kell rossz dolgokat csinálni velük.

Ezek a biztonsági bypass-tól a két jogosultság-emelésig és egy távoli kódvégrehajtásig terjednek.

De több mint Összesen 60 folt, és ha megnézi az érintett termékek és Windows-összetevők átfogó listáját, a szokásos módon hatalmas listát találunk, amely minden Windows-összetevőt/terméket tartalmaz, amelyekről hallott, és sokakat valószínűleg nem.

A Microsoft 62 biztonsági rést javít ki, köztük a Kerberost, a Mark of the Webet és az Exchange-et…

Szóval, mint mindig: Ne késlekedj/Tedd meg még ma, Douglas!

---

DOUG.  Nagyon jó.

Beszéljünk most egy nagy késésről…

Nagyon érdekes történeted van ezzel kapcsolatban Selyemút drogpiac, és emlékeztet arra, hogy a bûnözõktõl lopó bûnözõk továbbra is bûnnek számítanak, még akkor is, ha körülbelül tíz év elteltével ténylegesen rajtakapják érte.

A Selyemút kábítószerpiaci hackere bűnösnek vallja magát, 20 év börtönre néz

---

KACSA.  Igen, még azok is valószínűleg hallottak a „Selyemútról”, amely talán az első jól ismert, nagyszabású, széles körben elterjedt, széles körben használt sötét webes piactér, ahol gyakorlatilag bármi elérhető.

Szóval mindez 2013-ban lángba borult.

Mivel az alapító, eredetileg csak ún Dread Pirate Roberts, de végül kiderült, hogy az Ross Ulbricht… gyenge működési biztonsága elég volt ahhoz, hogy a tevékenységeket hozzá tudjon kötni.

A Silk Road alapítója, Ross Ulbricht feltételes szabadlábra helyezés nélkül kap életet

Nemcsak a működési biztonsága nem volt túl jó, de úgy tűnik, hogy 2012 végén (elhiszed, Doug?) egy baklövést követtek el a kriptovaluta fizetések feldolgozásakor…

---

DOUG.  [GASPS GÚNYÚ HORRORBAN]

---

KACSA.  …azt a típust, amit azóta is sokszor láttunk, ami nem egészen megfelelő kettős könyvelést csinált, ahol minden terheléshez van egy megfelelő jóváírás és fordítva.

És ez a támadó felfedezte, hogy ha pénzt helyez a számlájára, majd nagyon gyorsan kifizeti más számlákra, akkor valójában ötször (vagy akár többször is) kifizetheti ugyanazt a bitcoint, mielőtt a rendszer észrevenné, hogy az első terhelés megszűnt. keresztül.

Tehát alapvetően beletehetsz egy kis pénzt, majd újra és újra és újra kiveheted, és nagyobb rejtekhelyet kaphatsz…

…és akkor visszatérhetsz az úgynevezett „kriptovaluta fejési hurokba”.

És becslések szerint… a nyomozók nem voltak biztosak abban, hogy 200 és 2000 közötti saját bitcoinnal indult (hogy vásárolta vagy bányásztam, nem tudjuk), és nagyon-nagyon gyorsan azzá vált, várj, Doug: 50,0000 XNUMX bitcoin!

---

DOUG.  Wow!

---

KACSA.  Több mint 50,000 XNUMX bitcoin, csak úgy.

Aztán nyilvánvalóan arra gondolva, hogy valaki észreveszi, vágott-futott, miközben 50,000 XNUMX bitcoinnal előrébb járt…

…mindegyik elképesztő 12 dollárt ér, a néhány évvel ezelőtti cent töredékeihez képest. [NEvet]

Tehát 600,000 XNUMX dollárt kapott, Doug.

[DRÁMAI SZÜNET]

Kilenc évvel később…

[NEVETÉS]

…majdnem *pontosan* kilenc évvel később, amikor lerobbantották, és az otthonát körözés alapján razziázták, a zsaruk átkutattak, és egy halom takarót találtak a szekrényében, ami alatt egy pattogatott kukoricatartó volt elrejtve.

Furcsa hely a popcorn tárolására.

Amelyben egyfajta számítógépes hideg pénztárca volt.

Amiben az említett bitcoinok nagy része volt!

Abban az időben, amikor lebukták, a bitcoinok valamivel 65,535 2 dollártól északra voltak (vagy XNUMX¹⁶-1) mindegyik.

Időközben több mint ezerszeresére nőttek.

Tehát akkoriban ez volt a valaha volt legnagyobb kriptocoin bukása!

Kilenc évvel később, miután láthatóan képtelen volt megszabadulni a jogtalanul szerzett vagyonától, talán attól félt, hogy még ha megpróbálná is beledugni egy pohárba, minden ujja rá mutatna…

…van neki ez a 3 milliárd dollár értékű bitcoinja, amely kilenc éve egy pattogatott kukorica konzervdobozban hever!

---

DOUG.  Te jó ég.

---

KACSA.  Szóval, miután annyi éven át ezen a félelmetes kincsen ült, és azon töprengett, vajon elkapják-e, most azon töpreng: „Meddig kerülök börtönbe?”

És az őt terhelő vádpont maximális büntetése?

20 év, Doug.

---

DOUG.  Egy másik érdekes történet folyik most. Ha mostanában járt a Twitteren, tudni fogja, hogy sok a tevékenység. diplomatikusan elmondani…

---

KACSA.  [ALACSONY-KÖZÉPES MINŐSÉGŰ BOB DYLAN MÁSOLÁS] Nos, az idők változnak.

---

DOUG.  …beleértve egy ponton azt az ötletet, hogy 20 dollárt kell fizetni egy ellenőrzött kék csekkért, ami természetesen szinte azonnal csalásokra késztetett.

Twitter Blue Badge e-mailes csalások – Ne dőlj be nekik!

---

KACSA.  Ez csak egy emlékeztető, Doug, hogy valahányszor van valami, ami nagy érdeklődést váltott ki, a szélhámosok biztosan követni fogják.

És ennek a kiindulópontja a következő volt: „Hé, miért nem szállsz be korán? Ha már megkapta a kék jelet, mit gondol? Nem kell havi 19.99 USD-t fizetnie, ha előregisztrál. Hagyjuk, hogy megtartsa."

Tudjuk, hogy ez nem Elon Musk ötlete volt, ahogy kijelentette, de sok vállalkozás ezt csinálja, nem?

Sok cég nyújt Önnek valamilyen előnyt, ha marad a szolgáltatásnál.

Szóval nem teljesen hihetetlen.

Ahogy mondod… mit adtál?

B-mínusz, ugye?

---

DOUG.  A kezdeti e-mailt B-mínuszban írom… talán becsaphat, ha gyorsan elolvassa, de van néhány nyelvtani probléma; a dolgokat nem érzi jól.

És ha egyszer átkattint, a céloldalaknak C-mínuszokat adnék.

Ez még durvább lesz.

---

KACSA.  Ez valahol 5/10 és 6/10 között van?

---

DOUG.  Igen, mondjuk így.

És van néhány tanácsunk, hogy még ha A plusz átverésről is van szó, akkor se számítson, mert úgyis meg tudja akadályozni!

Kezdve a személyes kedvencemmel: Használjon jelszókezelőt.

A jelszókezelő sok problémát megold, ha csalásról van szó.

---

KACSA.  Igen.

A jelszókezelőnek nincs emberszerű intelligenciája, amelyet félrevezethet az a tény, hogy jó a szép kép, vagy tökéletes a logó, vagy a webes forma pontosan a megfelelő pozícióban van a képernyőn, pontosan ugyanazzal a betűtípussal , tehát felismered.

Csak annyit tud: "Soha nem hallottam erről az oldalról."

---

DOUG.  És természetesen, kapcsold be a 2FA-t, ha tudod.

Mindig adjon hozzá egy második hitelesítési tényezőt, ha lehetséges.

---

KACSA.  Persze ez nem feltétlenül véd meg önmagadtól.

Ha felkeres egy hamis webhelyet, és úgy döntött, hogy „Hé, ez pixel-tökéletes, ez biztosan az igazi”, és elhatározta, hogy bejelentkezik, és már megadta felhasználónevét és jelszavát, majd megkéri, hogy menjen végig a 2FA folyamaton…

…nagyon valószínű, hogy ezt teszi.

Azonban ez ad egy kis időt a „Stop. Gondol. Csatlakozás.” dolog, és mondd magadban: "Várj, mit keresek én itt?"

Tehát bizonyos értelemben az a kis késés, amit a 2FA bevezet, valójában nem csak nagyon csekély probléma, hanem egy módja annak, hogy ténylegesen javítsa a kiberbiztonsági munkafolyamatot… azáltal, hogy éppen annyi gyorsulási ütemet vezet be, hogy hajlamos a kiberbiztonságra. hogy kicsit komolyabban.

Szóval tényleg nem értem, mi a hátránya.

---

DOUG.  És természetesen egy másik stratégia, amelyet sok embernek nehéz betartani, de nagyon hatékony, az kerülje a bejelentkezési hivatkozásokat és a műveleti gombokat az e-mailekben.

Tehát ha kap egy e-mailt, ne csak kattintson a gombra… menjen magára a webhelyre, és elég gyorsan meg tudja állapítani, hogy az e-mail legális volt-e vagy sem.

---

KACSA.  Alapvetően, ha nem tud teljesen megbízni a kezdeti levelezésben, akkor nem hagyatkozhat a benne lévő részletekre, legyen az a link, amelyre kattintani fog, a telefonszám, amelyet hívni fog, vagy az e-mail cím. felveszi velük a kapcsolatot a , az Instagram-fiókon, amelyre DM-eket fog küldeni, bármi legyen is az.

Ne használja azt, ami az e-mailben található… találja meg a maga módját oda, és sok ilyen csalást fog rövidre zárni.

---

DOUG.  És végül, de nem utolsósorban… ennek józan észnek kell lennie, de nem: Soha ne kérdezze meg a bizonytalan üzenet küldőjét, hogy jogos-e.

Ne válaszoljon, és ne mondja azt, hogy „Hé, tényleg Twitter?”

---

KACSA.  Igen, teljesen igazad van.

Mert a korábbi tanácsom, „Ne hagyatkozzon az e-mailben található információkra”, például ne hívja fel a telefonszámát… egyesek kísértést éreznek, hogy ezt mondják: „Nos, felhívom a telefonszámot, és megnézem, valóban azok. [IRONIKUS] Mert nyilvánvalóan, ha a szakács válaszol, akkor a valódi nevüket fogják megadni.

---

DOUG.  Ahogy mindig mondjuk: Ha kétségei vannak/ne adja ki.

És ez egy jó figyelmeztető történet, ez a következő történet: amikor a biztonsági ellenőrzések, amelyek legitim biztonsági eszközök, többet árulnak el a kelleténél, akkor mi lesz?

Nyilvános URL-ellenőrző eszközök – amikor a biztonság bizonytalansághoz vezet

---

KACSA.  Ez egy jól ismert kutató, Fabian Bräunlein Németországban… korábban már bemutattuk párszor.

címmel részletes jelentéssel tért vissza urlscan.io's SOAR spot: csevegő biztonsági eszközök szivárogtatják ki a személyes adatokat.

És ebben az esetben az urlscan.io, egy ingyenesen (vagy fizetős szolgáltatásként) használható webhely, ahol megadhat egy URL-t, vagy egy domain nevet, vagy egy IP-számot, vagy bármit, és utánanézhet: „Mit tud a közösség erről?"

És felfedi a teljes URL-t, amelyről mások kérdeztek.

És ez nem csak olyan dolgok, amelyeket az emberek saját választásuk szerint másolnak és illesztenek be.

Előfordulhat például, hogy az e-mailjeik egy harmadik féltől származó szűrőeszközön mennek keresztül, amely maga kinyeri az URL-eket, és felhívja a urlscan.io, elvégzi a keresést, megkapja az eredményt, és ennek alapján dönti el, hogy levélszemetet küldjön, blokkolja-e a spameket, vagy átadja-e az üzenetet.

Ez pedig azt jelenti, hogy néha, ha az URL titkos vagy féltitkos adatokat, személyazonosításra alkalmas információkat tartalmazott, akkor mások, akik rövid időn belül a megfelelő domain névre kerestek rá, láthatják az összes keresett URL-t, beleértve a olyan dolgokat, amelyek az URL-ben lehetnek.

Tudod, mint blahblah?username=doug&passwordresetcode= egy hosszú hexadecimális karakterlánc követi, és így tovább.

És Bräunlein egy lenyűgöző listát készített azokról az URL-ekről, különösen azokról, amelyek megjelenhetnek az e-mailekben, amelyeket rendszeresen elküldenek egy harmadik félnek szűrés céljából, majd indexelve kerülnek keresésre.

Azok az e-mailek, amelyekről úgy gondolta, hogy biztosan kihasználhatók, többek között, de nem korlátozódtak a következőkre: fióklétrehozási linkek; Amazon ajándék szállítási linkek; API kulcsok; DocuSign aláírási kérelmek; dropbox fájlátvitel; csomagkövetés; jelszó visszaállítása; PayPal számlák; Google Drive dokumentummegosztás; SharePoint meghívók; és hírlevél leiratkozási linkek.

Nem mutogat oda a SharePointra, a Google Drive-ra, a PayPalra stb.

Ezek csak példák voltak azokra az URL-ekre, amelyekre talált, és amelyek potenciálisan ilyen módon kihasználhatók voltak.

---

DOUG.  A cikk végén van néhány tanácsunk, amelyek a következőkből állnak: olvassa el Bräunlein jelentését; olvas urlscan.ioblogbejegyzése; végezzen saját kódellenőrzést; ha olyan kóddal rendelkezik, amely online biztonsági kereséseket végez; megtudhatja, milyen adatvédelmi funkciók léteznek az online beküldésekhez; és ami még fontos, tanulja meg, hogyan jelentheti be a hamis adatokat egy online szolgáltatásnak, ha látja.

Észrevettem, hogy három… amolyan limerick van?

Nagyon kreatív miniversek a cikk végén…

---

KACSA.  [MOCK HORROR] Nem, ők nem limerickek! A limerickek nagyon formális ötsoros szerkezettel rendelkeznek…

---

DOUG.  [NEVETÉS] Nagyon sajnálom. Ez igaz!

---

KACSA.  …mérőre és rímre egyaránt.

Nagyon strukturált, Doug!

---

DOUG.  Nagyon sajnálom, annyira igaz. [NEvet]

---

KACSA.  Ez csak dög. [NEVETÉS]

Még egyszer: Ha kétségei vannak/ne adja ki.

És ha adatokat gyűjt: Ha nem kellene a szemetesben lennie/Dugja be egyenesen a szemetesbe.

És ha olyan kódot ír, amely nyilvános API-kat hív meg, amelyek felfedhetik az ügyféladatokat: Soha ne sírd el a felhasználókat azáltal, hogy hogyan hívod az API-t.

---

DOUG.  [NEVETÉS] Ez új számomra, és nagyon szeretem!

És végül, de nem utolsósorban az itteni listánkon, hétről hétre beszélünk erről az OpenSSL biztonsági hibáról.

A nagy kérdés most az, hogy "Honnan tudod mit kell javítani?"

Az OpenSSL biztonsági frissítés története – hogyan tudhatja meg, mit kell javítani?

---

KACSA.  Valóban, Doug, honnan tudjuk, hogy az OpenSSL melyik verziója van?

És nyilvánvalóan Linuxon csak megnyit egy parancssort, és gépel openssl version, és megmondja, hogy melyik verziója van.

De az OpenSSL egy programkönyvtár, és nincs olyan szabály, amely szerint a szoftvernek ne lehetne saját verziója.

Előfordulhat, hogy a disztribúciója az OpenSSL 3.0-t használja, de van egy alkalmazás, amely azt mondja: „Ó, nem, még nem frissítettünk az új verzióra. Inkább az OpenSSL 1.1.1-et részesítjük előnyben, mert az továbbra is támogatott, és ha még nem rendelkezik vele, hozzuk a saját verziónkat.”

És sajnos, csakúgy, mint abban a hírhedt Log4Shell-esetben, meg kellett keresnie a hármat? 12? 154? ki tudja, hány olyan hely a hálózaton, ahol esetleg van egy elavult Log4J program.

Ugyanez az OpenSSL-re is.

Elméletileg az XDR vagy az EDR eszközök meg tudják mondani, de egyesek nem támogatják ezt, és sokan elriasztják: ténylegesen futtassa a programot, hogy megtudja, melyik verzióról van szó.

Mert végül is, ha ez a hibás vagy rossz, és valóban le kell futtatnia a programot, hogy jelentse a saját verzióját…

…ez olyan, mintha a kocsit a ló elé tenné, nem?

Ezért közzétettünk egy cikket azokra a speciális esetekre, amikor valóban be akarja tölteni a DLL-t vagy a megosztott könyvtárat, és valójában a sajátját szeretné meghívni. TellMeThyVersion() szoftver kódot.

Más szóval, eléggé megbízik a programban ahhoz, hogy betöltse a memóriába, végrehajtsa azt, és lefuttassa valamelyik összetevőjét.

Megmutatjuk, hogyan kell ezt megtenni, így teljesen biztos lehet benne, hogy a hálózaton található összes távoli OpenSSL-fájl naprakész.

Mert bár ezt KRITIKUS-ról HIGH-ra csökkentették, ez még mindig egy hiba, amelyet ki kell javítani!

---

DOUG.  A hiba súlyosságával kapcsolatban egy érdekes kérdés Svet meztelen biztonsági olvasótól, aki részben ezt írja:

Hogyan lehet az, hogy egy olyan hiba, amely rendkívül összetett a kihasználás szempontjából, és csak szolgáltatásmegtagadási támadásokra használható, továbbra is MAGAS kategóriába kerül?

---

KACSA.  Igen, azt hiszem, mondott valamit a következőről: „Ó, nem hallott az OpenSL csapata a CVSS-ről?”, amely egy amerikai kormányzati szabvány, ha úgy tetszik, a hibák kockázati és összetettségi szintjének kódolására alkalmas módon. szkriptek automatikusan szűrik.

Tehát ha alacsony a CVSS pontszáma (ami a Közös biztonsági rés pontozási rendszer), miért izgatja az embereket ez?

Miért legyen MAGAS?

Így hát a válaszom ez volt: „Miért * ne lenne* MAGAS?”

Ez egy hiba a kriptográfiai motorban; összeomolhat egy olyan program, amely mondjuk frissítést próbál beszerezni… így újra és újra és újra összeomlik, ami egy kicsit több, mint egy szolgáltatásmegtagadás, mert valójában megakadályozza, hogy megfelelően végezze el a biztonságot.

Van egy biztonsági bypass elem.

És azt hiszem, a válasz másik része, amikor a sebezhetőségek kihasználásáról van szó: „Soha ne mondd, hogy soha!”

Ha van valami, például a verem puffer túlcsordulása, ahol a veremben lévő egyéb változókat manipulálhatja, esetleg memóriacímeket is beleértve, mindig fennáll annak a lehetősége, hogy valaki kitalál egy működőképes kizsákmányolást.

És az a probléma, Doug, hogy miután rájöttek, nem számít, milyen bonyolult volt kitalálni…

…ha már tudod, hogyan kell kihasználni, *bárki* megteheti, mert eladhatod neki az ehhez szükséges kódot.

Azt hiszem, tudod, mit fogok mondani: „Nem mintha erősen érzek volna.”

[NEVETÉS]

Ez ismét egyike azoknak a dolgoknak: „átkozott, ha megteszik, átkozott, ha nem”.

---

DOUG.  Nagyon jó, nagyon köszönöm, Svet, hogy megírtad ezt a megjegyzést és elküldted.

Ha van egy érdekes története, megjegyzése vagy kérdése, amelyet fel szeretne tenni, azt szívesen olvassuk a podcastban.

Írhat e-mailt a tips@sophos.com címre, kommentálhatja bármelyik cikkünket, vagy megkereshet minket a közösségi oldalon: @nakedsecurity.

Ez a mai műsorunk; köszönöm szépen, hogy meghallgattál.

Paul Ducklin számára Doug Aamoth vagyok, és emlékeztetem Önt a következő alkalomig, hogy…

---

MINDKÉT.  Maradjon biztonságban!