S3 Ep108: Ai ascuns TREI MILIARDE de dolari într-o cutie de floricele?

Faceți clic și trageți pe undele sonore de mai jos pentru a trece la orice punct. Poti de asemenea asculta direct pe Soundcloud.

DOUG.  Escrocherii pe Twitter, Patch Tuesday și criminali care atacă criminali.

Toate acestea și multe altele pe podcastul Naked Security.

[MODEM MUZICAL]

Bine ați venit la podcast, toată lumea.

Eu sunt Doug.

El este Paul Ducklin.

Paul, ce faci azi?

---

RAȚĂ.  Foarte bine, Doug.

Nu am avut eclipsa de Lună aici, în Anglia, dar am văzut pe scurt luna plină *plină* printr-un mic gol din nori care a apărut ca singura gaură din întregul strat de nori în momentul în care am ieșit afară. uită-te!

Dar nu am avut acea lună portocalie ca voi băieți în Massachusetts.

---

DOUG.  Să începem spectacolul cu Săptămâna aceasta în istoria tehnologiei… asta merge cu mult înapoi.

Săptămâna aceasta, pe 08 noiembrie 1895, profesorul german de fizică Wilhelm Röntgen a dat peste o formă încă nedescoperită de radiație care l-a determinat să se refere la radiația menționată pur și simplu ca „X”.

Ca și în radiografie.

Ce zici de asta... descoperirea accidentală a razelor X?

---

RAȚĂ.  Destul de uimitor.

Îmi amintesc că mama îmi spunea: în anii 1950 (trebuie să fi fost la fel în State), se pare, în magazinele de încălțăminte...

---

DOUG.  [ȘTIE CE URMĂ] Da! [râde]

---

RAȚĂ.  Oamenii își duceau copiii în... tu stai în această mașină, încalțai pantofii și în loc să spui doar: „Umblă-te, sunt strânși? Se ciupesc?”, ai stat într-un aparat cu raze X, care practic te-a scăldat în radiații cu raze X și a făcut o fotografie live și a spus: „Oh, da, au dimensiunea potrivită”.

---

DOUG.  Da, vremuri mai simple. Puțin periculos, dar...

---

RAȚĂ.  PUȚIN PERICULOS?

Vă puteți imagina oamenii care lucrau în magazinele de încălțăminte?

Trebuie să fi făcut baie în raze X tot timpul.

---

DOUG.  Absolut... ei bine, astăzi suntem puțin mai în siguranță.

Și în ceea ce privește siguranța, prima zi de marți a lunii este Patch Tuesday de la Microsoft.

So ce am invatat acest Patch Marți aici în noiembrie 2022?

Schimb 0-zile fix (în sfârșit) – plus 4 patch-uri nou-nouțe de marți 0-zile!

---

RAȚĂ.  Ei bine, lucrul super-incitant, Doug, este că, din punct de vedere tehnic, Patch Tuesday a remediat nu una, nu două, nu trei... ci *patru* zile zero.

Dar, de fapt, patch-urile pe care le-ați putea obține pentru produsele Microsoft marți au fixat *șase* zero-zile.

Amintiți-vă acele zile zero de schimb care, în mod notoriu, nu au fost corectate în ultimul patch de marți: CVE-2002-41040 și CVE-2022-41082, ceea ce a devenit cunoscut sub numele de ProxyNotShell?

S3 Ep102.5: „ProxyNotShell” Schimb de erori – un expert vorbește [Audio + Text]

Ei bine, acestea au fost remediate, dar, în esență, într-o „linie secundară” separată pentru Patch Tuesday: Exchange November 2022 SU, sau Software Update, care spune doar:

Actualizările software Exchange din noiembrie 2022 conțin remedieri pentru vulnerabilitățile zero-day raportate public la 29 septembrie 2022.

Tot ce trebuie să faceți este să faceți upgrade la Exchange.

Vai, mulțumesc Microsoft... Cred că știam că asta va trebui să facem când patch-urile vor apărea în sfârșit!

Așadar, acestea *sunt* scoase și există două zile zero remediate, dar nu sunt noi și, din punct de vedere tehnic, nu sunt în partea „Patch Tuesday”.

Acolo, avem alte patru zile zero fix.

Și dacă credeți în prioritizarea patch-urilor, atunci evident că aceștia sunt cei cu care doriți să vă ocupați mai întâi, pentru că cineva știe deja să facă lucruri rele cu ele.

Acestea variază de la o ocolire de securitate, la două niveluri de privilegii și o execuție de cod la distanță.

Dar sunt mai mult de 60 de plasturi în total, iar dacă te uiți la lista generală de produse și componente Windows afectate, există o listă enormă, ca de obicei, care include fiecare componentă/produs Windows despre care ai auzit și multe pe care probabil că nu le-ai făcut.

Microsoft corectează 62 de vulnerabilități, inclusiv Kerberos și Mark of the Web și Exchange... un fel

Deci, ca întotdeauna: Nu întârzia/Fă-o astăzi, Douglas!

---

DOUG.  Foarte bine.

Haideți să vorbim acum despre o întârziere destul de mare...

Ai o poveste foarte interesantă despre Piața de droguri din Drumul Mătăsii, și o reamintire că criminalii care fură de la criminali sunt încă o crimă, chiar dacă peste vreo zece ani ești prins pentru asta.

Un hacker de pe piața de droguri din Silk Road pledează vinovat, riscă 20 de ani în interior

---

RAȚĂ.  Da, chiar și oamenii care sunt destul de noi în domeniul securității cibernetice sau în ceea ce privește accesul online probabil că au auzit de „Drumul Mătăsii”, poate prima piață de web întunecată bine-cunoscută, larg răspândită și utilizată pe scară largă, unde practic orice poate merge.

Deci, totul a luat foc în 2013.

Pentru că fondatorul, cunoscut inițial doar ca Tericul pirat Roberts, dar în cele din urmă s-a dezvăluit a fi Ross Ulbricht… securitatea sa operațională slabă a fost suficientă pentru a lega activitățile de el.

Fondatorul Silk Road, Ross Ulbricht, primește viața fără eliberare condiționată

Nu numai că securitatea lui operațională nu era foarte bună, dar se pare că la sfârșitul anului 2012 au avut (îți vine să crezi, Doug?) o gafă de procesare a plăților în criptomonede...

---

DOUG.  [Gasps IN MOCK HORROR]

---

RAȚĂ.  …de tipul pe care l-am văzut repetat de multe ori de atunci, care nu a făcut o contabilitate corectă în partidă dublă, unde pentru fiecare debit, există un credit corespunzător și invers.

Și acest atacator a descoperit, dacă puneți niște bani în contul dvs. și apoi îi plătiți foarte repede în alte conturi, că puteți plăti de cinci ori (sau chiar mai mult) aceleași bitcoini înainte ca sistemul să-și dea seama că primul debit a dispărut. prin.

Deci ai putea pune niște bani și apoi să-i retragi din nou și din nou și din nou și să obții o rezervă mai mare...

… și apoi ai putea să te întorci în ceea ce ai putea numi o „buclă de muls criptomonede”.

Și se estimează... anchetatorii nu erau siguri că a început cu între 200 și 2000 de bitcoini ai lui (dacă i-a cumpărat sau i-a minat, nu știm), și i-a transformat foarte, foarte repede în, așteaptă, Doug: 50,0000 de bitcoini!

---

DOUG.  Wow!

---

RAȚĂ.  Peste 50,000 de bitcoini, chiar așa.

Și apoi, închipuindu-și în mod evident că cineva va observa, a tăiat și a fugit în timp ce era înainte cu 50,000 de bitcoini...

… fiecare valorând 12 USD uimitor, mai mult decât fracțiunile de cent cu doar câțiva ani înainte. [râde]

Așa că a scăpat cu 600,000 de dolari, exact așa, Doug.

[PAUZĂ DRAMATICĂ]

Nouă ani mai târziu…

[RÂSETE]

…aproape *exact* nouă ani mai târziu, când a fost arestat și casa lui a fost percheziționată în temeiul unui mandat, polițiștii au mers să caute și au găsit o grămadă de pături în dulapul lui, sub care era ascunsă o cutie de floricele de porumb.

Un loc ciudat pentru a-ți păstra floricelele.

Înăuntrul căruia era un fel de portofel rece computerizat.

În interiorul căruia se afla o mare parte din bitcoinii menționati!

În momentul în care a fost blocat, bitcoinii erau ceva mai puțin de 65,535 USD (sau 2¹⁶-1) fiecare.

Au crescut de peste o mie de ori între timp.

Deci, la acea vreme, a fost cea mai mare criză de criptomonede vreodată!

Nouă ani mai târziu, după ce se pare că nu a reușit să scape de câștigurile lui rău obținute, poate de teamă că, chiar dacă ar încerca să le împingă într-un pahar, toate degetele ar arăta înapoi spre el...

…a avut toate aceste bitcoini în valoare de 3 miliarde de dolari care au stat într-o cutie de floricele de porumb de nouă ani!

---

DOUG.  Dumnezeule.

---

RAȚĂ.  Așa că, după ce a stat pe această comoară înfricoșătoare în toți acești ani, întrebându-se dacă va fi prins, acum s-a întrebat: „Pentru cât timp voi merge la închisoare?”

Și pedeapsa maximă pentru acuzația cu care se confruntă?

20 de ani, Doug.

---

DOUG.  O altă poveste interesantă se petrece chiar acum. Dacă ai fost pe Twitter în ultima vreme, vei ști că există multă activitate. sa spun diplomatic...

---

RAȚĂ.  [IMPERSONARE BOB DYLAN DE CALITATE JOSĂ LA MEDIE] Ei bine, vremurile se schimbă.

---

DOUG.  … inclusiv la un moment dat ideea de a percepe 20 USD pentru un cec albastru verificat, care, desigur, aproape imediat a provocat unele escrocherii.

Escrocherii prin e-mailuri Twitter Blue Badge – Nu vă îndrăgostiți de ele!

---

RAȚĂ.  Este doar o reamintire, Doug, că ori de câte ori există ceva care a atras mult interes, escrocii vor urma cu siguranță.

Și premisa a fost: „Hei, de ce să nu intri devreme? Dacă ai deja un semn albastru, ghici ce? Nu va trebui să plătiți 19.99 USD pe lună dacă vă preînregistrați. Vă lăsăm să-l păstrați.”

Știm că nu asta a fost ideea lui Elon Musk, așa cum a afirmat el, dar este genul de lucru pe care îl fac multe companii, nu-i așa?

Multe companii vă vor oferi un fel de beneficii dacă rămâneți cu serviciul.

Deci nu este complet incredibil.

Cum spui... ce i-ai dat?

B-minus, nu-i așa?

---

DOUG.  Dau e-mailului inițial un B-minus... ați putea fi păcălit dacă îl citiți repede, dar există câteva probleme de gramatică; lucrurile nu se simt bine.

Și apoi, odată ce faci clic, aș da paginilor de destinație C-minus.

Asta devine și mai dificil.

---

RAȚĂ.  Este undeva între 5/10 și 6/10?

---

DOUG.  Da, să spunem asta.

Și avem câteva sfaturi, astfel încât, chiar dacă este o înșelătorie A-plus, nu va conta pentru că oricum vei putea să o contrazici!

Începând cu preferatul meu personal: Utilizați un manager de parole.

Un manager de parole rezolvă o mulțime de probleme când vine vorba de escrocherii.

---

RAȚĂ.  O face.

Un manager de parole nu are nicio inteligență umană care să poată fi indusă în eroare de faptul că imaginea frumoasă este corectă, sau logo-ul este perfect, sau formularul web este exact în poziția corectă pe ecran, cu exact același font , așa că o recunoști.

Tot ce știe este: „N-am auzit niciodată de acest site până acum”.

---

DOUG.  Și, desigur, activați 2FA dacă puteți.

Adăugați întotdeauna un al doilea factor de autentificare, dacă este posibil.

---

RAȚĂ.  Desigur, asta nu te protejează neapărat de tine însuți.

Dacă intri pe un site fals și te-ai hotărât: „Hei, este perfect pentru pixeli, trebuie să fie adevărata afacere”, și ești hotărât să te autentifici și ai introdus deja numele de utilizator și parola, și apoi îți cere să treci prin procesul 2FA...

…e foarte probabil să faci asta.

Cu toate acestea, vă oferă puțin timp pentru a face „Stop. Gândi. Conectați." lucru și spuneți-vă: „Așteaptă, ce caut eu aici?”

Deci, într-un fel, puțină întârziere pe care o introduce 2FA poate fi, de fapt, nu numai foarte puțină bătaie de cap, ci și o modalitate de a vă îmbunătăți efectiv fluxul de lucru în domeniul securității cibernetice... prin introducerea unei scăderi de viteză suficientă pe care sunteți înclinat să acceptați securitatea cibernetică. un pic mai serios.

Deci nu văd care este dezavantajul, cu adevărat.

---

DOUG.  Și, desigur, o altă strategie care este greu de respectat pentru mulți oameni, dar care este foarte eficientă, este să evitați linkurile de conectare și butoanele de acțiune din e-mail.

Deci, dacă primiți un e-mail, nu faceți doar clic pe butonul... accesați site-ul în sine și veți putea spune destul de repede dacă acel e-mail a fost legitim sau nu.

---

RAȚĂ.  Practic, dacă nu poți avea încredere totală în corespondența inițială, atunci nu te poți baza pe niciun detaliu din ea, indiferent dacă acesta este linkul pe care vei face clic, numărul de telefon pe care îl vei apela, adresa de e-mail pe care o vei apela. Îi vei contacta pe , contul de Instagram la care vei trimite DM-uri, oricare ar fi acesta.

Nu folosi ceea ce este în e-mail... găsește-ți propriul drum acolo și vei scurtcircuita o mulțime de escrocherii de acest fel.

---

DOUG.  Și, în sfârșit, nu în ultimul rând... acesta ar trebui să fie de bun simț, dar nu este: Nu întrebați niciodată expeditorul unui mesaj incert dacă este legitim.

Nu răspunde și spune: „Hei, ești cu adevărat Twitter?”

---

RAȚĂ.  Da, ai dreptate.

Deoarece sfatul meu anterior, „Nu vă bazați pe informațiile din e-mail”, cum ar fi să nu le sunați numărul de telefon... unii oameni sunt tentați să spună: „Ei bine, voi suna numărul de telefon și voi vedea dacă este într-adevăr sunt ei. [IRONIC] Pentru că, evident, dacă bucătarul răspunde, își vor da numele adevărat.”

---

DOUG.  După cum spunem întotdeauna: Dacă aveți îndoieli/Nu o dați.

Și aceasta este o poveste bună de avertizare, următoarea poveste: când scanările de securitate, care sunt instrumente de securitate legitime, dezvăluie mai mult decât ar trebui, ce se întâmplă atunci?

Instrumente publice de scanare a adreselor URL – atunci când securitatea duce la insecuritate

---

RAȚĂ.  Acesta este un cercetător binecunoscut pe nume Fabian Bräunlein din Germania... l-am prezentat de câteva ori înainte.

S-a întors cu un raport detaliat intitulat urlscan.ioLocul SOAR al lui: instrumente de securitate vorbăreț care scurg date private.

Și în acest caz, este urlscan.io, un site web pe care îl puteți folosi gratuit (sau ca serviciu cu plată) unde puteți trimite o adresă URL, sau un nume de domeniu, sau un număr IP, sau orice ar fi acesta, și puteți căuta „Ce știe comunitatea despre asta?"

Și va dezvălui adresa URL completă despre care au întrebat alți oameni.

Și acestea nu sunt doar lucruri pe care oamenii le copiază și le lipesc la alegere.

Uneori, e-mailul lor, de exemplu, poate trece printr-un instrument de filtrare terță parte care extrage el însuși adresele URL, sună acasă la urlscan.io, face căutarea, obține rezultatul și îl folosește pentru a decide dacă trimite mesajul nedorit, blochează spam-ul sau trimite mesajul.

Și asta înseamnă că uneori, dacă adresa URL include date secrete sau semi-secrete, informații de identificare personală, atunci alte persoane care tocmai au căutat numele de domeniu potrivit într-o perioadă scurtă de timp după aceea ar vedea toate adresele URL care au fost căutate, inclusiv lucruri care pot fi în URL.

Știi, ca blahblah?username=doug&passwordresetcode= urmat de un șir lung de caractere hexazecimale și așa mai departe.

Și Bräunlein a venit cu o listă fascinantă de tipuri de adrese URL, în special cele care pot apărea în e-mailuri, care pot fi trimise în mod obișnuit către o terță parte pentru filtrare și apoi indexate pentru căutare.

Tipul de e-mailuri despre care a crezut că sunt cu siguranță exploatabile includeau, dar nu se limitau la: link-uri pentru crearea contului; Link-uri de livrare a cadourilor Amazon; chei API; Cereri de semnare DocuSign; transferuri de fișiere dropbox; urmarirea pachetului; resetarea parolei; facturi PayPal; Partajarea documentelor Google Drive; Invitații SharePoint; și link-uri de dezabonare la newsletter.

Nu arătând cu degetul acolo spre SharePoint, Google Drive, PayPal etc.

Acestea au fost doar exemple de adrese URL pe care le-a întâlnit și care pot fi exploatate în acest fel.

---

DOUG.  Avem câteva sfaturi la sfârșitul acelui articol, care se rezumă la: citiți raportul lui Bräunlein; citit urlscan.iopostarea lui pe blog; faceți o revizuire a codului dvs.; dacă aveți cod care face căutări de securitate online; aflați ce caracteristici de confidențialitate există pentru trimiterile online; și, important, învață cum să raportezi date necinstite unui serviciu online dacă le vezi.

Am observat că sunt trei... un fel de limericks?

Mini-poezii foarte creative la sfârșitul acestui articol...

---

RAȚĂ.  [MOCK HORROR] Nu, nu sunt limerici! Limericks au o structură foarte formală de cinci linii...

---

DOUG.  [Râde] Îmi pare atât de rău. Este adevărat!

---

RAȚĂ.  … atât pentru metru cât și pentru rimă.

Foarte structurat, Doug!

---

DOUG.  Îmi pare atât de rău, atât de adevărat. [râde]

---

RAȚĂ.  Acesta este doar un doggerel. [RÂSETE]

Din nou: Dacă aveți îndoieli/Nu o dați.

Și dacă colectați date: Dacă nu ar trebui să fie în/Bagă-l drept în coș.

Și dacă scrieți cod care apelează API-uri publice care ar putea dezvălui datele clienților: Nu vă faceți niciodată să plângă utilizatorii/După cum apelați API-ul.

---

DOUG.  [RÂDE] Este unul nou pentru mine și îmi place foarte mult!

Și nu în ultimul rând, dar cu siguranță nu în ultimul rând, pe lista noastră de aici, am vorbit săptămână de săptămână despre această eroare de securitate OpenSSL.

Marea întrebare acum este „Cum poți să spui ce trebuie reparat?”

Povestea actualizării de securitate OpenSSL – cum puteți spune ce trebuie reparat?

---

RAȚĂ.  Într-adevăr, Doug, de unde știm ce versiune de OpenSSL avem?

Și, evident, pe Linux, deschideți un prompt de comandă și introduceți openssl version, și vă spune versiunea pe care o aveți.

Dar OpenSSL este o bibliotecă de programare și nu există nicio regulă care să spună că software-ul nu poate avea propria sa versiune.

Distribuția dvs. poate folosi OpenSSL 3.0 și, totuși, există o aplicație care spune: „Oh, nu, nu am făcut upgrade la noua versiune. Preferăm OpenSSL 1.1.1, pentru că acesta este încă acceptat, iar în cazul în care nu îl aveți, aducem propria noastră versiune.”

Și așa, din păcate, la fel ca în acel infam caz Log4Shell, a trebuit să le cauți pe cei trei? 12? 154? cine-știe-căte-locuri din rețeaua dvs. unde este posibil să aveți un program Log4J învechit.

Același lucru pentru OpenSSL.

În teorie, instrumentele XDR sau EDR s-ar putea să vă spună, dar unele nu vor accepta acest lucru și mulți îl vor descuraja: rulați de fapt programul pentru a afla ce versiune este.

Pentru că, la urma urmei, dacă este un bug sau unul greșit și, de fapt, trebuie să rulați programul pentru a-l face să raporteze propria sa versiune...

… asta e ca și cum ai pune căruța înaintea calului, nu-i așa?

Așa că am publicat un articol pentru acele cazuri speciale în care doriți de fapt să încărcați DLL-ul sau biblioteca partajată și doriți să o apelați pe propria sa TellMeThyVersion() codul software.

Cu alte cuvinte, aveți suficientă încredere în program încât să îl încărcați în memorie, să îl executați și să rulați o componentă a acestuia.

Vă arătăm cum să faceți acest lucru, astfel încât să vă asigurați că toate fișierele OpenSSL periferice pe care le aveți în rețea sunt actualizate.

Pentru că, deși a fost retrogradat de la CRITICAL la HIGH, este totuși o eroare pe care trebuie și pe care doriți să-l remediați!

---

DOUG.  În ceea ce privește gravitatea acestui bug, am primit un intrebare interesanta de la cititorul de securitate Naked Svet, care scrie, parțial:

Cum se face că un bug care este enorm de complex pentru exploatare și poate fi folosit doar pentru atacuri de tip denial of service, continuă să fie clasificat ca HIGH?

---

RAȚĂ.  Da, cred că a spus ceva despre „Oh, nu a auzit echipa OpenSL de CVSS?”, care este un standard guvernamental american, dacă doriți, pentru codificarea riscului și a nivelului de complexitate al erorilor într-un mod care poate fi filtrată automat după scripturi.

Deci, dacă are un scor CVSS scăzut (care este Sistem comun de notare a vulnerabilităților), de ce oamenii sunt entuziasmați de asta?

De ce ar trebui să fie HIGH?

Și astfel răspunsul meu a fost: „De ce *n-ar** să fie ÎNALT?”

Este o eroare într-un motor criptografic; ar putea bloca un program, să zicem, care încearcă să obțină o actualizare... așa că se va bloca din nou și din nou și din nou, ceea ce este puțin mai mult decât o simplă refuzare a serviciului, deoarece de fapt vă împiedică să vă faceți securitatea corect.

Există un element de bypass de securitate.

Și cred că cealaltă parte a răspunsului este, când vine vorba de vulnerabilitățile transformate în exploit: „Nu spune niciodată niciodată!”

Când aveți ceva de genul unui buffer overflow de stivă, unde puteți manipula alte variabile de pe stivă, inclusiv adrese de memorie, va exista întotdeauna șansa ca cineva să descopere un exploit funcțional.

Și problema, Doug, este că odată ce și-au dat seama, nu contează cât de complicat a fost să-și dea seama...

…odată ce știi cum să-l exploatezi, *oricine* o poate face, pentru că le poți vinde codul pentru a face acest lucru.

Cred că știi ce am de gând să spun: „Nu că aș fi foarte puternic pentru asta.”

[RÂSETE]

Este, din nou, unul dintre acele lucruri „la naiba dacă o fac, la naiba dacă nu o fac”.

---

DOUG.  Foarte bine, mulțumesc foarte mult, Svet, pentru că ai scris acest comentariu și l-ai trimis.

Dacă aveți o poveste, un comentariu sau o întrebare interesantă pe care doriți să o trimiteți, ne-ar plăcea să o citim pe podcast.

Puteți trimite un e-mail la tips@sophos.com, puteți comenta oricare dintre articolele noastre sau ne puteți contacta pe social: @nakedsecurity.

Acesta este spectacolul nostru de astăzi; multumesc mult pentru ascultare.

Pentru Paul Ducklin, sunt Doug Aamoth și vă reamintesc până data viitoare să...

---

AMBII.  Rămâi în siguranță!