S3 Ep95: Slack leak, atacul Github și cripto-ul post-cuantic [Audio + Text]

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.  Slack leaks, cod GitHub obraznic și criptografie post-cuantică.

Toate acestea și multe altele pe podcastul Naked Security.

[MODEM MUZICAL]

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

Eu sunt Doug Aamoth.

Cu mine, ca întotdeauna, este Paul Ducklin.

Paul, ce faci azi?

---

RAȚĂ.  Super-duper, ca de obicei, Doug!

---

DOUG.  Sunt super încântat să ajung la cea de săptămâna aceasta Istoria tehnologiei segment, deoarece...

...ai fost acolo, omule!

Săptămâna aceasta, pe 11 august...

---

RAȚĂ.  Oh nu!

Cred că banul tocmai a scăpat...

---

DOUG.  Nici nu trebuie să spun anul!

11 august 2003 – lumea a observat viermele Blaster, care a afectat sistemele Windows 2000 și Windows XP.

Blaster, cunoscut și sub numele de Lovesan și MsBlast, a exploatat o depășire a tamponului și este probabil cel mai cunoscut pentru mesaj, „Billy Gates, de ce faci asta posibil? Nu mai faceți bani și reparați-vă software-ul.”

Ce sa întâmplat, Paul?

---

RAȚĂ.  Ei bine, a fost epoca de dinainte, poate, am luat securitatea atât de în serios.

Și, din fericire, acest tip de eroare ar fi mult, mult mai dificil de exploatat în zilele noastre: a fost un buffer overflow bazat pe stivă.

Și dacă îmi amintesc bine, versiunile de server ale Windows erau deja construite cu ceea ce se numește protecția stivei.

Cu alte cuvinte, dacă depășiți stiva în interiorul unei funcții, atunci, înainte ca funcția să revină și să provoace daune cu stiva coruptă, va detecta că s-a întâmplat ceva rău.

Deci, trebuie să închidă programul ofensator, dar malware-ul nu începe să ruleze.

Dar această protecție nu era în versiunile client de Windows la acel moment.

Și, din câte îmi amintesc, a fost unul dintre acele programe malware timpurii care trebuia să ghicească ce versiune a sistemului de operare aveai.

Esti pe 2000? Esti pe NT? Esti pe XP?

Și dacă a greșit, atunci o parte importantă a sistemului s-ar prăbuși și veți primi avertismentul „Sistemul dumneavoastră este pe cale să se închidă”.

---

DOUG.  Ha, le amintesc!

---

RAȚĂ.  Deci, a existat acea daune colaterale care a fost, pentru mulți oameni, semnul că ai fost lovit de infecții...

…care ar putea fi din afară, ca și cum ai fi doar un utilizator casnic și nu ai avea un router sau un firewall acasă.

Dar dacă te aflai în interiorul unei companii, cel mai probabil atacul urma să vină de la altcineva din cadrul companiei, aruncând pachete în rețeaua ta.

Deci, foarte asemănător cu atacul CodeRed despre care am vorbit, care a avut loc cu câțiva ani înainte, într-un podcast recent, problema a fost într-adevăr dimensiunea, volumul și viteza acestui lucru.

---

DOUG.  Bine, ei bine, asta a fost acum vreo 20 de ani.

Și dacă întoarcem ceasul înapoi la acum cinci ani, atunci atunci Slack a început să curgă parole cu hashing. [RÂSETE]

---

RAȚĂ.  Da, Slack, popularul instrument de colaborare...

... are o funcție prin care puteți trimite un link de invitație altor persoane pentru a se alătura spațiului dvs. de lucru.

Și, vă imaginați: faceți clic pe un buton care spune „Generează un link”, și va crea un fel de pachet de rețea care probabil are ceva JSON în interior.

Dacă ați avut vreodată o invitație la întâlnire Zoom, veți ști că are o dată și o oră și persoana care vă invită și o adresă URL pe care o puteți utiliza pentru întâlnire, o parolă și toate astea. lucruri – are destul de multe date acolo.

În mod normal, nu cercetezi datele brute pentru a vedea ce este acolo – clientul spune doar: „Hei, iată o întâlnire, aici sunt detaliile. Doriți să Acceptați / Poate / Refuzați?”

S-a dovedit că atunci când ai făcut asta cu Slack, după cum spui, timp de mai bine de cinci ani, în acea invitație erau incluse date străine care nu sunt strict relevante pentru invitația în sine.

Deci, nu o adresă URL, nu un nume, nu o dată, nu o oră...

…dar *hash-ul parolei utilizatorului care invită* [Râsete]

---

DOUG.  Hmmmmm.

---

RAȚĂ.  Nu glumesc!

---

DOUG.  Asta suna rau...

---

RAȚĂ.  Da, chiar da, nu-i așa?

Vestea proastă este, cum naiba a ajuns asta acolo?

Și, odată ce a fost acolo, cum naiba a scăpat de observație timp de cinci ani și trei luni?

De fapt, dacă vizitați articolul despre Naked Security și vă uitați la URL completă al articolului, veți observa că la sfârșit scrie: blahblahblah-for-three-months.

Pentru că, când am citit prima dată raportul, mintea mea nu a vrut să-l vadă ca 2017! [RÂSETE]

Era între 17 aprilie și 17 iulie, așa că erau o mulțime de „17” acolo.

Și mintea mea a ștears 2017 ca an de început – l-am citit greșit ca „aprilie până în iulie *a acestui an*” [2022].

M-am gândit: „Uau, *trei luni* și nu au observat”.

Și apoi primul comentariu la articol a fost, „Ahem [TUSE]. Era de fapt 17 aprilie *2017*.”

Wow!

Dar cineva și-a dat seama pe 17 iulie [2022], iar Slack, spre meritul lor, l-a reparat în aceeași zi.

De exemplu, „Oh, la ce ne gândeam?!”

Deci asta e vestea proastă.

Vestea bună este că cel puțin au fost parole *hashed*.

Și nu au fost doar hashing, ci au fost *sărate*, care este locul în care amestecați datele aleatoare alese în mod unic pentru fiecare utilizator cu parola.

Ideea acestui lucru este dublă.

Unu, dacă doi oameni aleg aceeași parolă, nu primesc același hash, așa că nu puteți face nicio inferență uitându-vă prin baza de date hash.

Și doi, nu puteți precalcula un dicționar de hashe-uri cunoscute pentru intrări cunoscute, deoarece trebuie să creați un dicționar separat pentru fiecare parolă *pentru fiecare sare*.

Deci nu este un exercițiu banal să spargeți parolele hashing.

Acestea fiind spuse, toată ideea este că nu ar trebui să fie o chestiune publică.

Sunt tocate și sărate *în cazul în care* se scurg, nu *pentru ca* să se scurgă.

Deci, ou pe fața lui Slack!

Slack spune că aproximativ unul din 200 de utilizatori, sau 0.5%, a fost afectat.

Dar dacă ești utilizator Slack, aș presupune că, dacă nu și-au dat seama că au scurs parole hashed timp de cinci ani, poate că nici nu au enumerat complet lista persoanelor afectate.

Deci, du-te și schimbă-ți parola oricum... ai putea la fel de bine.

---

DOUG.  OK, mai spunem: dacă nu utilizați un manager de parole, luați în considerare obținerea unuia; și porniți 2FA dacă puteți.

---

RAȚĂ.  Credeam că ți-ar plăcea asta, Doug.

---

DOUG.  Da, o iau!

Și apoi, dacă sunteți Slack sau o companie ca aceasta, alegeți a algoritm reputat de salt-hash-and-stretch atunci când manipulați singur parolele.

---

RAȚĂ.  Da.

Cea mai mare problemă în răspunsul lui Slack și lucrul pe care l-am crezut că lipsește, este că ei au spus doar: „Nu vă faceți griji, nu numai că am hashat parolele, ci le-am sărat și”.

Sfatul meu este că, dacă sunteți prins într-o astfel de încălcare, atunci ar trebui să fiți dispus să declarați algoritmul sau procesul pe care l-ați folosit pentru sărare și hashing și, de asemenea, în mod ideal, ceea ce se numește întindere, care este în cazul în care nu o singură dată se hash parola sărată, ci poate o faci de 100,000 de ori pentru a încetini orice fel de atac de dicționar sau de forță brută.

Și dacă specificați ce algoritm utilizați și cu ce parametri... de exemplu, PBKDF2, bcrypt, scrypt, Argon2 – aceștia sunt cei mai cunoscuți algoritmi de parolă „salt-hash-stretch” de acolo.

Dacă spuneți de fapt ce algoritm utilizați, atunci: [A] sunteți mai deschis și [B] le oferiți potențialelor victime ale problemei șansa de a evalua singuri cât de periculos cred că ar fi fost acest lucru .

Și acest tip de deschidere poate ajuta foarte mult.

Slack nu a făcut asta.

Ei au spus doar: „Oh, au fost sărați și măcinați”.

Dar ceea ce nu știm este că au pus doi octeți de sare și apoi i-au rupt o dată cu SHA-1...

…sau aveau ceva mai rezistent la crăpare?

---

DOUG.  Rămânând la subiectul lucrurilor rele, observăm o tendință în curs de dezvoltare în care se află oamenii injectând lucruri rele în GitHub, doar pentru a vedea ce se întâmplă, expunând riscul...

… mai avem una din acele povești.

---

RAȚĂ.  Da, cineva care acum ar fi apărut pe Twitter și a spus: „Nu vă faceți griji băieți, nu s-a făcut rău. A fost doar pentru cercetare. O să scriu un raport, voi ieși din Blue Alert.”

Au creat literalmente mii de proiecte GitHub false, bazate pe copierea codului legitim existent, inserarea deliberată a unor comenzi malware acolo, cum ar fi „apelați acasă pentru instrucțiuni suplimentare” și „interpretați corpul răspunsului ca cod backdoor de executat” și curând.

Deci, lucruri care ar putea face rău dacă ați instala unul dintre aceste pachete.

Dându-le nume cu aspect legitim...

… împrumutând, aparent, istoria de comitere a unui proiect autentic, astfel încât lucrul să pară mult mai legitim decât v-ați aștepta altfel dacă ar apărea cu „Hei, descărcați acest fișier. Știi că vrei!"

Într-adevăr?! Cercetare?? Nu știam asta deja?!!?

Acum, puteți argumenta: „Ei bine, Microsoft, care deține GitHub, ce fac ei pentru a face atât de ușor pentru oameni să încarce astfel de lucruri?”

Și există ceva adevăr în asta.

Poate că ar putea face o treabă mai bună de a menține malware-ul în primul rând.

Dar este puțin exagerat să spună: „Oh, totul este vina Microsoft”.

În opinia mea, este și mai rău să spun: „Da, aceasta este o cercetare autentică; acest lucru este cu adevărat important; trebuie să le reamintim oamenilor că acest lucru s-ar putea întâmpla.”

Ei bine, [A] știm deja asta, mulțumesc foarte mult, pentru că mulți oameni au făcut asta înainte; am primit mesajul tare și clar.

Și [B] aceasta *nu este* cercetare.

Aceasta încearcă în mod deliberat să păcălească oamenii să descarce cod care oferă unui potențial atacator control de la distanță, în schimbul capacității de a scrie un raport.

Asta mi se pare mai mult o „scuză mare” decât un motiv legitim pentru cercetare.

Așadar, recomandarea mea este că, dacă crezi că aceasta *este* cercetare și dacă ești hotărât să faci ceva ca asta din nou, *nu te aștepta la multă simpatie* dacă ești prins.

---

DOUG.  Bine – vom reveni la asta și cititorul comentează la sfârșitul emisiunii, așa că rămâneți.

Dar mai întâi să vorbim despre semafor, și ce au de-a face cu securitatea cibernetică.

---

RAȚĂ.  Ahhh, da! [A RADE]

Ei bine, există un lucru numit TLP Protocolul semaforului.

Iar TLP este ceea ce ați putea numi un „protocol de cercetare în domeniul securității cibernetice umane” care vă ajută să etichetați documentele pe care le trimiteți altor persoane, pentru a le oferi un indiciu despre ceea ce sperați că vor (și, mai important, ce sperați că vor * nu*) fac cu datele.

În special, cât de larg ar trebui să-l redistribuie?

Este acesta ceva atât de important încât ai putea să-l declari lumii?

Sau este acest lucru potențial periculos, sau poate include unele lucruri pe care nu vrem să fie publice încă... așa că păstrați-le pentru tine?

Și a început cu: TLP:RED, ceea ce însemna, „Păstrează-l pentru tine”; TLP:AMBER, ceea ce însemna „Puteți să-l circulați în interiorul propriei companii sau către clienții dvs. despre care credeți că ar putea avea nevoie urgent să știe acest lucru”; TLP:GREEN, ceea ce însemna: „OK, puteți lăsa acest lucru să circule pe scară largă în comunitatea de securitate cibernetică”.

Și TLP:WHITE, ceea ce însemna: „Poți spune oricui”.

Foarte util, foarte simplu: ROȘU, CHIHHHUN, VERDE... o metaforă care funcționează la nivel global, fără să vă faceți griji despre care este diferența dintre „secret” și „confidențial” și care este diferența dintre „confidențial” și „clasificat”, toate acele lucruri complicate care are nevoie de o mulțime de legi în jurul lui.

Ei bine, TLP-ul tocmai a primit câteva modificări.

Deci, dacă vă interesează cercetarea în domeniul securității cibernetice, asigurați-vă că le cunoașteți.

TLP:WHITE a fost schimbat în ceea ce eu consider un termen mult mai bun de fapt, pentru că alb are toate aceste note culturale inutile de care ne putem lipsi în epoca modernă.

Asa de, TLP:WHITE tocmai a devenit TLP:CLEAR, care din punctul meu de vedere este un cuvânt mult mai bun, deoarece spune: „Este clar să folosești aceste date” și acea intenție este declarată, ahem, foarte clar. (Îmi pare rău, nu am putut rezista jocului de cuvinte.)

Și există un strat suplimentar (deci a stricat puțin metafora – acum este un semafor de culoare *cinci* culori!).

Există un nivel special numit TLP:AMBER+STRICT, iar asta înseamnă: „Puteți împărtăși acest lucru în cadrul companiei dvs.”.

Deci s-ar putea să fii invitat la o întâlnire, poate că lucrezi pentru o companie de securitate cibernetică și este destul de clar că va trebui să arăți asta programatorilor, poate echipei tale IT, poate oamenilor tăi de asigurare a calității, astfel încât să poți cerceta problema sau rezolvați problema.

dar TLP:AMBER+STRICT înseamnă că, deși îl puteți circula în interiorul organizației dvs., *vă rugăm să nu le spuneți clienților dvs. sau clienților dvs.*, sau chiar persoanelor din afara companiei despre care credeți că ar putea avea nevoie să le cunoască.

Păstrați-l în cadrul comunității mai strânse pentru început.

TLP:AMBER, ca și înainte, înseamnă „OK, dacă simți că trebuie să le spui clienților tăi, poți.”

Și asta poate fi important, pentru că uneori s-ar putea să doriți să vă informați clienții: „Hei, avem remedierea. Va trebui să luați câțiva pași de precauție înainte de sosirea remedierii. Dar pentru că este un fel de sensibil, putem să vă cerem să nu spuneți lumii încă?”

Uneori, a spune lumii prea devreme joacă de fapt în mâinile escrocilor mai mult decât în ​​mâinile apărătorilor.

Deci, dacă sunteți un răspuns de securitate cibernetică, vă sugerez să mergeți: https://www.first.org/tlp

---

DOUG.  Si tu poti citiți mai multe despre asta pe site-ul nostru, nakedsecurity.sophos.com.

Și dacă sunteți în căutarea pentru o altă lectură ușoară, uitați de criptografia cuantică... trecem la criptografia post-cuantică, Paul!

---

RAȚĂ.  Da, am mai vorbit despre asta de câteva ori pe podcast, nu-i așa?

Ideea unui computer cuantic, presupunând că s-ar putea construi unul suficient de puternic și de fiabil, este că anumite tipuri de algoritmi ar putea fi accelerate peste stadiul actual al tehnicii, fie pe tonul rădăcinii pătrate... sau chiar mai rău, *logaritmul* al amplorii problemei de astăzi.

Cu alte cuvinte, în loc să luați 2²⁵⁶ încearcă să găsească un fișier cu un anumit hash, ați putea să o faceți doar („doar”!) 2¹²⁸ încearcă, care este rădăcina pătrată.

În mod clar, mult mai rapid.

Dar există o întreagă clasă de probleme care implică factorizarea produselor numerelor prime despre care teoria spune că ar putea fi sparte în *logaritmul* timpului pe care îl iau astăzi, vorbind în mod liber.

Deci, în loc să luăm, să zicem, 2¹²⁸ zile pentru a se sparge [MULT MAI MULT DECÂT VÂSTA ACTUALĂ A UNIVERSULUI], ar putea dura doar 128 de zile pentru a se sparge.

Sau puteți înlocui „zile” cu „minute” sau orice altceva.

Și, din păcate, acel algoritm de timp logaritmic (numit Algoritmul de factorizare cuantică a lui Shor)… care ar putea fi, teoretic, aplicat unora dintre tehnicile criptografice actuale, în special celor utilizate pentru criptografia cu cheie publică.

Și, în cazul în care aceste dispozitive de calcul cuantic devin fezabile în următorii câțiva ani, poate ar trebui să începem să ne pregătim acum pentru algoritmi de criptare care nu sunt vulnerabili la aceste două clase particulare de atacuri?

În special cea logaritmică, pentru că accelerează atât de mult atacurile potențiale, încât cheile criptografice pe care le credem în prezent „Ei bine, nimeni nu își va da seama vreodată asta”, ar putea deveni dezvăluite într-o etapă ulterioară.

Oricum, NIST, Institutul Național de Standarde și Tehnologie în SUA, organizează de câțiva ani un concurs pentru a încerca să standardizeze niște algoritmi publici, nebrevetați, bine analizați, care vor fi rezistenți la aceste computere cuantice magice, dacă vor apărea vreodată.

Și recent au ales patru algoritmi pe care sunt pregătiți să-i standardizeze acum.

Au nume grozave, Doug, așa că trebuie să le citesc: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, și SPHINCS+. [RÂSETE]

Deci au nume grozave, dacă nu altceva.

Dar, în același timp, NIST și-a dat seama: „Ei bine, sunt doar patru algoritmi. Ceea ce vom face este să alegem încă patru ca potențiali candidați secundari și vom vedea dacă ar trebui să treacă și vreunul dintre aceștia.”

Deci, există patru algoritmi standardizați acum și patru algoritmi care ar putea fi standardizați în viitor.

Sau *au fost* patru pe 5 iulie 2022, iar unul dintre ei a fost SIKE, scurt pentru încapsularea cheii de izogenie supersingulară.

(Vom avea nevoie de mai multe podcasturi pentru a explica izogeniile supersingulare, așa că nu ne vom deranja. [Râsete])

Dar, din păcate, acesta, care stătea acolo cu o șansă de luptă de a fi standardizat, pare că a fost rupt iremediabil, în ciuda faptului că a fost deja deschis la controlul public de cel puțin cinci ani.

Așa că, din fericire, chiar înainte de a fi sau ar putea fi standardizat, doi criptografi belgieni și-au dat seama: „Știi ce? Credem că am reușit să ocolim acest lucru folosind calcule care durează aproximativ o oră, pe un procesor destul de mediu, folosind doar un nucleu.”

---

DOUG.  Bănuiesc că este mai bine să afli asta acum decât după ce l-ai standardizat și l-a scos în sălbăticie?

---

RAȚĂ.  Intr-adevar!

Bănuiesc că dacă ar fi fost unul dintre algoritmii care au fost deja standardizați, ar trebui să abroge standardul și să vină cu unul nou?

Pare ciudat că acest lucru nu a fost observat timp de cinci ani.

Dar cred că aceasta este întreaga idee a controlului public: nu știi niciodată când cineva s-ar putea lovit de fisura necesară sau de mica pană pe care o pot folosi pentru a pătrunde și a dovedi că algoritmul nu este atât de puternic pe cât se credea inițial.

O reamintire bună că, dacă te-ai gândit * vreodată* să-ți tricotezi propria criptografie...

---

DOUG.  [Râde] Nu am făcut-o!

---

RAȚĂ.  ..în ciuda faptului că v-am spus pe podcastul Naked Security de N ori, „Nu face asta!”

Acesta ar trebui să fie ultimul memento că, chiar și atunci când experții adevărați scot un algoritm care este supus controlului public într-o competiție globală timp de cinci ani, acest lucru nu oferă neapărat suficient timp pentru a expune defectele care se dovedesc a fi destul de rele.

Deci, cu siguranță nu arată bine pentru asta SIKE algoritm.

Și cine știe, poate va fi retras?

---

DOUG.  Vom fi cu ochii pe asta.

Și pe măsură ce soarele apune încet în emisiunea noastră pentru această săptămână, este timpul să auzim de la unul dintre cititorii noștri despre povestea GitHub despre care am discutat mai devreme.

Jefui scrie:

„Există niște cretă și brânză în comentarii și urăsc să spun asta, dar pot vedea cu adevărat ambele părți ale argumentului. Este periculos, supărător, pierdere de timp și consumator de resurse? Da, desigur că este. Este ceea ce ar face tipurile criminale? Da da este. Este un memento pentru oricine care folosește GitHub sau, de altfel, orice alt sistem de depozit de coduri, că călătoria în siguranță pe internet necesită un grad sănătos de cinism și paranoia? Da. Ca administrator de sistem, o parte din mine vrea să aplaude expunerea riscului la îndemână. În calitate de administrator de sistem pentru o grămadă de dezvoltatori, acum trebuie să mă asigur că toată lumea a căutat recent orice atracție pentru intrări îndoielnice.”

---

RAȚĂ.  Da, mulțumesc, RobB, pentru acest comentariu, pentru că cred că este important să vedem ambele părți ale argumentului.

Au fost comentatori care doar spuneau: „Care naiba este problema cu asta? Asta e super!"

O persoană a spus, „Nu, de fapt, acest test de stilou este bun și util. Bucură-te că aceștia sunt expuși acum, în loc să-și ridice capul urât de la un atacator real.”

Și răspunsul meu la asta este: „Ei bine, acesta *este* un atac, de fapt”.

Doar că cineva a ieșit acum afară, spunând „Oh, nu, nu. Nici un rău făcut! Sincer, nu am fost obraznic.”

Nu cred că ești obligat să cumperi acea scuză!

Dar oricum, acesta nu este un test de penetrare.

Răspunsul meu a fost să spun, foarte simplu: „Testererii responsabili de penetrare acționează întotdeauna [A] după ce au primit permisiunea explicită și [B] în limitele comportamentale convenite în mod explicit în prealabil.”

Nu vă creați doar propriile reguli și am discutat despre asta înainte.

Deci, așa cum a spus un alt comentator, care este, cred, comentariul meu preferat... spuse Ecurb, „Cred că cineva ar trebui să meargă din casă în casă și să spargă ferestrele pentru a arăta cât de ineficiente sunt cu adevărat încuietorile ușilor. Acest lucru este întârziat. Să sară cineva pe asta, te rog.”

Și apoi, în caz că nu v-ați dat seama că e satira, oameni buni, spune el, "Nu!"

---

RAȚĂ.  Îmi dau ideea că este un memento bun și îmi dau ideea că dacă ești utilizator GitHub, atât ca producător, cât și ca consumator, există lucruri pe care le poți face.

Le enumerăm în comentarii și în articol.

De exemplu, puneți o semnătură digitală pe toate comenzile dvs., astfel încât să fie evident că modificările au venit de la dvs. și există un fel de trasabilitate.

Și nu consumați doar orbește lucruri pentru că ați făcut o căutare și „s-a părut” că ar putea fi proiectul potrivit.

Da, cu toții putem învăța din asta, dar asta contează de fapt ca ne învață sau este doar ceva ce ar trebui să învățăm oricum?

Cred că asta *nu* predă.

Pur și simplu *nu are un standard suficient de înalt* pentru a fi considerat cercetare.

---

DOUG.  Discuție grozavă în jurul acestui articol și mulțumesc că l-ai trimis, Rob.

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 tips@sophos.com; puteți comenta oricare dintre articolele noastre; sau ne poți contacta pe social: @NakedSecurity.

Acesta este emisiunea noastră de astăzi – mulțumesc foarte mult pentru ascultare.

Pentru Paul Ducklin, sunt Doug Aamoth care vă reamintește, până data viitoare, să...

---

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

[MODEM MUZICAL]