Bankattacker - Finlandssvenskt fiberforum (1)
Bredbandsgruppen  
Forum RSS feed    Forum - Svara - Statistik - Registrering - Sök -

Finlandssvenskt fiberforum / Säkerhet på nätet / Bankattacker
. 1 . 2 . 3 . >>
Författare Meddelande
Nisse
Medlem
# Skrivet: 6 Jan 2015 13:45
Svara 


Nå, Guje, vad säjer du om senaste bankattackerna ? Fast du har ju redan för länge sedan sagt en hel del ...

Tyvärr tycks både banker och politiker vara fullständigt bortkomna ifråga om nätets säkerhet. Allt tyder på att först en riktigt stor smhällelig katastrof får dem att vakna till. Och troligen springa runt som huvudlösa höns ...

Polisen skall utreda ... Ha-ha-ha, de vet inget, kan inget och får heller inga resurser av politikerna.

Upplagt för riktigt mycket elände i framtiden.

UlfG
Medlem
# Skrivet: 7 Jan 2015 12:18
Svara 


Bankerna kör väl trådlöst...eller...

Guje
Medlem
# Skrivet: 11 Jan 2015 01:57 - Editerad av: Guje
Svara 


Månne inte allt är sagt redan vad som skall sägas? Bara att luta sig bakåt i TV stolen och följa med underhållningen.

För 10 år sedan bad jag min då 14 åriga dotter ladda ner Cain&Abel för att göra en Man-in-the-middle attack mot min bank-PC. Flickan plockade faktiskt fram engångslösenorden och följde med min https krypterade banksession - i klartext på sin egen PC.

Inte bra så jag kontaktade Ficora. De tyckte inte heller att det lät bra så deras jurist kontaktade mig och bad mig inte störa dem i fortsättningen!

Så, jag jag visade tricket åt YLE hur lätt man knäcker banksekretessen i det här landet. YLE bad Nordea om en kommentar, som hälsade att om bankens namn nämns i TV-inslaget så bussar dom sina jurister på YLE. Inslaget visades förstås i TV men blev bortförklarat av Ficoras dataexpert.

Så, jag kontaktade Nordeas styrelse som först hotade med sina jurister. När de märkte att jag trots allt har svårt att hålla tyst blev jag bjuden på kaffe med praliner på Alexendarsgatan i HAB:ens gamla salar. En småmysig tillställning där jag fick lära mig

a) hur litet det här problemet egentligen är eftersom de mestadels har företagskunder som på något sätt lär vara immuna mot MITM-attacker

b) att alla andra banker gör ju så här galet dom också, så då kan den bästa banken, Nordea, inte ändra sina rutiner heller

c) att om nån lyckas sno mina pengar från kontot så har de nog råd att betala dem tillbaka. Vilket jag ingalunda betvivlar, med tanke på mitt blygsamma saldo.

Att mina pengar i så fall hade hamnat i fel ficka och finansierarat gu-vet-vad bekymrade dem inte alls. Eftersom även jag lider av attitydproblem är jag inte kund i den banken längre.

Så, vad jag vet är allt både sagt och gjort redan.

Guje
Medlem
# Skrivet: 11 Jan 2015 02:15 - Editerad av: Guje
Svara 


Mig veterligen kör bankerna i Finland fortfarande med halv säkerhet utan riktig kundcertifiering.

Inte att undra på att all världens wannabees vädrar morgonluft...

Nisse
Medlem
# Skrivet: 11 Jan 2015 22:39
Svara 


Enligt optimisten kommer bankerna att ändra sitt beteende först då den stora katastrofen är ett faktum. Enligt pessimisten kommer de inte ens då att förbättra säkerheten ...

PortKatterno
Medlem
# Skrivet: 12 Jan 2015 15:37
Svara 


För min del använder jag Aktia och loggar in på vanligt sätt med användarnamn och lösenord. Men varje transaktion måste bekräftas med en sexsiffrig kod som kan användas bara en gång. Koderna får jag per snigelpost enligt en frekvens som tydligen bestäms enligt hur många koder jag har använt. Jag får 144 st per gång.

Även om någon kan avläsa min förbindelse och komma över mitt användarnamn, mitt lösenord och sifferkoden för den sessionen kan inga nya transaktioner från kontot göras utan en ny sifferkod. Så jag brukar betrakta systemet som säkert och har använt det överallt, bl.a. från hotell, också utomlands.

Guje
Medlem
# Skrivet: 12 Jan 2015 23:17
Svara 


Och om nån sitter där i mitten, mellan dig och banken, och bara väntar in din engångskod, och - då du skickar den - bryter kontakten till dig och utnyttjar koden på "bästa" sätt?

Om nu systemet är så säkert som du antar så är det väl ingen vits att kryptera trafiken över huvud taget. Eller?

I min värld betyder ordet "banksekretess" att även innehållet i mina banktransaktioner hålls hemliga. Det är inte bara kontotömningar som skall vara omöjliga. Även Kontots saldo och transaktioner måste förbli skyddade!

Engångskoder och kryptering låter förstås bra. Men om banken inte med säkerhet vet vem som sitter i andra ändan så är keden inte så värst stark.

Bebbe Nyberg
Medlem
# Skrivet: 13 Jan 2015 12:16
Svara 


Bankkoderna används ju också för att identifiera sig till andra aktörer, t.ex. skatteförvaltningen och befolkningsregistret. Hur är det med den saken då, kan nån annan ändra mina registeruppgifter?

Guje
Medlem
# Skrivet: 14 Jan 2015 09:26 - Editerad av: Guje
Svara 


Knappast kan nån ändra dina registeruppgifter. De ligger väl inskrivna i någon databas långt ner i urberget utan Internet-access. ... väl
Däremot har man hört om att personuppgifterna kan stjälas och sedan användas lite här och där. Kanske i någon web-butik som inte är så nogräknad med vart de skickar varan och vem som får fakturan.

Men det är en annan sak.

Såhär funkar den MITM-attack jag snackar om. Finessen är inbyggd i ARP-standarden så man kan inte fixa till det sådär bara. All TCP/IP trafik bygger på ARP-protokollet som finns i alla former av IP-trafik. Både i koppartrådar, fiber och i trådlöst. Hjälper inte att kryptera.

http://www.oxid.it/downloads/apr-intro.swf (Bli icke förskräckta av de första bilderna - klicka er fram i sekvensen så dyker animeringarna upp )

Den typ av kryptering bankerna i Finland använder sig av öppnas av en bugg i krypteringsprotokollet. Så här är alltså MINST TVÅ sk. egenskaper eller planeringsmissar som samverkar för att knäcka banksekretessen.

PortKatterno
Medlem
# Skrivet: 14 Jan 2015 17:43
Svara 


Aktia har även byggt in en annan säkerhetsmekanism i systemet. Om transaktionen går till ett konto utomlands räcker det inte med engångskoden. Då fordras ytterligare en pinkod för denna transaktion som kommer till mig som SMS. Också denna kod är en engångskod. Allt detta gör att jag nog inte oroar mig särskilt mycket för att någon skulle komma åt mina blysamma tillgångar på banken. Det är säkert lättare att kolla beloppen än att komma åt dem. Helt trygg kan man väl aldrig vara. Om NSA beslutar sig för att trakassera mig på något sätt kan nog ingen hindra dem.

Men hur skulle ett säkert system se ut? Vad vore det i andra sammanhang nämnda best practice för nätbankernas säkerhet?

Nisse
Medlem
# Skrivet: 14 Jan 2015 18:04
Svara 


Krypterad kommunikation borde bli normalinställning. Med ett tillräckligt bra krypteringsprotokoll.

Guje
Medlem
# Skrivet: 14 Jan 2015 19:40
Svara 


Inte blir ett system med engångskoder säkrare om man frågar efter ännu fler engångskoder. Är koderna synliga i skurkdatorn så är dom. Det är ju som att läsa upp engångskoden direkt från pappret för honom. Bara att invänta den sista koden ... sen slår han till.


PortKatterno: "Men hur skulle ett säkert system se ut?"

T.ex. som Nordea gör i Sverige. Där ger de också ett certifikat åt kunden så banken med säkerhet vet vem som är i andra ändan, sk. dubbla certifikat, ett för banken och ett för kunden. I Finland är det bara banken som har certifikat medan kunderna får engångskoder. Lite som man använder toapapper.


Klicka här och välj fliken e-kod
https://internetbanken.privat.nordea.se/nsp/login



eller här: Nordea på finska, men inte i Finland.
https://solo.nordea.com/nsc/engine?language=fi&cou ntry=FI


Så, nog kan dom bara dom vill!!!

Guje
Medlem
# Skrivet: 3 Feb 2015 22:22 - Editerad av: Guje
Svara 


Här i dagarna fick jag frågan: "Är det faktiskt så att det fortfarande är möjligt att läsa bankens SSL-krypterade lösenord från en annan dator?"

Så jag prövade Cain&Abel - precis som för över 10 år sedan. Denna gång valde jag Andelsbanken. Bedöm själva hur krypterat det är!

Test 1:
"REQUEST_PREVIOUS_QUERYSTRING=id%3D81201%26panknro%3D556009%26&REQUEST_LOGIN_ATTEMPTED=true&USERNAME=GujeWasHere&PWD=0071&x=17&y=5"

Test 2:
"REQUEST_PREVIOUS_QUERYSTRING=id%3D81201%26panknro%3D556009%26&REQUEST_LOGIN_ATTEMPTED=true&USERNAME=12121212&PWD=3232&x=12&y=5"


Såhär säger Nordea på sin Login-sida:

"Den här förbindelsen är krypterad med SSL-teknik. Låset i webbläsaren visar att förbindelsen är krypterad. I webbläsaren Firefox blir låset synligt då du klickar på texten "Nordea Bank Finland Plc (FI)" som finns på grön botten i adressfältet."
https://solo1.nordea.fi/nsp/login?language=sv&coun try=FI


Så att...inte så stora förändringar där inte! Däremot har Cain&Abel blivit ännu bättre. Hittade nya funktioner med nånting dom kallar för "Certificate Injection". Vad nu det kan vara? Kanske Nordea kan berätta!


-----------
PS. Ni kanske börjar förstå varför jag VURMAR för L2 låsningen i våra fibernät. Vi har ingående talat om just den saken i tråden om det ultimata nätet.

Guje
Medlem
# Skrivet: 3 Feb 2015 23:07
Svara 


Nu är det ju inte enbart bankerna som låter bli att berätta hela sanningen.

Även vi IT-mänskor tillhör samma patrask. ALLA vet att det är såhär - men INGEN gör nånting åt det. (förutom då något enstaka troll från Bromarf-skogarna och en och annan Italienare).

Exakt vad är det som IT-fackfolket tycker att är det roliga i MITM-attacker? I ur och skur, på konferans efter konferans, år ut och år in, visar man hur "enkelt" det går att blåsa dumma användare på deras lösenrd - bara man vill!!? Var är yrkesstoltheten - etiken?

Här ett alldeles färskt exempel igen. Skruva er fram till någon sekund före 25 minuter och tryck på play!

http://areena.yle.fi/tv/2449755

MarkusI
Medlem
# Skrivet: 4 Feb 2015 13:36
Svara 


Så jag prövade Cain&Abel - precis som för över 10 år sedan. Denna gång valde jag Andelsbanken. Bedöm själva hur krypterat det är!

Guje: Kan du beskriva topologin lite?

MarkusI
Medlem
# Skrivet: 4 Feb 2015 14:00 - Editerad av: MarkusI
Svara 


Här ett alldeles färskt exempel igen. Skruva er fram till någon sekund före 25 minuter och tryck på play!

http://areena.yle.fi/tv/2449755



För att detdär skall ha fungerat så måste reportern ha godkänt att lita på opålitliga certifikat, stort misstag.

Edit: Eller så går hans e-post och Facebook utan SSL.

Guje
Medlem
# Skrivet: 4 Feb 2015 16:16 - Editerad av: Guje
Svara 


Eller så fuskade nån in ett lämpligt certifikat som är helt ok...en lämplig proxyserver... in't vet jag vad dom pynjar med.

Eller... så har reportern bara begärt hjälp av de "hjälpsamma" dataknuttarna...

Utgångspunkten i programmet var att han gav dem fulla rättigheter att, med vilka metoder som helst, ta fram uppgifter om honom.

Metoderna är många och inte alltid av teknisk natur. Trollkonstnärer som dom är.

"Bedragarna har kapat Facebook-konton och har därefter kontaktat någon i personens vänkrets. Bedragarna har uppgett att de har problem med sin bankdosa och har bett att få låna bankkoder."

http://www.svt.se/nyheter/regionalt/vastmanlandsny tt/blev-av-med-tusentals-kronor-nar-facebookkontot -kapades

Mer:
http://www.svt.se/search/?q=bankkoder

Guje: Kan du beskriva topologin lite?,
Som sagt var, läs och begrunda. Allt finns på www.oxid.it:
http://www.oxid.it/downloads/apr-intro.swf


Så här såg Nordea skärmdumparna ut för 10 år sedan (2 sidor): http://bredband.selfip.net/forum/filebox/dokument/ nordeacrack.pdf

MarkusI
Medlem
# Skrivet: 4 Feb 2015 17:05
Svara 


Jag har ingen flashplayer till hands men jag antar att du, Guje, hade båda maskinerna på samma broadcast-domän ifall browsern och sniffern inte var på samma maskin tillochmed.

Om det inte var på samma maskin så sysslade du med ARP-spoofing för att få nätverksutrustningen att skicka trafik till tredje part.

Cain&Abel kan inte knäcka SSL. NSA kan inte knäcka SSL, dom "ber" om privatnycklarna till root-certifikaten från ifrågavarande Certificate Authority. Sen finns det andra saker som NSA gör men det är kanske inte så relevant i denna diskussion.

Så, ifall du såg lösenorden så skickar banksidan lösenorden utan SSL, inte bra.

I ett fullt ruttat nät, PVLAN kvalificerar inte, går det inte att spoofa trafik från grannen. Och SSL går inte att knäcka.

Sluta skrämma upp stackarna och lita inte på opålitliga certifikat eller operativsystem :)

Guje
Medlem
# Skrivet: 4 Feb 2015 19:50 - Editerad av: Guje
Svara 


MarkusI: "Sluta skrämma upp stackarna och lita inte på opålitliga certifikat eller operativsystem "

Just så snackar riktiga dataknuttar!

Klart det handlar om ARP spoofing. Och klart att det handlar om att förfalska certifikat. Vad annars? Vill du bortförklara och skicka skulden på folk som inte förstår bättre, får du nog lov att bli snäppet vassare än så! Om du påstår att bankerna skickar lösenorden utan SSL är bevisbördan din - inte min!

MarkusI: "Så, ifall du såg lösenorden så skickar banksidan lösenorden utan SSL, inte bra."

Här är adressen: https://www.op.fi/op/privatkunder?id=10000&srcpl=1 &kielikoodi=sv

Vad är bättre än att du själv kollar om lösenorden skickas utan SSL! När jag gjorde det för över 10 år sedan så var dom krypterade, precis så som jag skriver om i min text.

Citat: "No³åâõLA8IAwè›ëgª\ý~¨hÔ@Ù@(|QGMT
î7U-(aRäpÚ‡ †(âˆ$–hâ‰(ž– I! j©© l·ÕhμÁ@
ivèÑÕoñ\tIä‘H&©ä’L6)V\,ò‘B-ö)àr94@G"



Kan du alltså visa mig och världen att bankerna skickar lösenorden i klartext?
Som en extra övningsuppgift kan du förklara hur även mina garanterat SSL-krypterade Nordea saldosidor kan dyka upp på PC:n i rummet bredvid. (Se sid 2 i min pdf-fil)
(Tips: Inga trojaner eller fjärrstyrningar i farten)


När vi har den saken avklarad går vi vidare i analysen av SSL.

Johanh
Medlem
# Skrivet: 5 Feb 2015 00:09 - Editerad av: Johanh
Svara 


Jag ska inte kommentera Gujes avlyssning av trafiken desto mera, utan faller in i kören och rekommenderar att rutta trafiken, så slipper man mycket bekymmer.

Ni som gillar att kolla på SSL-skyddad trafik, certifikat m.m., installera Calomel SSL Validation i webbläsaren. Den ger en del intressanta uppgifter om olika sidors certifikat.

https://addons.mozilla.org/sv-se/firefox/addon/cal omel-ssl-validation/

En annan obligatorisk add-on är förstås: https://www.eff.org/https-everywhere

Calomel säger så här om Andelsbankens webbsida (https://www.op.fi/op/privatkunder?id=10000&srcpl= 1&kielikoodi=sv):

********************************
Calomel SSL Validation

Security : Warning! Very Weak (red 23%)
Certificate: Verified
Class: Extended Validation (EV)
URL Host : www.op.fi
Common Name (CN) : www.op.fi (matched)
Perfect Forward Secrecy [PFS] : NO (0/20)
Ciphersuite : TLS_RSA_WITH_RC4_128_SHA
Key Exchange : RSA/server key (3/25)
Signature : RSA
Bulk Cipher : RC4 128 bit (4/15)
MAC : SHA-1 (8/20)
Issued to : OP-Pohjola osk
: Helsinki Helsinki FI
: SHA-1 med RSA-kryptering 2048 bit (4/10)
Issued by : Symantec Corporation
: US
: SHA-1 med RSA-kryptering 2048 bit (4/10)
Valid from : 11.12.2014 02:00:00
Valid until : 13.12.2015 01:59:59
********************************

Märk väl den usla säkerhetsgraden på certifikatet (23% enligt Calomels bedömning). Ingen Perfect Forward Secrecy (PFS)! Vilket betyder att sparad trafik kan knäckas i framtiden om man kommer över nycklarna eller om krypteringen blir knäckt.

Man tycker ju att banker skulle satsa mera på certifikat om de är måna om sina kunder.

Andra banker kan ha bättre, t.ex. Handelsbanken i Finland graderas till 88% enligt Calomel. Nordea och Danske bank har dålig säkerhet med 34%. Aktia utmärker sig över de andra bankerna med 100% "kvalitetsgrad" på certifikatet; bästa möjliga certifikat som man kan få idag!

Det är sen inte så stor nytta om man som google visar på 100% (där har de bättrat sig ifjol och infört bl.a. PFS), om de ändå lämnar ut root-nycklar åt tredje part (det vet vi ju inte säkert, men högst antagligen).

Guje
Medlem
# Skrivet: 5 Feb 2015 09:18 - Editerad av: Guje
Svara 


Aj, Aktia 100%, "bästa möjliga certifikat som man kan få idag!", skriver Johanh.

Då kör vi! Här är Aktias inloggning som den ser ut på MITM-datorn:
[Client-side-data (74 bytes)]
IDToken1=12345678&IDToken2=helloworld&goto=&enc oded=false&gx_charset=UTF-8

I mina ögon verkar den där Calorimetern faktiskt ge olika utslag för samma resultat. Jag menar den ena banken har ett uselt resultat på 23% medan den andra får högsta betyg på 100%, men båda visar sina lösenord lika öppet. Månne säkerhets-%:en rentav är kopplad till årsavgiften. Låg avgift -> låg säkerhets-%, hög avgift -> hög säkerhets-%. Såna saker har man ju sett förr också.

För en som bor i Ekenästrakten dyker polisen Dido ohjälpligt upp I skallen. Efter ett inbrott sa han: "Av hålets storlek att bedöma var tjuvarnas antal två". Små säkerhetshål -> lite tjuvar, stora säkerhetshål -> många tjuvar.

Nåjo, det är ju inte bara IT-folk som resonerar som Dido. Och eftersom det är så många som gör det så är det inte så farligt. Trösta er med det!

Guje
Medlem
# Skrivet: 5 Feb 2015 09:26
Svara 


Johanh, du skrev: "faller in i kören och rekommenderar att rutta trafiken, så slipper man mycket bekymmer."

Att slippa mycket bekymmer låter ju bra!

Så hur skall grannen rutta sin trafik så jag inte kommer åt hans lösenord? Och då han sitter på ett Internet-café, hur ruttar han då?

MarkusI
Medlem
# Skrivet: 5 Feb 2015 11:13
Svara 


Guje: Om du gjorde experimentet med utgångspunkten att användarn trycker "Ja, lita på opålitliga certifikat" på allt som kommer upp och gjorde en äkta MITM-attack med certifikat-byte och återkryptering så kunde du endast bevisa att systemet fallerar på användarn.

Ta nu och berätta lite mera om hur du gjorde :)

Johanh
Medlem
# Skrivet: 5 Feb 2015 11:38
Svara 


Guje skrev:
Aj, Aktia 100%, "bästa möjliga certifikat som man kan få idag!", skriver Johanh.

Ja, det finns inte bättre certifikat. Det spelar ingen roll vad man har för certifikat om man råkar ut för en MITM-attack, eftersom man då antingen har accepterat ett falskt certifikat ELLER inte alls använder ett certifikat mera (eftersom MITM-attacken kan gå ut på att skurken tar hand om HTTPS mellan sig och banken och skickar en vanlig HTTP åt den intet ont anande användaren). Men det spelar nog roll i andra sammanhang än MITM-attacker, eftersom sämre certfikat kan knäckas.

Så hur skall grannen rutta sin trafik så jag inte kommer åt hans lösenord?

Det ska byanätet fixa. Switcharna skall rutta för att skilja på layer 2 mellan kunderna. Då blir ARP poisoning plötsligt mycket svårare.

Och då han sitter på ett Internet-café, hur ruttar han då?

Där går det inte att rutta. Då är det upp till användaren att inte acceptera okända certifikat. Och att försäkra sig om att anslutningen verkligen är HTTPS och att det officiella certifikatet används. Där hjälper browser-verktyg som Calomel och https-everywhere. Men sist och slutligen är det upp till användaren, så länge det inte finns andra tekniska lösningar på problemet.

MarkusI
Medlem
# Skrivet: 5 Feb 2015 11:55
Svara 


Man ska ju sen inte surfa till något personligt från en maskin som ägs av ett Internet-café. Där kan maskinerna vara med eller utan vilja preparerade för att "låna" användarns information.

En lösning är att ha en egen laptop med på resan och en VPN-burk hemma som man tunnlar via för att komma genom Caféets MITM-gateway. Det talas om att 128bits AES-kryptering inte riktigt räcker mera så man ska titta på VPN-inställningarna lite också...

Johanh
Medlem
# Skrivet: 5 Feb 2015 12:04 - Editerad av: Johanh
Svara 


Hur man skyddar sig mot Gujes MITM attack:

- Se till att du aldrig sitter på samma layer 2 som Guje. Det kan innebära:
- se till att rutta trafiken mellan anslutningar i ett byanät
- se till att säkra dina hemma-apparater med router och brandvägg
- hårdkoda ARP-cache (detta är kanske inte så praktiskt och används ganska sällan)
- använd en IDS för att övervaka ARP-trafik och DNS-spoofing (det är lite extremt och svårt att övervaka i ett stort nätverk)
- Gör dina bankärenden endast hemifrån
- Viktigast är ändå att se till att webbläsaren alltid har på HTTPS då man gör bankärenden. Har den inte det, då är det nästan 100% säkert att man är utsatt för en MITM-attack.
- Acceptera inte okända certifikat, speciellt inte från en bank
- Riktigt viktiga system använder IP-nummer istället för DNS, för att undvika DNS-spoofing. Eller använd den lokala hosts-filen. DNSSEC är förstås ännu bättre. I USA är det obligariskt för staten (åtminstone GOV och MIL) att använda DNSSEC.
- Edit: VPN är också ett verktyg om man är på ett osäkert nätverk

Guje
Medlem
# Skrivet: 5 Feb 2015 18:32 - Editerad av: Guje
Svara 


Det här rådet köper jag: "- Se till att du aldrig sitter på samma layer 2 som Guje."


Som ni märker så kan grannen egentligen inte göra så mycket annat. Det hjälper t.ex. inte att utrusta datorn med världens bästa brandmurar och världens säkraste operativsystem. Jag sitter ju UTANFÖR er dator och ser på trafiken som går av och an - när banken skickar nåt åt er så ser JAG det först. Är jag på gott humör så skickar informationen oförändrad vidare till er. När ni skickar nåt åt banken så ser JAG det först. Har ni tur är jag på gott humör då också.

De flesta råd ni ger faller på nätbyggarens axlar, som ruttandet och Layer 2 skyddet, resten av era råd faller i råskis. Folk brukar vara godtrogna - och skall så få vara. Vem tusan märker av om certifikatet är bankens eller inte om browsern släpper igenom det? Det är ju bara att köpa ett sånt certifikat och tuta och köra. Sen finns det också en massa sätt att få egna signerade certifikat godkända i offrets pc. Trollkonsterna är många och inte alltid av teknisk natur.

I era inlägg läser jag att användaren egentligen får skylla sig själv om han råkar illa ut. Men, vilket ansvar tycker ni bankerna har? Det är ju deras verktyg vi använder. Nog har konsumentskyddet fått fason på andra farliga grejer också, så varför inte denna gång?

Det finns ju tekniska lösningar, så varför filosofera kring saken som du gör här, Johanh: "Men sist och slutligen är det upp till användaren, så länge det inte finns andra tekniska lösningar på problemet."

Kolla nu på nytt mina tidigare länkar till bankernas egna lösningar! Problemet är att de inte tagit dem i bruk i Finland!

Tid har dom haft på sig gud i nog. Påminner om att min 14:åriga dotter redan för över 10 år sedan visade Cain&Abel tricket för dem. Men deras attityd var redan då den som ni här och nu också framför: Användarens eget fel. Men, så är det nog inte!

Sen är det ju inte heller alldeles fel att tänka över vad man skriver! Varifrån fick du tex MarkusI att bankernas lösenord inte skulle vara krypterade. Skall man bli hörd i det här sammanhanget så måste man tillräckligt vara påläst.

Johanh
Medlem
# Skrivet: 5 Feb 2015 20:41
Svara 


Antagligen har inte bankerna förlorat pengar på MITM-attacker ännu tillräckligt mycket för att motivera att förnya systemet. Jag ser inget konstigt där. Det är ju så allt fungerar. Man använder halvdåliga tekniska lösningar tills lagstiftning eller marknaden tvingar en att förnya systemet.

Ska man vara sarkastisk så håller ju dessutom säkerheten på att bli sämre. Om Storbritanniens regering får igenom sitt förslag så ska ju kryptering "förbjudas" där, eller ändras så att det finns "bakvägar" för staten. Det de inte fattar är att man då också tillåter skurkar och terrorister at komma in. Ibland tror man att politiker är skvatt galna.

Det finns många andra områden också som man kan reta sig på varför det inte används bättre tekniska lösningar.

MarkusI
Medlem
# Skrivet: 5 Feb 2015 21:22
Svara 


Sen är det ju inte heller alldeles fel att tänka över vad man skriver! Varifrån fick du tex MarkusI att bankernas lösenord inte skulle vara krypterade. Skall man bli hörd i det här sammanhanget så måste man tillräckligt vara påläst.


Jag håller med om att man borde tänka igenom vad man skriver, jag hoppas andra gör det också :)

Varifrån fick jag att bankernas lösenord inte skulle vara krypterade? Jo, DU, Guje, vägrade berätta om tekniska/sociala lösningen till din MITM-attack så jag antog att kunden visste att man inte skall lita på opålitliga certifikat och att kundens dator inte var under någon annans än kundens makt.

Under detta antagande sade jag att ifall du såg lösenorden så gick den trafiken utanför SSL-tunneln som borde uppstå direkt man öppnar nätbanken för att logga in:

Så, ifall du såg lösenorden så skickar banksidan lösenorden utan SSL, inte bra.

Jag antar också att alla banker ser till att trafiken går genom en SSL-tunnel. Webbläsarna, i alla fall dom vettiga, meddelar nog ifall certifikatet är opålitligt. På samma sätt som att man inte litar på alla människor så borde vi medborgare också förstå att inte lita på allt man ser på Internet. T.ex. att dubbelkolla adressen och dendär lås-ikonen i webbläsarn hör till. Jag vet inte bakom vilken sten man bor ifall man missat alla meddelanden från banken som säger att man skall göra det.

Johanh
Medlem
# Skrivet: 5 Feb 2015 22:50
Svara 


Om man nu skulle nysta lite till i det här...

Nu är det ju så att nätverket ser ut som det ser ut på layer 2. Det finns ingen teknisk lösning som helt skulle förhindra ARP-poisoning, DNS-spoofing och SSL-hijacking på den nivån (de mest vanliga MITM-attackerna).

Om du då Guje föreslår en mackapär som bankerna har i Sverige, med end-to-end kryptering, så löser ju det inte det ursprungliga problemet, utan alla andra webbsidor är fortfarande lika osäkra och utsatta för MITM.

Så det är gott och väl att en viss bank kan lösa det mellan sig själv och kunden, men hur gör man med alla andra webbsidor? Ska varje enskild sida på nätet skicka ett certifikat åt användaren? Det ser jag ingen vettig lösning på hur det skulle hanteras.

Vi kommer alltså tillbaka till nätverket. Använd en router hemma. Bygg in routrar i byanätet. Var medveten om riskerna.

Johanh
Medlem
# Skrivet: 5 Feb 2015 23:37
Svara 


Vi har i alla fall mycket bättre säkerhet i våra banker än i USA. Där frågar bankerna fortfarande efter "your mother's maiden name" som säkerhetsfråga
http://gizmodo.com/heres-why-your-bank-account-is- less-secure-than-your-gm-1683777281

Guje
Medlem
# Skrivet: 5 Feb 2015 23:59
Svara 


Nu är det viktiga inte HUR just jag, rent tekniskt, plockar ut lösenorden. Det viktiga är att nån i teorin KAN avläsa koderna. För att inte tala om det katastrofala att nån i praktiken faktiskt gör det också! Sådär lätt, och sådär länge.

Hela resonemanget med lösenord bygger ju på att de skall hållas hemliga. Bankerna uppmanar tom. sina kunder att inte visa sina koder för nån. Koderna skall dessutom förvaras skilt från andra inloggningsuppgifter.

Och vad är det första som kan hända med koden då banken tar emot den? Jo, att den hamnar inför skurkögon - i klartext dessutom - trots att banken säger att förbindelsen är krypterad. Vad är det för säkerhetssystem! Ett jäkla hymlande med engångskoder och smygande med papperslappar, som till slut kan visa sig ha varit förgäves! De e va de e!

Påminner starkt om hemligheten att odla champinjoner: Håll dom i mörker och mata dom med dynga.

Guje
Medlem
# Skrivet: 6 Feb 2015 00:12
Svara 


(Inläggen tycks droppa in lite i kors ... de va länge sen!)


Aj...ja...bättre än i USA...lite som principen ät-upp-din-gröt-det-finns-dom-som-inte-får-nån -mat?

Nä, inte föreslår jag nån mackapär, men om det inte går med nåt annat så... jovisst. Det är det värt!

Det jag är ute efter är att åtminstone den viktiga banktrafiken kollar vem som sitter i BÅDA ändorna av tråden. Och inte som nu då banken ger ett certifikat medan kunden knappar in en osäker kod.

Kanske som i Estland där medborgarna har sina egna certifikat som staten bjuder på. (Rätta mig här om jag har fel - har inte kollat läget). Men som princip alltså att alla, personer, institutioner, företag, har sina certifikat, lätt tillgängliga dessutom. Finland har nog en lång väg ännu till "världsledande säkerhetsnation" som det snackats om.

Guje
Medlem
# Skrivet: 6 Feb 2015 00:24 - Editerad av: Guje
Svara 


Johanh skrev: "Vi kommer alltså tillbaka till nätverket. Använd en router hemma. Bygg in routrar i byanätet. "

Har du tänkt på att om jag knycker ut min egen router och grannen har sin inkopplad så ligger jag i samma L2 som grannens router. Då kan jag ARP-spoofa trafiken mellan grannen och vår gemensamma gatewayen.

Kopplar jag in min egen router fel, så den börjar dela ut DHCP i byanätet så faller byanätet ganska snabbt.

Nätet måste alltså L2 säkras från byanätets sida och vara oberoende av om kunden har en router eller inte.

Det betyder att rådet åt kunden att sätta in en router egentligen inte har nån betydelse. Det är L2 isoleringen som är avgörande. (Men det har vi ju redan snackat igenom i annan tråd)

Nisse
Medlem
# Skrivet: 6 Feb 2015 06:07
Svara 


Jag kollade in Cloudflare som påstår att deras Strict SSL hindrar MitM. Vad jag förstår så använder bankerna inte strikt SSL. Helt klart pågår ett krig mellan skurkar och säkerhets

Guje
Medlem
# Skrivet: 6 Feb 2015 08:58 - Editerad av: Guje
Svara 


Man kunde tro att de använder sin egen medicin.

Det här dyker upp då jag loggar in på https://www.cloudflare.com/login

login_email=kollar@bara.com&login_pass=hellowor ld&security_token=MTQyMzIwMTAyOHRQd2huYmJsc0JxQnJ QS3pUTEd0WFZpcXRZTmlNcVhI&act=login


Nästa! Har ni fler förslag?

MarkusI snackade nånting om operativsystem. Har du nåt på den fronten så min granne kan åtgärda? Bästa rådet hittills är att över huvud taget inte finnas i samma layer 2 med mig. Och i vårt fall betyder det att han borde drar ut nätkabeln från sin fiberanslutning. Och stänga sin WiFi för annars kommer jag väl in den vägen i stället.

MarkusI
Medlem
# Skrivet: 6 Feb 2015 10:10
Svara 


Har du tänkt på att om jag knycker ut min egen router och grannen har sin inkopplad så ligger jag i samma L2 som grannens router. Då kan jag ARP-spoofa trafiken mellan grannen och vår gemensamma gatewayen.

Kopplar jag in min egen router fel, så den börjar dela ut DHCP i byanätet så faller byanätet ganska snabbt.

Nätet måste alltså L2 säkras från byanätets sida och vara oberoende av om kunden har en router eller inte.



JohanH:s point var att nätet skall vara byggt så att varje kund ansluts till ett eget broadcast-domän samt ip-subnet. Om kunden inte har makt över byanätets access-apparatur så kan inte kunden spoofa något alls. L2 och L3 -isolering är enda 100% spoofsäkra lösningen.

MarkusI
Medlem
# Skrivet: 6 Feb 2015 10:16
Svara 


MarkusI snackade nånting om operativsystem. Har du nåt på den fronten så min granne kan åtgärda? Bästa rådet hittills är att över huvud taget inte finnas i samma layer 2 med mig. Och i vårt fall betyder det att han borde drar ut nätkabeln från sin fiberanslutning. Och stänga sin WiFi för annars kommer jag väl in den vägen i stället.


Mitt råd är att undvika Windows ifall man vill investera i att säkra operativsystemet. Och jo, WiFi är ett stort säkerhetshål.

Guje
Medlem
# Skrivet: 6 Feb 2015 11:22
Svara 


OM nätet har ett L2-skydd så är saken OK. Den som fixar det skyddet är nätbyggaren och nånting som kunderna inte kan påverka. Det tror jag vi alla kan vara över ens om.

Det står ju tom. inskrivet i lagen att det hör till nätoperatörens skyldighet att förhindra avlyssning. Nånting som dök upp i lagboken en tid efter min första kontakt till Ficora för ca. 10 år sedan. Så, jo, på så sätt var ju Ficora alerta. Och helt säkert redan innan jag knackade på dörren. L2-skyddet är alltså gammal skåpmat redan.

Men nu snackar snackar vi om vad KUNDEN kan göra. Du har flera gånger signalerat att man skall välja bra operativsystem och browser, så skyddar man sig från MITM-attacker. Min granne har Windows 8.1 och IE. Med tanke på MITM, är det bra det?

Guje
Medlem
# Skrivet: 6 Feb 2015 11:27
Svara 


Lite korspostningar igen...

Ok, jo Windows/Linux dialogen är en evighetsfråga.

Så - hur förhindrar Linux (eller Windows) en MITM-attack?

MarkusI
Medlem
# Skrivet: 6 Feb 2015 11:38
Svara 


Så - hur förhindrar Linux (eller Windows) en MITM-attack?

Först några frågor:

- Är kunden uppmärksam?
- Är kund-datorn fortfarande under kundens makt och ren?

Guje
Medlem
# Skrivet: 6 Feb 2015 12:12 - Editerad av: Guje
Svara 


Vad är det för frågor? Kunden litar på att operativsystemet tar hand om MITM-attacken förstås! Så som du låter påskina.

Eller är det så att kunden måste vara extra uppmärksam när hon kör Linux?
Som en samvetsgrann cybermedborgare är alla uppdateringar, brandmurar och virusskydd på plats. Inga betänkligheter där inte.

MarkusI
Medlem
# Skrivet: 6 Feb 2015 14:02
Svara 


Det är en vanlig artighet att svara på frågor som försöker klarlägga situationen.

Och nej, man behöver inte vara extra uppmärksam då man kör Linux. Kan inte säga samma sak om Windows och dess inbyggda webbläsarprogram.

TLS (SSL) har svagheter. Största och mest sannolika svagheten är användarn som ska bestämma om denne litar på andra parten. De andra svagheterna kräver att man fifflar med processorns slumptalsgenerator eller att privata nycklar har läckt ut på något sätt.

Om vi utgår från att kunden är uppmärksam och datorn är ren så finns det ingen chans att känslig trafik går okrypterat. Din MITM-attacktyp är alltså att agera proxy mellan kunden och banken för att kunna "strippa" bort TLS och passa trafiken till kunden över okrypterad HTTP. Här kommer kunden att märka att låsikonen försvann och ifall webbläsarprogrammet samt webbsidan stöder HSTS så kommer webbläsarn att vägra surfa till adressen (med den förutsättning att webbläsarn fått kommunicera med webbsidan före MITM-attacken). Internet Explorer kommer att stöda HSTS först i Windows 10. Där har (andra operativsystem med) andra webbläsarprogram möjligheten att vara bättre.

Om vi utgår från att kunden är "din mommo" som "bara vill till banken" och inte förstår sig på saken alls så då är det kört. "din mommo" installerar tillochmed ett Root-certifikat från falsk tredje part, mot en trevlig diskussion med "nån från supporten", i värsta fall som möjliggör en massa roligheter.

Allt baserar sig alltså på att om datorn, mer bestämt webbläsarprogrammet, är rent och om användarn är uppmärksam. Jo, det är lätt att rubba den balansen men vi har i åratal blivit påminnda om att inte godkänna opålitliga certifikat samt att kolla att låsikonen finns genom hela känsliga sessionen.

- errare humanum est -

Johanh
Medlem
# Skrivet: 6 Feb 2015 14:16
Svara 


Känns som att denna diskussion håller på att bli "someone is wrong on the Internet"...

Och HSTS är en bra grej. Den borde bankerna ta i bruk omedelbart om de vore ens lite rädda för Guje och hans medbröder.

https://en.wikipedia.org/wiki/HTTP_Strict_Transpor t_Security

Det är en rätt ny standard, men den är absolut åt rätt håll.

Guje
Medlem
# Skrivet: 6 Feb 2015 14:49
Svara 


Ok, "Allt baserar sig alltså på att om datorn, mer bestämt webbläsarprogrammet, är rent och om användarn är uppmärksam."

Så då är det inte operativsystemet som skyddar utan a) webbläsarprogrammet och b) användaren själv. Det betyder att val av operativsystem inte spelar någon roll alls i en MITM-attack. Linux, iOS, Android, Windows - det kvittar.

Återstår browsern och användaren. Men, som du själv säger, om användaren felar så felar browsern också. Summa sumarum: Varken operativsystem eller browser skyddar i en MITM-atttack utan det ligger HELT OCH HÅLLET på användarens axlar att märka av då lamporna börjar blinka. OM dom börjar blinka.

Påstår du alltså fortfarande att Linux är bra i en MITM-attack? Operativsystemet märker ju inte ens av MITM-attacken gång. Brandmurarna ser den inte. Antiviruset ser inte attacken. Browsern försöker varna - OM DEN KAN! Bara användarn stoppar - om hon märker den. Låter inte särskilt tryggt det du skriver: - errare humanum est -

Hade du haft din flash i skick så hade du kunnat bekanta dig med bl.a. Cain&Abel's demo jag hänvisade till då du först undrade hur det går till. Då hade du också märkt att här inte finns nån Proxy på vägen. På deras hemsidor kan man läsa om att certifikatet, ett falsk sådant, skickas till användarens browser. Som naturligtvis ropar till.

MarkusI, en liten undran. Hur varnar browsern om jag injicerar ett godkänt certifikat jag köpt?

Guje
Medlem
# Skrivet: 6 Feb 2015 16:26
Svara 


HSTS verkar intressant eftersom dom - i motsats till Nisses tips om CluodFlare - berättar vad dom gör i en RFC. Det är det första. Svampodlare skall man inte ha att göra med!

Noterar samtidigt ett intressant årtal på wiki-länken:

The most important security vulnerability that HSTS can fix is SSL-stripping man-in-the-middle attacks, first publicly introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk "New Tricks For Defeating SSL In Practice".

Intresssant därför att Cain&Abel sårbarheten var känd redan 2003. Undrar om HSTS fixat den läckan också?


Jag har inga lösningar på problemet, andra än den att använda certifikat i båda ändorna. Jag är bara en budbärare det inte lönar sig att satsa krut+kula på.

Guje
Medlem
# Skrivet: 6 Feb 2015 16:30
Svara 


Johanh: "Och HSTS är en bra grej. Den borde bankerna ta i bruk omedelbart om de vore ens lite rädda för Guje och hans medbröder. "

Ingen fara. Vi fick vår utbildning på 60-talet i söndagsskolan i Liljendal. Sen kan det vara annat med dom som inte gick just där.

Guje
Medlem
# Skrivet: 6 Feb 2015 19:56 - Editerad av: Guje
Svara 


Vad sägs om det här då när jag har Cain på arbetstur och surfar till sidan

https://projects.dm.id.lv/Public-Key-Pins_test

Firefox:

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.


projects.dm.id.lv uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_unknown_issuer)


IE:

Går gladeligen in på siten - oberoende om Cain är ledig eller om han jobbar.



Nu har grannen ett alternativ till att dra ut sladden. Han kan använda Firefox.

Nån som undrar om Firefox stoppade accessen till nån av bankerna? Nä.

Men, kom ihåg - Cain är på jobb och ser ändå det mesta. DNS:sökningar och sånt.

Kom också ihåg att detta bara är en test av mig som saknar större betydelse. Det SER ju ut att funka. Men om det gverkligen gör det hittar man i dokumenteringen av de metoder som används. Plötsligt hittar Cain på nåt nytt finurligt och då är det kanske kört igen.

Edit: Kanske man borde testa med ett riktigt certifikat också. Ett själv signerat certifikat är ju ganska enkelt att stoppa...tog nog inte Cain ännu..

Johanh
Medlem
# Skrivet: 6 Feb 2015 22:00
Svara 


Bra att vi fick det bekräftat. Åtminstone motsvarar det det som skrivs om HSTS på nätet. Återstår bara att övertyga bankerna att de skall använda HSTS, då. Och få folk att använda Firefox och Chrome istället för IE.

Om du skaffar ett riktigt certifikat har du fortfarande fel CN och webbläsaren borde reagera. Men du kan förstås ha en bluffsida som certifikatet verkar stämma mot. Så det spelar inte så stor roll vilken metod du använder, utan cert, med self-signed, eller med ett riktigt. I alla tre fallen gäller det för slutanvändaren att märka att inte certifikatet stämmer (eller saknas). Detta gäller då utan HSTS. Med HSTS i bruk, så spelar det ingen roll vilken av dessa tre scenarion som används, då borde webbläsaren reagera och stoppa sidan.

En annan intressant sak är om det är möjligt för en MITM attack att lyckas då en användare har ett PKI certifikat, t.ex. i ett smartcard från en bank (det som du nämnde tidigare). Jag gissar att en MITM attack fortfarande kan lyckas om den som attackerar skickar ett falskt certifikat och användaren accepterar det i webbläsaren. Dvs, samma scenario som ovan. Enda räddningen i detta fall vore också HSTS. Det borde gå i Finland att få PKI-certifikat från banker också, åtminstone som företagskund. Kanske någon är villig att testa det som har? Dessutom i äldre webbläsare finns det kryphål där SSL-attacker kan lyckas transparent, utan att någon varning visas.

Den säkraste lösningen är förstås VPN-tunnel till banken. Då går det inte att luras mera. Jo, man borde kunna med ARP-poisoning (ditt Cain och Abel-program) avbryta trafiken, men det som händer är att tunneln stängs. Men det är nog en dyr lösning med VPN.

rahlskog
Medlem
# Skrivet: 6 Feb 2015 22:10
Svara 


Nu har jag sett på tillräckligt länge från sidan och hamnade skapa konto för att stiga in.

Firefox:

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.


projects.dm.id.lv uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_unknown_issuer)


IE:

Går gladeligen in på siten - oberoende om Cain är ledig eller om han jobbar.



Nu har grannen ett alternativ till att dra ut sladden. Han kan använda Firefox.

Nån som undrar om Firefox stoppade accessen till nån av bankerna? Nä.

Men, kom ihåg - Cain är på jobb och ser ändå det mesta. DNS:sökningar och sånt.

Kom också ihåg att detta bara är en test av mig som saknar större betydelse. Det SER ju ut att funka. Men om det gverkligen gör det hittar man i dokumenteringen av de metoder som används. Plötsligt hittar Cain på nåt nytt finurligt och då är det kanske kört igen.

Edit: Kanske man borde testa med ett riktigt certifikat också. Ett själv signerat certifikat är ju ganska enkelt att stoppa...tog nog inte Cain ännu..


Din test berättade inget som vi inte redan visste.
Firefox och Chrome har stöd för HSTS, IE har inte det före Windows 10. Det också krävs en serverside flagga för att aktivera HSTS så är det knappast förvånande att bankerna inte har det då den ännu har status "PROPOSED STANDARD" och kan ändras ifall problem hittas. Det som lite förvånade mej var att Cain helt missade chansen att bryta HSTS vilket går att göra endast första gången man besöker en HSTS sida. Ett riktigt certifikat skulle inte hjälpa dej mycket här, du får inte nån respektabel CA att ge ut ett cert för op.fi eller liknande.

Men tack för att du fick mej att gräva banksäkerhet, jag ska ha en diskussion med Andelsbanken om RC4.

Guje
Medlem
# Skrivet: 6 Feb 2015 23:13
Svara 


Va roligt att diskussionen röner intresse. Äntligen får man väl säga! Tacksam dessutom för alla goda råd och tips ni för in här i tråden.

Problemet har faktiskt varit det att fackfolket tigit som muren om de här sakerna. Ända upp i Ficoras och bankinspektionens korridorer har det varit tyst som i graven. Alla vet ändå hur det är, men man tiger! Så, att... kanske tiden är inne för en attitydförändring så småningom. Gör som rahlskog, MarkusI, Johanh mfl. Logga gärna in och skriv en snutt om era tankar!

------
HSTS kom till min kännedom först i dag då Johanh tipsade om saken. Så för mig är konceptet helt nytt. Försökte Googla en stund för att läsa in mig på ämnet. Principen att all trafik måste krypteras har legat i bakhuvet på mig en längre tid redan, men jag har inte kommit till skott riktigt ännu. Så, HSTS kom faktiskt på beställning sas. Nån som på rak arm kan säga något om IIS stöd? Finns det alternativ till HSTS? Man kunde ju öva med vårt forum t.ex.

-------
PEN testen med Cain&Abel är gjorda direkt out-of-the box. Ladda ner - installera - kör - fundera en stund vad knapparna gör - och så spoofar man.
Nu antar jag att Cain nog jobbade på i bakgrunden och inte ens försökte komma förbi HSTS. Tills vidare finns där ingen sån funktion ens inbyggd.

Att skaffa ett op.fi certifikat kan förstås vara knepigt, men kanske ett oq.fi kunde lura nån - typ. Det var närmast Johanh:s tanke med en bluffsida jag tänkte på. Och när man själv gör de här testen så duger ju vilket eget certifikat som helst. Här handlar det mer om principen än att lura nån. Men, jag tror förstås er om ni säger att HSTS stoppar även såna försök.


Mera tankar! Nån med synpunkter?

Nisse
Medlem
# Skrivet: 7 Feb 2015 05:58
Svara 


Tyvärr har vi alltid kvar den mänskliga faktorn. Även om certifikaten är vattentäta så finns risken att folk blir vana att strunta i dem. Jag har redan ett par gånger råkat ut för att jag måste godkänna ett obekräftat certifikat.

Det är litet som att ropa "Vargen kommer". Om systemet varnar i onödan väldigt ofta så blir man van att automatiskt godkänna obekräftade certifikat ... Så ett bra säkerhetsystem måste bli så bra standard att det bli ovanligt med obekräftade certifikat.

Förstås är folk försiktiga att godkänna obekräftade certifikat då det gäller bankärenden men risken finns.

Guje
Medlem
# Skrivet: 7 Feb 2015 11:15
Svara 


Det som Nisse skriver om vargen och det som MarkusI konstaterade om den mänskliga faktorn: - errare humanum est - ökar ju inte trygghetskänslan precis. Men det låter ju tryggt det där med bankens engångskoder som ibland dubbelkollas med ett SMS till den egna telefonen. Och det man inget vet om, mår man inte dåligt av heller. Men, om man vet vilka vägar de där koderna kan ta, så .... ja....

Euforin och lättnaden är därför stor när HSTS dyker upp som tar hand om fejkade certifikat.

Nedan har vi sättet Cain jobbar på. Han hoppar in i handskakningsproceduren vid lämpligt ögonblick och får banken att tro att Cain är kunden och får kunden att tro att han snackar med banken. Cain producerar ett helt eget certifikat åt kunden, som HSTS i vilket fall som helst kommer att förkasta. Inte sant? Berätta nu för oroliga mig varför det är så! Och vad som hindrar Cain att inte spela CA också. Han tillverkar ju rot-certifikat på löpande band, den jäkeln.

Jag citerar manualen i Cain&Abel:

How it works
Cain's HTTPS sniffer works in FULL-DUPLEX CLIENT-SIDE STEALTH mode; both server and client traffic is decrypted and if spoofing is enabled the attacker's IP and MAC addresses are never exposed to the victim client. Connections are accepted by a local "acceptor" socket listening on HTTPS port defined in the configuration dialog; this socket handle hijacked client connections but only when APR is enabled. OpenSSL libraries are used to manage SSL communications over two more sockets, one used for the traffic between the client <-> Cain and the other used for the traffic between Cain <-> server.



This is how all works step by step:



1) The HTTPS filter is enabled by the user in the configuration dialog

2) APR is enabled by the user using the button on the toolbar -> the Man-in-the-Middle attack is ready

3) The victim client starts a new session to an HTTPS enabled server (e.g. https://login.passport.com)

4) Packets from the client are hijacked by APR and captured by Cain's sniffer by mean of Winpcap driver

5) APR-HTTPS search for a fake certificate associated to the requested server in the Certificate Collector; if present the certificate will be used if not it will be automatically downloaded, properly modified and stored locally for future usage .

6) Packets from the victim are modified so that they are re-directed to the local acceptor socket; modifications are made on MAC addresses, IP addresses and TCP source ports (Port Address Translation "PAT" is used to handle multiple connections). The data captured is then sent again into the network using Winpcap but it is this time addressed to the local socket that will accept the Client-side connection.

7) The Server-side socket is created and connected to the real server requested by the victim.

8) OpenSSL libraries are used to manage encryption on both sockets using the fake certificate victim-side and the real certificate sever-side.

9) Packets sent by the Client-side socket are modified again to reach the victim's host.

10) Data coming from the server is decrypted, saved to session files, re-encrypted and sent to the victim host by mean of the Client-side socket.

11) Data coming from the client is decrypted, saved to session files, re-encrypted and sent to the server by mean of the Server-side socket.



Although it can be noticed from the fake certificate file used, this kind of attack is STEALTH from a client point of view because the victim thinks to be connected to the real server; try a "netstat -an" on the client to check yourself.



Once decrypted, traffic from the client is also sent to the HTTP sniffer filter for a further analysis on credentials. You can take a look at the data saved in session files by APR-HTTPS here.

Prerequisites
This feature needs APR to be enabled and a Man-in-the-Middle condition between the HTTPS server and the victim host.

Limitations
This feature does not work like a PROXY server; because of the usage of the Winpcap driver it cannot decrypt HTTPS sessions initiated from the local host.

Johanh
Medlem
# Skrivet: 7 Feb 2015 11:50 - Editerad av: Johanh
Svara 


Det är en sak att tillverka falska certifikat som användaren kanske inte upptäcker, men det borde inte gå att göra sådana falska certifikat som kunde lura webbläsare och sidor med HSTS. Åtminstone inget som det rapporterats om.

Här är förresten en add-on åt Firefox som visar om sidan har stöd för HSTS eller inte:
https://addons.mozilla.org/en-US/firefox/addon/str ict-transport-security-d/
Med den installerad kan man klicka på certifikat-ikonen för att visa om sidan har stöd för "Strict option".

Med HSTS, så kan en MITM-attack lyckas endast om användaren ansluter första gången till en HTTP-sida. Är användaren fiffig och kommer direkt till HTTPS-sidan, så misslyckas MITM-attacken. Firefox och Chrome har en delvis gemensam lista med sidor som har HSTS-stöd. Går man till en sådan sida, så är också en MITM-attack inte möjlig.

Gällande IIS-server och HSTS, så googlade jag åt dig: https://hstsiis.codeplex.com/
Det verkar inte räcka enbart med att sätta till en custom header. Kan ju finnas andra lösningar; jag använder inte IIS, så jag känner inte till det.

Guje
Medlem
# Skrivet: 7 Feb 2015 17:34 - Editerad av: Guje
Svara 


Du skriver: "...det borde inte gå att göra sådana falska certifikat ". Hymla inte! Går det - eller går det inte? Ja eller nej! Jag vet många saker det inte rapporterats om, men som ändå existerar. Jag menar - du föreslår faktiskt HSTS som ett säkerhetskoncept för bankerna!

Man blir inte särskilt stärkt i tron av följande heller:

rahlskog skriver: "Det som lite förvånade mej var att Cain helt missade chansen att bryta HSTS vilket går att göra endast första gången man besöker en HSTS sida.
Själv skarvar du i: "Med HSTS, så kan en MITM-attack lyckas endast om användaren ansluter första gången till en HTTP-sida."

Jaha - så HSTS stoppar inte MITM-attacker, sen heller! Så vitt jag vet försökte Cain inte ens överlista HSTS. Jag testade inte en "första kontakt". Dra absolut inga slutsatser från de test jag gjorde! Det som HSTS stoppade var ett självsignerat certifikat, och såna stoppas alltid. Oberoende om det är Cain eller inte.


Vidare skriver rahlskog: "Ett riktigt certifikat skulle inte hjälpa dej mycket här, du får inte nån respektabel CA att ge ut ett cert för op.fi eller liknande."

Och om CA:n inte är respektabel, vilka certifikat får man då tag på?


I mina ögon är HSTS lite malplacerad. Det är väl där som läckan finns (Cain) man borde täppa till och inte där det rinner ut? Varför över huvud taget släppa in Cain i handskaknigsproceduren? Det är ju där säkerhetshålet finns.

Här några hål till det rinner ut ur. Skall de också få sitt HTST-plåster?
(jag listar Cain&Abel's ganska självförklarande bokstavskombinationer)

- DNS
- SSH-1
- HTTPS
- ProxyHTTPS
- RDP
- FTPS
- POP3S
- IMAPS
- LDAPS
- SIPS

Johanh
Medlem
# Skrivet: 7 Feb 2015 19:43
Svara 


Man blir inte särskilt stärkt i tron av följande heller:

rahlskog skriver: "Det som lite förvånade mej var att Cain helt missade chansen att bryta HSTS vilket går att göra endast första gången man besöker en HSTS sida.
Själv skarvar du i: "Med HSTS, så kan en MITM-attack lyckas endast om användaren ansluter första gången till en HTTP-sida."

Jaha - så HSTS stoppar inte MITM-attacker, sen heller!


Det handlar inte om tro. Ta nu och läs hur HSTS fungerar...

Guje
Medlem
# Skrivet: 7 Feb 2015 21:49 - Editerad av: Guje
Svara 


Hjälper föga vad JAG läser och vad JAG tror om säkerheten på nätet. Det är nog andra personers tyckanden och menanden som är avgörande! Era rader om möjlig MITM attack mot HSTS räckte för mig, och många andra säkert också. Skiter ni i eget bo så får ni väl reda upp efter förmåga.

Man kan inte begära att alla lägger sig in i detaljerna! Allra minst att plöja igenom tekniska dokument. För tillfället resonerar jag just på det här jävligt korthuggna sättet. Vill ni ha mitt stöd för era tankar så krävs det nog lite bättre argument än att "läs spexen så förstår du nog". Tänk om jag missar poängen, gör en felbedömning och hamnar att ta ansvar för det. Nä du! Den kompetensen har inte att jag. Såna risker tar jag inte.

Ja, var blev vi? Du skrev visst "... Borde inte gå att göra falska certifikat..." Och jag bad om ett tydligare svar: ja eller nej. Hymla inte! Så jag frågar igen: Går du i godo för att HSTS stoppar falska certifikat?

Det handlar faktiskt om tro - om tro-värdighet.

Johanh
Medlem
# Skrivet: 7 Feb 2015 23:52 - Editerad av: Johanh
Svara 


Skiter ni i eget bo

Ursäkta, men det är inte mitt bo.

Jag känner inte alls att jag har ansvar för något av det du räknar upp här. Jag trodde den här tråden var en diskussion om att förbättra saker och ting, och att lära sig vad man kan göra för att undvika MITM-attacker. Inte att ställa någon vid skampålen (tja, förutom bankerna och de som utvecklat tekniken om jag tolkar dig rätt). Ursäkta om jag på något vis har trampat på din agenda här. Jag har också lärt mig flera saker här, bl.a. just om HSTS.

Går du i godo för att HSTS stoppar falska certifikat?

Jag kan inte gå i godo, jag har inte gjort de där specsen. Jag förstår inte din aggressiva ton här. Du riktar dig nog till fel person. Om du frågar snällt så ska jag försöka forska lite till i saken (det kommer jag säkert ändå att göra). Det är ett intressant område och högaktuellt. Men försök inte ställa mig till svars för något som jag inte har ansvar för!

Om du kollar lite vad vi skrev, så är det så, att då man första gången kontaktar en sida i webbläsaren med http, så är man ALLTID sårbar för MITM-attacker (om andra förutsättningar för MITM uppfylls). Och då hjälper inga världens certifikat eller HSTS eftersom de inte används då! Det kan man inte beskylla certifikaten eller HSTS för! Låset på husdörren hindrar inte tjuvarna att ta sig in i trädgården. Typ. Det finns inte så mycket botemedel mot detta, utom det som redan tidigare listats, nämligen genom att försäkra sig om att ingen befinner sig på samma layer 2, hårdkoda ARP-cache, dyra IDS:ar som skyddar nätet, VPN, IPSEC osv.

Men observera! Google och Mozilla har en s.k. "preloaded HSTS list" i sina webbläsare. Denna lista innehåller sidor som har verifierat sig som HSTS-kompatibla. Om du surfar till en sida som finns i listan, så kommer webbläsaren automatiskt att använda HTTPS också första gången du surfar till en sådan sida. Då används HSTS direkt och då kan inte en MITM-attack göras. Man kan begära att bli tillagd i Google Chromes lista här: https://hstspreload.appspot.com/ Eftersom Mozilla Firefox använder delvis samma lista, så torde man komma med i Firefox lista också (känner inte till detaljerna).

Edit: här är den nuvarande listan för Chromium/Chrome: https://code.google.com/p/chromium/codesearch#chro mium/src/net/http/transport_security_state_static. json

Edit 2: Hoppfullt att några .fi domäner också finns i listan, bl.a. skogsbruket.fi! Men inga banker. Skäms banker! Man kan känna sig säkrare på en simpel skogsbrukstidning än en bank i Finland! Men skogen är ju det gröna guldet förstås, så det ligger väl en större sanning där också... Så nu är det bara att börja surfa på https://www.skogsbruket.fi för det är en av de få sidor i Finland där man är skyddad mot MITM-attacker

Johanh
Medlem
# Skrivet: 8 Feb 2015 00:43
Svara 


Kom nu ihåg att HSTS inte är lösningen på ALLA problem (ingen har påstått det heller), även om det (tillsammans med "preloaded lists") förhindrar EN sorts attack (SSL-hijacking).

T.ex. själva TLS kan vara sårbart via BEAST eller dylikt. Och det är ju en helt annat slags problem som behöver andra lösningar.

Inte har ju samhället EN typ av lösning för att förhindra alla stuginbrott heller. Det är nog så att det måste till många slags lösningar för att göra säkerheten bättre. Och på nätet spelar kryptering en stor roll.

Guje
Medlem
# Skrivet: 8 Feb 2015 13:21 - Editerad av: Guje
Svara 


Nå, jag undrade nu bara hur allvarligt du ställer dig bakom HSTS. I ett tidigare inlägg valde jag faktiskt att lita på ditt omdöme.

Jag tackar för ditt tydliga svar: "...Ursäkta, men det är inte mitt bo. ... försök inte ställa mig till svars för något som jag inte har ansvar för! ..."

Ditt förslag att bankerna absolut måste ta HSTS i bruk, var det lika allvarligt menat? Att, som du skriver: "Skäms banker! Man kan känna sig säkrare på en simpel skogsbrukstidning än en bank i Finland! ". Det förslaget och texten är väl ändå dina? Och dem tar du förstås ansvar för?

Ohjälpligt blir nog HSTS samtidigt din baby. Om du vill det eller inte. Knacka på hos banken bara och fråga om dom vill ha en låda det står HSTS på. Glöm inte askarna med tillbehören från både Firefox och Google! Innehållet samma, men formatet olika. Månne inte banken då frågar: "Vad har du i DINA lådor"?

Skriv gärna också en varningslapp på lådan: GÄLLER INTE DEN TYP AV MITM-ATTCKER CAIN SYSSLAR MED.
I HSTS-spexen står det nämligen:

14.8
....For example, the attacker could first convince users of a victim web
application (which is protected by HSTS Policy) to install the
attacker's version of a root CA certificate purporting (falsely) to
represent the CA of the victim web application. ...
... This type of attack leverages vectors that are outside of the scope
of HSTS.
https://tools.ietf.org/html/rfc6797

Visst finns det rapporter om biverknigar:

... The impact is that it's possible for a site to track you even if you choose to use "incognito" or "private" browsing features in an effort to avoid such tracking.
... A notable exception is Internet Explorer which has no support for HSTS (although it is in development at the time of writing) so it's not vulnerable to this technique.

http://www.radicalresearch.co.uk/lab/hstssupercook ies


Vad nyttan sist och slutligen är för dem som ENBART kör httpS från böjan tål att tänkas på. Folk kommer ju till sådana websidor direkt och inte via HTTP som är HSTS:s specialitet.

Vad 100 000 flugor käkar, köper jag inte sådär på direkten alltså.



Fler goda förlsag som påstås hålla Cain borta?

. 1 . 2 . 3 . >>
Ditt svar
Bold Style  Italic Style  Underlined Style  Image Link  URL Link     :) ;) :-p :-( :up: :down: :talk: :confused :cool: :sealed: :noway: ... Använd inte smilies

Kill your darlings


» Namn  » Lösenord 
Only registered users can post here. Enter your login/password correctly before posting a message, or register first.