Teamo de esploristoj de pluraj universitatoj en Germanio evoluigis novan MITM-atakon kontraŭ HTTPS, kiu povas ĉerpi sesiajn kuketojn kaj aliajn sentemajn datumojn, kaj ankaŭ ekzekuti arbitran JavaScript-kodon en la kunteksto de alia retejo. La atako nomiĝas ALPACA kaj povas esti aplikata al TLS-serviloj, kiuj efektivigas malsamajn aplikajn tavolprotokolojn (HTTPS, SFTP, SMTP, IMAP, POP3), sed uzas oftajn TLS-atestilojn.
La esenco de la atako estas, ke se li regas retan enirejon aŭ sendratan alirpunkton, la atakanto povas redirekti retan trafikon al alia rethaveno kaj organizi la starigon de konekto kun FTP aŭ poŝtservilo kiu subtenas TLS-ĉifradon kaj uzas TLS-atestilo komuna kun la HTTP-servilo, kaj la retumilo de la uzanto supozos, ke ligo estis establita kun la petita HTTP-servilo. Ĉar la TLS-protokolo estas universala kaj ne estas ligita al aplikaĵ-nivelaj protokoloj, la establado de ĉifrita konekto por ĉiuj servoj estas identa kaj la eraro de sendado de peto al la malĝusta servo povas esti determinita nur post establado de ĉifrita sesio dum prilaborado de la. ordonoj de la sendita peto.
Sekve, se vi ekzemple redirektas uzantkonekton origine adresitan al HTTPS al poŝtservilo kiu uzas atestilon kunhavitan kun la HTTPS-servilo, la TLS-konekto estos sukcese establita, sed la poŝtservilo ne povos prilabori la transdonitan. HTTP-komandoj kaj resendos respondon kun erarkodo. Ĉi tiu respondo estos procesita de la retumilo kiel respondo de la petita retejo, transdonita ene de ĝuste establita ĉifrita komunika kanalo.
Tri atakopcioj estas proponitaj:
- "Alŝutu" por preni Kuketon kun aŭtentigaj parametroj. La metodo aplikeblas se la FTP-servilo kovrita de la TLS-atestilo permesas al vi alŝuti kaj reakiri ĝiajn datumojn. En ĉi tiu atakvariaĵo, la atakanto povas atingi retenon de partoj de la originala HTTP-peto de la uzanto, kiel ekzemple la enhavo de la Kuketo-kapo, ekzemple, se la FTP-servilo interpretas la peton kiel konservan dosieron aŭ registras envenajn petojn tute. Por sukcese ataki, la atakanto tiam bezonas iel ĉerpi la konservitan enhavon. La atako aplikeblas al Proftpd, Microsoft IIS, vsftpd, filezilla kaj serv-u.
- "Elŝutu" por organizi transretejan skribadon (XSS). La metodo implicas, ke la atakanto, kiel rezulto de iuj individuaj manipuladoj, povas meti datumojn en servon, kiu uzas komunan TLS-atestilon, kiu tiam povas esti elsendita responde al uzantpeto. La atako aplikeblas al la supre menciitaj FTP-serviloj, IMAP-serviloj kaj POP3-serviloj (kuriero, cyrus, kerio-connect kaj zimbra).
- "Reflekto" por ruli JavaScript en la kunteksto de alia retejo. La metodo baziĝas sur reveno al la kliento parto de la peto, kiu enhavas la JavaScript-kodon senditan de la atakanto. La atako estas aplikebla al la supre menciitaj FTP-serviloj, la cyrus, kerio-connect kaj zimbra IMAP-serviloj, same kiel la sendmail SMTP-servilo.
Ekzemple, kiam uzanto malfermas paĝon kontrolitan de atakanto, ĉi tiu paĝo povas iniciati peton por rimedo de retejo kie la uzanto havas aktivan konton (ekzemple, bank.com). Dum MITM-atako, ĉi tiu peto adresita al la retejo bank.com povas esti redirektita al retpoŝta servilo, kiu uzas TLS-atestilon, kiu estas dividita kun bank.com. Ĉar la poŝtservilo ne ĉesigas la sesion post la unua eraro, servokapoj kaj komandoj kiel "POST / HTTP/1.1" kaj "Gastiganto:" estos procesitaj kiel nekonataj komandoj (la poŝtservilo resendos "500 nerekonitan komandon" por ĉiu kaplinio).
La poŝtservilo ne komprenas la funkciojn de la HTTP-protokolo kaj por ĝi la servaj kaplinioj kaj la datumbloko de la POST-peto estas traktataj en la sama maniero, do en la korpo de la POST-peto vi povas specifi linion kun komando al. la poŝtservilo. Ekzemple, vi povas pasi: MAIL FROM: alert(1); al kiu la poŝtservilo resendos 501 erarmesaĝon alert(1); : misformita adreso: atentigo(1); eble ne sekvas
Ĉi tiu respondo estos ricevata de la retumilo de la uzanto, kiu ekzekutos la JavaScript-kodon en la kunteksto ne de la komence malfermita retejo de la atakanto, sed de la retejo bank.com al kiu la peto estis sendita, ĉar la respondo venis ene de ĝusta TLS-sesio. , kies atestilo konfirmis la aŭtentikecon de la respondo de bank.com.
Skanado de la tutmonda reto montris, ke ĝenerale ĉirkaŭ 1.4 milionoj da retserviloj estas trafitaj de la problemo, por kiu eblas fari atakon miksante petojn per malsamaj protokoloj. La ebleco de vera atako estis determinita por 119 mil retserviloj, por kiuj estis akompanantaj TLS-serviloj bazitaj sur aliaj aplikaj protokoloj.
Ekzemploj de ekspluatoj estis preparitaj por ftp-serviloj pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla kaj serv-u, IMAP kaj POP3-serviloj kolombejo, kuriero, interŝanĝo, cyrus, kerio-connect kaj zimbra, SMTP-serviloj postfix, exim, sendmail , mailenable, mdaemon kaj opensmtpd. Esploristoj studis la eblecon fari atakon nur en kombinaĵo kun FTP, SMTP, IMAP kaj POP3-serviloj, sed eblas, ke la problemo ankaŭ povas okazi por aliaj aplikaj protokoloj, kiuj uzas TLS.
Por bloki la atakon, oni proponas uzi la etendon ALPN (Application Layer Protocol Negotiation) por negoci TLS-sesion konsiderante la aplikan protokolon kaj la etendon SNI (Server Name Indication) por ligi al la gastiga nomo en la kazo de uzado. TLS-atestiloj kovrantaj plurajn domajnajn nomojn. Flanke de aplikaĵo, oni rekomendas limigi la limon de la nombro da eraroj dum prilaborado de komandoj, post kio la konekto finiĝas. La procezo de evoluigado de rimedoj por bloki la atakon komenciĝis en oktobro de la pasinta jaro. Similaj sekurecaj mezuroj jam estis prenitaj en Nginx 1.21.0 (poŝta prokurilo), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Iru) kaj Internet Explorer.
fonto: opennet.ru