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

Finlandssvenskt fiberforum / Säkerhet på nätet / Bankattacker
<< . 1 . 2 . 3 . >>
Författare Meddelande
Guje
Medlem
# Skrivet: 8 Feb 2015 13:49
Svara 


Aj, jo, rahslkog kastade också in en kod, koden RC4. Även han på väg till banken med en låda.

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

Hoppas du väljer att varna dem för RC4 och inte rekommendera såna lösningar:

http://threatpost.com/microsoft-warns-customers-aw ay-from-sha-1-and-rc4/102902

(Om det nu var den RC4:an du avsåg? )

Guje
Medlem
# Skrivet: 8 Feb 2015 18:42
Svara 


Hoppsan!

Jag läste igenom HSTS spexen och fann en intressant sak. Jag hoppas innerligt jag har fel, men inte ser det riktigt bra ut.

Antag att en Cain-släkting lyckas kränga in ett falskt certifikat för www.banken.net i kundens dator. (Jo, sånt händer! ;)
HSTS tipsar tom. själv om hur man eventuellt kan gå tillväga och är något som HSTS inte bryr sig om att stoppa. )

Denna Cain-filur meddelar sedan att www.banken.net använder HSTS och låser adressen till det fejkade certifikatet, med egenskapen "Lås aldrig upp". Sen försvinner han ut i bitrymden.

När kunden nästa gång försöker öppna www.banken.net kommer han inte in. Därför att det riktiga certifikatet inte stämmer med det falska.
Använder kunden t.ex. Chrome kommer hon aldrig till sin bank. Låset stryks först då låstiden gått ut, och det sker ju ALDRIG. (Ok, jo, man skall kunna plocka bort låset, men den finessen skall vara undangömd)

Detta sker oberoende om www.banken.net själv använder HSTS eller inte. Den som kör vanlig HTTP stoppas också eftersom HSTS tvingar över till HTTPS.

Snygg DOS-attack. Spåren efter Cain-släkten kan sökas i stjärnorna.


Snälla Johanh, nån, visa att jag har fel!



Det var i dom här paragraferna jag fastnade:

https://tools.ietf.org/html/rfc6797#section-8.4


8.4. Errors in Secure Transport Establishment


When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 12 ("User Agent Implementation Advice"))
if there are any errors, whether "warning" or "fatal" or any other
error level, with the underlying secure transport.
For example, this
includes any errors found in certificate validity checking that UAs
employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
as via TLS server identity checking [RFC6125].


8.6. Missing Strict-Transport-Security Response Header Field


If a UA receives HTTP responses from a Known HSTS Host over a secure
channel but the responses are missing the STS header field, the UA
MUST continue to treat the host as a Known HSTS Host until the
max-age value for the knowledge of that Known HSTS Host is reached
.
Note that the max-age value could be effectively infinite for a given
Known HSTS Host. For example, this would be the case if the Known
HSTS Host is part of a pre-configured list that is implemented such
that the list entries never "age out".

12.5. HSTS Policy Deletion

HSTS Policy deletion is the ability to delete a UA's cached HSTS
Policy on a per-HSTS Host basis.

NOTE: Adding such a feature should be done very carefully in both
the user interface and security senses. Deleting a cache
entry for a Known HSTS Host should be a very deliberate and
well-considered act -- it shouldn't be something that users
get used to doing as a matter of course: e.g., just "clicking
through" in order to get work done. Also, implementations
need to guard against allowing an attacker to inject code,
e.g., ECMAscript, into the UA that silently and
programmatically removes entries from the UA's cache of Known
HSTS Hosts.

Johanh
Medlem
# Skrivet: 8 Feb 2015 20:08 - Editerad av: Johanh
Svara 


Du kallar det DOS-attack, men det är ju precis hela nyttan med HSTS; att anslutningen till sidan stoppas om något felaktigt förekommer. Specsen har ju utformats exakt för att detta skall ske. Man skall inte komma åt sidan med felaktigt certifikat. Vill du eller vill du inte att en SSL-hijacking skall förhindras? Du kan inte både äta kakan och ha den kvar.

När kunden nästa gång försöker öppna www.banken.net kommer han inte in. Därför att det riktiga certifikatet inte stämmer med det falska.

Hur menar du nu? Om inte MITM-attacken pågår längre, så finns det falska certifikatet inte med i bilden längre. Då är det ju det riktiga certifikatet som skickas från den riktiga servern.

Vill man nödvändigtvis radera HSTS-data för en viss webbplats är det inte värre i Firefox än att man stänger sidan först, öppnar Historik i sidofältet, klickar på sidan och väljer "Ta bort all historik för webbplatsen". Detta gäller då inte förstås för "preload" listan. Orsaken till varför man skulle vilja göra det är kanske om en webbsida tagit bort SSL, eller ändrat sitt certifikat av någon orsak, så att det inte mera är kompatibelt med tidigare information (lite långsökt, men borde i teorin kunna hända t.ex. vid serverbyte på en intern webbplats där man använder egna self-signed certifikat, eller vid utveckling om man testar HSTS på sin server).

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


Skall försöka förklara mig en gång till.

Det är SKURKENS certifikat som ligger i HSTS-registret och som stoppar accessen till den riktiga sidan. Det var skurken som satte in en HSTS-record i Firefox. Tvärt emot som det skulle gå. HSTS stoppar den riktiga www.banken.net!

Johanh
Medlem
# Skrivet: 9 Feb 2015 00:09
Svara 


HSTS sparar inget certifikat.

Guje
Medlem
# Skrivet: 9 Feb 2015 09:28 - Editerad av: Guje
Svara 


Tack för det!

Så står det ju i 8.1.1. Bara tre uppgifter får sparas: www-adressen, avslutningstiden och om subdomänerna också skall räknas in. Inget får ändras efter detta.
https://tools.ietf.org/html/rfc6797#section-8.1.1

Därefter påtvingar HSTS bruket av HTTPS tills tiden gått ut.

Browsern släpper alltså fram användaren till web-adressen alltid om certifikatet blir godkänt. Även ett fejkat sådant, eller hur?

Och om någon manuellt fört in ett självsignerat certifikat så godkänns även det.

Är resonemanget korrekt så här långt?

Johanh
Medlem
# Skrivet: 9 Feb 2015 14:59
Svara 


Browsern släpper alltså fram användaren till web-adressen alltid om certifikatet blir godkänt. Även ett fejkat sådant, eller hur?

Och om någon manuellt fört in ett självsignerat certifikat så godkänns även det.

Är resonemanget korrekt så här långt?


Det låter i alla fall bättre. Men var noggrann med hur du beskriver det och med vilka termer ("Browsern släpper fram användare...", "någon fört in ett självsignerat certifikat" etc). Hela SSL/TLS bygger på att användaren/webbläsaren litar på CA från certifikatet man blir erbjuden _av servern_. Det görs på basen av CA (root certet finns färdigt i användarens maskin) eller om man själv godkänner ett okänt certifikat.

Guje
Medlem
# Skrivet: 9 Feb 2015 15:32
Svara 


Tack för det.

Nå, nog är det ju browsern som släpper fram användaren till web-adressen. Vem annars? I vissa fall öppnar den enbart om användaren prompt vill ha det så.

Och, som du själv skriver, om man själv godkänner ett certifikat, känt eller okänt, så är det certifikatet OK därefter. Antagligen godkänner HSTS det också, trots att det är självsignerat (Det här vet jag inte än, men så tror jag). Är PC:n nersölad med all världens maskar kan väl nån av dem slinka in ett certifikat som också blir OK. Eller så luras man bara till att godkänna ett certifikat. Då har ju någon faktiskt satt in ett självsignerat certifikat.

Angående CA:n så menar jag också att SSL/TLS bygger på att en tredje part, kallad CA, kollar det certifikat som servern (t.ex. banken) skickar.

Men om Cain har hoppat in i bankens roll och presenterar ett helt eget giltigt certifikat, så nog får browsern grönt ljus från CA:n, precis som för alla andra giltiga cert. Och då släpper browsern fram användaren till - som han tror - banken. Skillnaden denna gång är att browsern inte varnar längre och att hänglåset visar att trafiken är OK. Men i andra ändan sitter Cain.

Kommer du till samma sak?

Johanh
Medlem
# Skrivet: 9 Feb 2015 18:18
Svara 


Det är väl en upprepning av det vi tidigare sagt. Endast användaren kan märka detta om han granskar webbadressen och certifikatet noggrannt (CN-fältet), eller som vi tidigare kommit fram till, HSTS med en sida i preload listan (eller från ett tidigare besök på sidan) skulle också förhindra det. Man kan visserligen bli utsatt för ett falskt certifikat, men om både webbaddressen och certifikatet ser äkta ut, så har man nog blivit hackad av århundradets hackare, eller någon har gjort intrång hos en CA.

Har någon gjort intrång och stulit någon CA:s private keys, så kan man för all del förfalska vilka certifikat man vill, och då plösligt hjälper inte heller HSTS längre. Men då står det nog redan på alla tekniska nyhetssidor på nätet om saken. Det hände sig 2011 att en CA vid namn DigiNotar blev hackad och hundratals falska certifikat blev gjorda, bl.a. i googles namn. Dessutom var firman tyst en månad om saken. Då det blev känt, tog nederländska staten över dess system och dess root-certifikat blev utsparkat ur alla operativsystem för att få bort de falska certifikaten. Tyvärr slutade ju de äkta certifikaten också att fungera, och trovärdigehten var noll, så DigiNotar blev bankrutt efter en tid.

Men hur långt lönar det sig att diskutera detta? Är man så skicklig så man förfalskar CA i certifikat eller kommer in på andras layer2-nätverk, så kan man lika gärna räkna med att de är inne på datorn också, och plötsligt saknar hela denna diskussion betydelse. Man kan bli rånad på hemvägen från bankomaten också. En klubba i huvudet hjälper inga hemliga koder mot.

För min del tycker jag det mesta blivit sagt i denna tråd om MITM-attacker, om inget nytt framkommer (HSTS var ju ett bra exempel).

Guje
Medlem
# Skrivet: 9 Feb 2015 19:32 - Editerad av: Guje
Svara 


Du har alldeles rätt - det gäller att komma tillräckligt nära slutkunden. Helst i hans omedelbara närhet, kallad layer 2. Det är där dom här hemskheterna kan ske. Som i WiFi och företagsnät och såna ställen, och i hemnätet naturligtvis. Så, att komma i kontakt med någons layer 2 är nog inte alls särskilt svårt, och absolut inte i klass med att förfalska ett CA-certifikat - den jämförelsen köper jag inte.

Ok, jag får väl filosofera vidare ensam då. Du anar säkert att knäckebrö och vatten hägrar i horisonten. Men, tack nu så här långt iaf! Du orkade ju mycket längre än MarkusI, trots snålblåsten där i ett skede. Så man lär sig segla.


-----------
Århundrades hackare...nåh... det handlar ju inte om att hacka en CA precis. Lite luras med certifikat och eventuellt några IP-adresser bara.

Jag snappade upp en grej dom skrev om på HSTS-sidan och lät Google Översättaren kryptera texten så den inte blir helt uppenbar för en massa wannabees.
Svampodlaren i mig kan dessutom berätta att Cain&Abel saknar "DNS cache poisoning attack". Försök googla! Finns Ingenting här.

Citerar bara och menar ingenting:

14,8. Bogus rotcertifikatutfärdarcertifikat Phish plus DNS cache poisoning attack
https://tools.ietf.org/html/rfc6797#section-14.8


En angripare kan tänkas få användarnas inloggningsuppgifter
tillhör en offer HSTS skyddat webbapplikation via en falsk rot
CA-certifikat phish plus DNS cache poisoning attack.

Exempelvis skulle angriparen först övertyga användare av ett offer bana
ansökan (som skyddas av HSTS Policy) för att installera
angriparens version av en rotcertifikatutfärdarcertifikat utger (falskt) till
representera CA offrets webbapplikation. Detta kan vara
koms genom att skicka användarna en phishing e-postmeddelande med en
länk till ett sådant intyg, som sina webbläsare kan erbjuda installation
Om du klickar på.

Sedan, om angriparen kan utföra en attack på användarnas DNS
servrar, (t.ex. via cache poisoning) och slå på HSTS Policy för
deras falska webbapplikation, skulle de drabbade användarnas webbläsare tillgång
angriparens webbapplikation i stället den legitima webben
ansökan.

Denna typ av attack utnyttjar vektorer som ligger utanför räckvidden
av HSTS. Däremot kan möjligheten att sådana hot mildras
genom att i en webbapplikation övergripande strategi driftsättning
lämplig sysselsättning, förutom HSTS, säkerhetsanläggningar
såsom DNS Security Extensions [RFC4033], plus tekniker för att blockera
e phishing och falska certifikat injektion.

Guje
Medlem
# Skrivet: 10 Feb 2015 08:53
Svara 


Men, varför hymla?

Här är en länk som på ett ganska bra sätt berättar om flera sätt att utföra de här attackerna.

http://www.cs.du.edu/~ramki/downloads/papers/cloak Preprint.pdf

Läs speciellt stycket 3.3 MITM Attack on SSL Using Bogus Certificates
om certifikat-kedjor och hur man med sslsniff kan sticka in sig själv som en CA. Det betyder att det berömda hänglåset dyker upp i browsern och att varningarna försvinner. Helt säker site alltså, men skurken är ändå på linjen.

Den svagaste länken är mänskan - vilket detta papper också visar. Så, därför är det nog på tiden att bankerna börjar axla sitt ansvar och PÅ RIKTIGT kolla vem som är i andra ända. Nu ligger HELA ANSVARET på kunderna då någon startar upp sin MITM-attack.

MarkusI
Medlem
# Skrivet: 10 Feb 2015 13:40
Svara 


Guje: Jag hade redan sagt allt som jag behövde säga och såg inte att diskussionen kunde ta vidare, kreativa, vägar.

Har du kompromissat någon person eller dennes dator/annan apparat, har säkerheten redan flugit bort.

Om exploiten börjar med "Step1: Become administrator" eller motsvarande så är det inte en exploit.

Nisse
Medlem
# Skrivet: 10 Feb 2015 21:13
Svara 


Enligt krypteringsteknikens grundsats så borde HELA nätet ses som fientligt område - inklusive den egna maskinen. Därför borde pålitliga nycklar finnas UTANFÖR nätet. Jag har till exempel en dosa från Nordea i Sverige som jag sätter in mitt bankkort i. Därefter får jag koder från Nordea Sverige och svarar med koder från dosan (som innehåller Nordeas krypteringsalgoritm.

Det betyder att alla certifikat ses som fientliga och osäkra då de kommer från nätet.

Guje
Medlem
# Skrivet: 10 Feb 2015 23:05 - Editerad av: Guje
Svara 


En annan grundsats inom säkerhetstänket är att berätta hur säkerheten i detalj är designad. Där skall inte finnas några "svarta lådor" som gömmer nån hemlighet. TLS är ett väl dokumenterat säkerhetssystem. Fast man vet hur det är gjort så kommer man inte in. Motsatsen, den man först kommer att tänka på, är security by obscurity. Då är designen hemlig. Man berättar helt enkelt inte hur systemet är gjort, för annars kommer man in. Lönnfack, och hur de öppnas är ett klassiskt exempel.

Båda funkar, men Sequrity by Design är det sätt som ändå funkar bäst i längden. Sequrity by obscurity funkar en tid, tills Tin-Tin eller Indiana Jones dyker upp.

Nisses dosa från Nordea i Sverige bör därför betraktas som ett fall för Tin-Tin, tills Nordea berättar vad där finns och hur den funkar. I säkerhetssammanhang är det bäst att köra worst case. Kallas även "försiktighet". Då förvärrar man inte situationen, ifall dosan sen också läser bankkortet på sitt alldeles eget lilla sätt.

Vem minns inte bankomat-tricket i Hesa 1999 då två skurkar monterade sin egen läsapparat i en bankomat. Tipset hade de fått från en deckare med en bankomat på Sergels torg i Stockholm.
http://www.dn.se/arkiv/nyheter/deckare-gav-ide-til l-kupp


Förstår jag MarkusI rätt så anser du att bankkunderna som stack in sitt kreditkort i den falska automaten får skylla sig själva eftersom det inte var någon "exploit". De gav ju "administratörsrättigheter" åt en apparat som skurkarna redan "kompromissat".

Rättsväsendet hade en annan syn på saken. Bankkunderna var offer och ingalunda skyldiga till sitt eget öde. Även i datorsäkerhets sammanhang brukar sådana kallas för "offer" som råkar ut för skurkar.

Jag tycker att du skuldbelägger offren om de t.ex. med sin Windows + Internet Explorer hamnar ut för en MITM-attack. Har jag fel?

Nisse
Medlem
# Skrivet: 10 Feb 2015 23:12
Svara 


Man kanske kunde dela litet på ansvaret. Den som kör med gamla system fulla av säkerhetshål kunde ta litet av ansvaret i alla fall. Och speciellt de som bara kopplar en WLAN-burk till nätet utan den minsta säkerhet.

Å andra sidan anser jag det vara åtminstone moraliskt kriminellt att fabriksinställningarna är sådana att de är fullständigt öppna. Man kan lätt hindra folk att komma ut på nätet innan de ändrat lösenordet för admin åtminstone.

Guje
Medlem
# Skrivet: 11 Feb 2015 08:48 - Editerad av: Guje
Svara 


Jag tror det finns av alla sorter. De som fullständigt struntar i säkerheten - "jag har inga hemligheter" typerna och de som inte ansluter sig till Internet "därför att då stjäl någon deras identitet" typerna.

En sund blandning av att själv ta ansvar och att vara medveten om riskerna är ett bra koncept. Uppenbara risker, som att hålla alla dörrar öppna då komplicerade apparater första gången ansluts till nätet (t.ex. WiFi/fiber-modemet), borde förbjudas i lag! För all del, kunden kommer själv snabbt igång, men det gör även de mörkare elementen på nätet.

Vad jag vill säga är att fabriken och tjänsteleverantörerna också måste axla sitt ansvar och ge kunderna EN REJÄL CHANS att skydda sig. Vilket jag menar att bankerna i dagens Finland inte gör. Engångs-lösenord är security by obscurity. Vet man hur det är designat så kommer man in. Först en ARP-spoofning och på den nåt sätt att lura banken till att tro att kunden sitter i andra ändan. Kommer MITM-skurken så långt har kunden INGEN CHANS att skydda sig. Här hjälper inga operativsystem, antivirus-skydd, brandmurar och uppdaterare datorer längre. Att hålla lösenorden skilt från alla andra koder är ett skämt i det skedet då alla era hemliga koder dyker upp på skurkens skärms i den takt kunden matar in dem.

Täpp till hålet, banker! Det är ni som designat säkerheten som era kunder måste använda!

Guje
Medlem
# Skrivet: 12 Feb 2015 11:17
Svara 


Oj, ordval i fel ordning i förra inlägget.

Jag skrev: "Först en ARP-spoofning och på den nåt sätt att lura banken till att tro att kunden sitter i andra ändan."

Bör vara:

"Först en ARP-spoofning och på den nåt sätt att lura kunden till att godkänna den förfalskade banken i andra ändan."

Banken är ju redan lurad.

Nisse
Medlem
# Skrivet: 13 Feb 2015 10:43
Svara 


Det var en bra artikel i Östnyland i dag med Guje: "Bristande webbsäkerhet för bankkunden". Ett helt uppslag (där en bild tog 60 % ...). Men det kom i alla fall tydligt fram att det finns problem. Bankerna påstod att det inte fanns skäl till oro. Vad skulle de annat säja ? Men inte ger det någon större tilltro till säkerheten då Guje med ett enkelt nedladdat program efter 20 minuter kunde följa med vad en bankkund skrev: koder, kontonummer - allt.

Även om banken betalar kompensation så undrar man vart pengarna försvinner ? Betalar bankerna terroristernas och skurkarnas verksamhet ?

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


Artikeln var i Västis också, men där var jag "Bromarvbo"

Lite som väntat: F-Secure och Bankerna försöker bortförklara med att de känner till saken och att den är marginell.

MarkusI tyckte visst att debatten inte har varit tillräckligt kreativ: Inte får jag alls fram kundens koder om kunden följer bankens certifikat-direktiv. Sant MarkusI - så är det!

Hittills har debatten enbart handlat om att lura kunden på ett förfalskat certifikat. Enbart i syfte att kunna öppna det som kunden skickar åt banken. Men om vi struntar i det?

Vad händer om vi helt enkelt skickar det krypterade materialet jämte äkta certifikat vidare till kunden. Hänglåsen visas och den som vill kolla äktheten kan gott göra det. Äkta vara! Kunden öppnar krypteringen med bankens publika nyckel, skriver in sina lösenord och transaktioner, krypterar tillbaks sitt material med bankens publika nyckel, och returnera svaret till banken.

När meddelandet går via Cains kusin så kan han inte öppna det eftersom det bara är banken som har den andra nyckeln - den hemliga. Banken öppnar med sin nyckel, skriver ett svar, och krypterar texten med sin hemliga nyckel. Banksvaret går att öppna enbart med bankens publika nyckel som finns hos alla bankkunder, så även hos Cain och hans kusin. Först skickar skurkkusinen bankens svar i original till kunden för att inte oroa henne. Sen...blir Cain-släktingen kreativ ... och öppnar bankens svar med den publika nyckeln som alla har.

Det betyder att skurken sitter och avläser allt vad banken skickar åt kunden. Det här uppfyller garanterat inte banksekretessen. I kundens ända är allt ok och alla certifikat är i sin ordning. Men, banken skickar ändå allt sitt skyddade material rätt i händerna på skurken.

I tidningarna säger både F-Secure och banken att de nog vet om det här! Och därför uppmanar dom bankkunderna är följa säkerhetsdirektiven. Man häpnar!
Som slutknorr på det hela tar de till polis Didos logik: Eftersom de här hålet är så litet är tjuvarnas antal också litet.


MarkusI och Johanh, blir debatten mer konstruktiv om vi vinklar saken så här? Så här är skurken helt osynlig för både banken och kunden. Det är dessutom ytterst svårt att logga honom. Så vänta er inga rapporter över skedda intrång.

Johanh
Medlem
# Skrivet: 13 Feb 2015 17:22
Svara 


Scenariot är nog samma som vi nämnt tidigare i tråden. Inte ser jag något nytt i ditt förslag. Men det går inte att "skicka vidare" serverns certifikat. Man kan inte stjäla ett certifikat på det viset. Men med en MITM-proxy (typ med något sånt här program kanske? https://mitmproxy.org/) kan du generera ett nytt certifikat med samma CN och skicka vidare det åt kunden. Men det börjar bli väldigt avancerade grejer. Det är helt riktigt allt det du säger, men jag tycker proportionerna blir lite uppblåsta. Det finns massor med andra säkerhetsbrister vi borde reagera minst lika mycket (och mer) på. Som F-secure säger, så är det nog på annat håll de stora riskerna finns för tillfället.

Och varför upprepa grundproblemet gång på gång istället för att föreslå lösningar? Det ÄR i alla fall en mycket känd säkerhetsbrist i data- och nätverkssammanhang. Man kunde ju uppmana banker att ta i bruk HSTS och uppmana folk att använda Chrome och Firefox. Men jag antar att de nog är medvetna om saken och tar i bruk det så småningom, inte är de hur dumma som helst de som jobbar med datasäkerheten på banker.

Jag tyckte det var dåligt att artikeln inte nämnde något (eller mycket litet) om hur kunderna kan skydda sig. Dvs. kontrollera certifikat och address, logga helst in på banken hemifrån (fast nät) och inte på en okänd WIFI-accesspunkt m.m.

Guje
Medlem
# Skrivet: 13 Feb 2015 17:51
Svara 


Johanh: "Men det går inte att "skicka vidare" serverns certifikat. "

Det låter intressant. Varför går det inte? ... byte för byte som kommer in från banken går vidare till kunden.

Johanh
Medlem
# Skrivet: 13 Feb 2015 18:58
Svara 


Nog kan du skicka trafiken vidare, men inte avlyssnar du den då... Men nu går vi igen tillbaka till grunderna för hur TLS/SSL fungerar som vi redan avhandlat många gånger...

Nisse
Medlem
# Skrivet: 13 Feb 2015 19:24
Svara 


Jag undrar hur mobilbankernas säkerhet fungerar. Det blir allt vanligare med smarttelefoner i betalningarna. Personligen ställer jag mej tvivlande till säkerheten i dessa.

Guje
Medlem
# Skrivet: 13 Feb 2015 19:45
Svara 


Johanh frågar vidare: "Och varför upprepa grundproblemet gång på gång istället för att föreslå lösningar? "

Svar: För n:te gången: Det finns inga lösningar!

1) En ARP-attack görs på layer 2. Därför kan man inte göra nånting med lösningar på t.ex. layer 7 där Firefox finns. HTTP ligger på layer 5. Den som känner till det, förstår att t.ex. ett operativsystem INTE kan fixa saken. Du måste jobba med en lösning på layer 2, ARP-protokollet. Ändrar man ARP-standarden så måste alla burkar och nätkort ändras. Elementär nätteknik.

2) Så länge banken envisas med att skicka ut sina tecken, i första hand till en skurk, kan kunden inte göra ett smack. Om alla hänglås är på plats och alla certifikat är kollade så ser kunden ingen skillnad. Vilka direktiv tycker du man ytterligare skall ge åt kunden så han kan varnas? Ingenting av det som du hittills listat upp hjälper. Kanske det var därför tidningen lät bli att tramsa strunt. Vad vet jag?


PS.
Johanh: "Nog kan du skicka trafiken vidare, men inte avlyssnar du den då... "

I vilka världar lever du? Tar jag ett tecken ur ett "rör" så kan jag skicka ut det i två rör. Det ena går till kunden och i det andra röret avkrypterar jag bankens text med deras egen publika nyckel. Precis på samma sätt som kunden just då gör i sin egen browser. Är jag lat så skickar jag tecknen in i Firefox så får jag den både avkrypterad och renderad på en gång. Bra övningsuppgift för en skolelev som skall lära sig hur en readerwriter-funktion programmeras.

Guje
Medlem
# Skrivet: 13 Feb 2015 19:54
Svara 


Nisse: "Jag undrar hur mobilbankernas säkerhet fungerar"

Det gör jag också. Är det security by obscurity, så som Andelsbanken sa i tidningen, eller är de gjort med konventionella väl dokumenterade modeller.

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


I kväll gjorde jag ett litet test i vårt byanät.

Eftersom jag har admin rättigheter tog jag bort layer 2 låset för just min fiberanslutning. Därefter låg jag i samma layer 2 där mina andra bybor ansluter till vårt fibernätet. Dvs. i nivå med den layer 2 som byswitchen jobbar på.

När jag pingade en granne som ligger flera km från vårt hus så dök hans MAC-adress upp i min ARP-tabell. Något den aldrig får göra, men som den gör pga. min felkonfigurering. Det betyder att jag kan kapa grannens trafik att gå från dem -> via mej -> till vår gemensamma router.

MITM-attacken skriver alltså om MAC-adressen i grannes mediekonverter på WAN-utsidan och styr därefter all trafik via mej. Då förstår tom. MarkusI och Johanh att någon Linux eller Firefox inne i grannens nät inte kan stoppa min attack. Grannen vet inte ens om den. Jag sitter ju UTANFÖR deras nät, i en annan layer 2 där grannens trafik bara råkar flyta igenom.

Och då får den här attacken plötsligt andra dimensioner. Det är sas. inte längre bara inom hemmets väggar en sån attack är möjlig - den är möjlig även utanför. Förutsatt att skurken kan tas sig dit. Och det gör han tex om man i ett höghus delar på samma Internet med en switch utan layer 2 lås.

Exakt vad menar Johanh som säger att det här problemet egentligen är litet. Är du säker på att alla nät som folk ansluter sitt hem till har layer 2 låset på plats och också rätt konfigurerat?

------
Om jag testade Cain i vårt byanät? Aldrig i livet - det är olagligt! Snabbt konfigurerade jag mig tillbaks igen.

Guje
Medlem
# Skrivet: 14 Feb 2015 12:13
Svara 


Eftersom ARP-attacken forfarande verkar vara så okänd, även bland fackfolk som påstår sig veta vad det handlar om, så är det hög tid att idka lite upplysning. Se nedan de främsta missuppfattningarna och fördomarna. Jag håller fullständigt med. Texten skrevs redan 2007, och sedan dess har det inte hänt särskilt mycket.

1.You need very advanced and complicated tools to perform ARP cache poisoning

2.ARP cache poisoning only works against hosts of specific operating systems (OS)

3.You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.

4.An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN

5.Some switches hung when you send one of those fake ARP replies through

Läs motiveringarna I länken nedan. Speciellt punkt 2 för er som går omkring och lurar folk med att Linux och Firefox på nåt sätt skulle vara "bättre".
Punkt 3 var det jag testade i går kväll. Såg inte särskilt bättre ut genom en av mina VPN till Danmark heller.

http://www.radajo.com/2007/03/common-misconception s-about-arp-cache.html

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


Märklig tystnad.

Här har vi eventuellt den största och farligaste formen av intrångsvektor på hela nätet och vårt forum är tyst. Hela Finland är tyst.

ARP attacken är extremt lätt att utföra och så gott som omöjlig att upptäcka. Och den är varken okänd eller marginell, som en del försöker få den till.

Google gav mig över 100 000 träffar på "How to arp spoofing" och på YouTube sprids budskapet av unga röster som vädrar morgonluft.
https://www.youtube.com/watch?v=0JdeZ_3z490 .

Upplev speciellt de sista sekunderna där Wannabee berättar vad man kan göra "just for fun" + det där småflinet i slutet. Det skickar jag till F-Secure och Andelsbanken.

Guje
Medlem
# Skrivet: 15 Feb 2015 12:48
Svara 


Nisse undrade i ett tidigare inlägg: "Även om banken betalar kompensation så undrar man vart pengarna försvinner ? Betalar bankerna terroristernas och skurkarnas verksamhet ?"

Jag undrar också. På senaste tid har tom. huvuden rullat så deras "verksamhet" har tagit former ingen i sin vildaste fantasi nånsin hade trott.

Johanh
Medlem
# Skrivet: 15 Feb 2015 16:47
Svara 


Här har det stulits hundratals miljoner av banker på högre layer. http://www.nytimes.com/2015/02/15/world/bank-hacke rs-steal-millions-via-malware.html?_r=0

En sådan här nyhet gör ju nog att man undrar lite över ditt påstående om ARP-attacker som den största och allvarligaste intrångsvektorn. Här får du nog motivera litet. Har du några konkreta bevis eller misstankar om var MITM-attackerna sker? I byanäten ska det ju inte kunna hända om de är byggda enligt kommunikationsverkets föreskrifter.

Guje
Medlem
# Skrivet: 15 Feb 2015 18:34
Svara 


Ja, det har du rätt i. Det var en värsting. Tur att det inte sker många sådana - får man hoppas åtminstone. Här var svagaste länken igen en gång banken. Undrar till vad dom miljonerna användes till?

"The silence around the investigation appears motivated in part by the reluctance of banks to concede that their systems were so easily penetrated, and in part by the fact that the attacks appear to be continuing.

Det finns två ställen en MITM-attack kan göras och det är i ändorna, antingen i banken eller så i det lokala nätet. Där nån stans "mitt emellan" är en attack osannolik och ibland tom helt omöjlig. Dels löper trafiken inne i operatörernas väl skyddade nät och dels flyttas paketen inte alltid längs samma rutt, bl.a. pga. load balancing. Men i ändorna möts datapaketen igen och byggs upp till hela texter.

Precis som du själv också skriver är byanäten säkra om de är byggda enligt föreskrifterna. Så, skall en MITM-attack ske så är det i ändorna - antingen hos banken eller så i LAN-miljön. Då är det i ändorna skyddsmekanismerna skall sättas in, inte sant? Nu är jag helt övertygad om att bankerna i Finland nog skyddar sig i sin ända. Återstår den andra ändan - kundens ända. Och där kan det krylla av all världens ohyra. Bara EN av dessa datorer behöver ha ARP-virus så kan den avlyssna all trafik i LAN-nätet - utan att de andra märker av det. Därför menar jag att ARP-attacken är en av de värsta hoten. Den är osynlig för t.ex. F-Secure, så vänta dig inga rapporter om inräknade attacker precis. Därför är den också ett alldeles utmärkt sätt att starta en avläsning av t.ex. banktrafiken på. Eller till att utföra en DOS.

Varför banken bara fortsätter att skicka hemliga bankuppgifter in i en sådan miljö, utan att säkerställa om kunden är i andra ändan förstår jag bara inte. Förstår nån det?

Guje
Medlem
# Skrivet: 16 Feb 2015 11:41
Svara 


Märklig tystnad.

Finns det faktiskt inte andra argument än att "ARP-spoofningen är ett så litet hål och att det är värre på annat håll"?

Själv är jag bara en vanlig programmerare som är tvungen att plöja igenom en massa manualer och verkligen förstå vad där sägs. Men, jag djupdyker inte längre än nödvändigt. Till sist så brukar där alltid finnas nån som kan förklara, så att även jag förstår. Men inte i det här fall, för nu hör jag bara: Bry dig inte om detaljerna. Och så är det tyst.

Problemet ur mitt perspektiv, om vi skall tala om mig, är väl närmast att jag är ute efter att skriva säkra program. Vad är då naturligare än att kopiera den säkerhet som bankerna använder. Och så stöter man på sådana här säkerhetsluckor. Om JAG blir fast för att ha skrivit osäker kod, är det väl mig man hänger. Det ligger alltså lite av självbevarelsedrift i det hela. Jag antar att en del experter nog kan dela ut "goda råd" till höger och vänster utan att behöva ta ansvar för saken. Dom får sin lön ändå. Men, det funkar inte för mig och mitt lilla företag.

Som nätbyggare ser jag också en risk med säkerhetsluckorna. Om det en dag råkar visa sig att en kund faktiskt blir plundrad. Hur bevisar jag att det inte var jag i mitt lilla byanät som felade - speciellt om det är banken som påstår det. Vem tror man på? Mej eller banken?

Finns här faktiskt INGEN som i sak kan säga att jag har fel. Tex. på punkten att man endast behöver bankens publika nyckel för att kunna avkoda deras trafik. För så djupt har jag faktiskt inte dykt i TLS-standarden att jag med säkerhet kan säga att jag har fel. Jag hoppas naturligtvis innerligen att jag har fel. Det skulle lösa ågan att kunden ändå skulle kunna se någon varning på sin skärm. HSTS, jovisst - men i det här fallet skulle den inte hjälpa.

Innan jag är övertygad om just den detaljen kan jag naturligtvis inte heller lova någon säker kryptering med bankernas metod. Men det finns ju andra knep.

MarkusI
Medlem
# Skrivet: 17 Feb 2015 10:58 - Editerad av: MarkusI
Svara 


http://en.wikipedia.org/wiki/Transport_Layer_Secur ity
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellma n_key_exchange

Om du vill så får du försöka bevisa att Diffie-Hellman har fel :)

Edit: Bindesträcket mellan Diffie och Hellman.

rahlskog
Medlem
# Skrivet: 17 Feb 2015 23:33 - Editerad av: rahlskog
Svara 


Jag vet inte var jag ska börja...

Jag börjar förstå varför Nordea tänkte skicka jurister efter dej, det går inte att föra en vettig diskussion om ämnet då du hela tiden förvränger våra ord och försöker göra oss personligt ansvariga för de teknologier som vi refererar till. Vi inte är experter, vi har inga special utbildningar, vi är vanliga personer som har ett intresse inom området. Läs på lite själv, försök förstå de teknologiska och sociala problemen, ingen vill ha säkerhet ifall det hindrar deras Facebook spel.

Säkerhet är inte nånting man bara får sådär, den ska existera i lager, nånstans måste tillförlitet börja.
- Kan du lita på din webläsare?
- Kan du lita på ditt operativsystem?
- Kan du lita på din dator?
- Kan du lita på ditt lokala nät?
- Kan du lita på din router?
- Kan du lita på din ISP?
- Kan du lita CA:n?
- Kan du lita på banken?

HSTS är ett lager i detta system så är också att använda accepterad kryptering utan kända fel, därav min kommentar om RC4 (vad tror du om mej egentligen?). Min fråga skulle vara att varför stöder dom endast RC4 och RSA-SHA1 ciphers, är det nån teknologisk begränsning och har dom nån plan på att uppgradera inom en snar framtid.

Ska fortsätta med länken där du refererar till stycke 3.3 MITM using bogus certificates. Stegen var i princip att köpa ett certifikat för x.com och sen skapa ett subsigned certifikat för op.fi och få det godkänt via kedjan op.fi->x.com->CA, den luckan har täppts igen genom att certifikaten inte tillåter ett sådant steg i kedjan.

Och sen Nisse med sin bankdosa, vad finns månne i den lådan? Problemet med alla svarta lådor är att vi inte vet vad som finns i dem, vi kan bara skaka på den och höra hur det skrammlar innuti och se ifall nånting faller ut. Om Nisse pratar om e-kod så då är det inte bättre än våra tallistor, du kan utföra precis samma attack på den. BankID som är nånting dom verkar hålla på att byta till så låter som en certifikatbaserad lösning, där man kan få certifikatet som en fil eller som ett kort. Efter erfarhenheter med liknande system så kan säga att rekommendationerna är att datorn där du använder kortet inte är kopplad till internet, lite opassande krav med tanke på användningsområdet är internetbank. Dethär är nu ingen fakta bara mina spekulationer baserat på erfarenhet och vad jag kunde hitta på nordeas sidor om hur man använder e-kod och BankID.

Rättsväsendet har nog en åsikt om MITM också, det är precis lika olagligt som att göra falska automater eller slå ner nån på gatan. Så du får lugna dej lite med att hitta på åsikter åt andra.

Hela ditt inlägg om att skicka serverns certifikat så är felaktigt, du har en grundläggande brist i din kunskap om TLS och Public-Key Cryptograpghy (PKC). Man öppnar aldrig nånting med bankens publika nyckel, den används för att kryptera det man vill skicka till banken och banken öppnar med privata nyckeln. Det är dessutom väldigt lite man krypterar med den, för PKC är väldigt dyrt. Det som händer i ClientHello och ServerHello är att man använder PKC till att förhandla fram en symmetrisk kryptering, då främst AES idag, med den symmetrisk krypteringen så skapar en kanal som flyter åt båda hållen och som är mycket mycket lättare att bearbeta.

Kanske du borde sluta dra förhastade slutsatser, ta ett steg tillbaka från din svarta låda (Cain & Abel) och studera de underliggande teknikerna lite närmare så kunde vi framtiden ha en mer givade diskussion.

/Robert

Edit: rättade svengelskan

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


Nä MarkusI, jag har nog inget behov alls att visa nånting över huvud taget angående krypteringsalgoritmerna. Det kvittar liksom. Det räcker med att Cain visar bl.a. Aktias krypterade inloggning i klartext, t.ex. efter att, på sätt eller annat lurat kunden då banken inte upptäckte Cain.

[Client-side-data (74 bytes)]
IDToken1=12345678&IDToken2=helloworld&goto=&enc oded=false&gx_charset=UTF-8

Det handlar ju inte om att knäcka krypteringen utan att hoppa in i rätt sekund när banken frågar vem som är i andra ändan. Det är idententifikationen som attakeras - inte krypteringen.

"In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. ....
A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie–Hellman, such as STS protocol, may be used instead to avoid these types of attacks."


Kunden kan kolla att banken är i andra ändan, MEN - banken kollar inte tillräckligt bra vem som de snackar med. Bankernas system med hemliga engångskoder räcker inte! Det är det jag säger.

Men tack iaf. för länkarna som förde mig alldeles rätt:

Verkar ju nog som om hela CA-systemet är på väg ur tiden.


Attacks against TLS/SSL
=======================
Significant attacks against TLS/SSL are listed below:

Renegotiation attack
--------------------
A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS. ...

Version rollback attacks
------------------------
Modifications to the original protocols, like False Start[152] (adopted and enabled by Google Chrome[153]) or Snap Start, have reportedly introduced limited TLS protocol version rollback attacks[154] ...

BEAST attack
------------

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called BEAST ... Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway[160] in 2002. The vulnerability of the attack had been fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.

RC4 as a stream cipher is immune to BEAST attack. Therefore, RC4 was widely used as a way to mitigate BEAST attack on the server side. However, in 2013, researchers found more weaknesses in RC4. Thereafter enabling RC4 on server side was no longer recommended.[161]


CRIME and BREACH attacks
------------------------

The authors of the BEAST attack are also the creators of the later CRIME attack, .... it allows an attacker to perform session hijacking on an authenticated web session.

Timing attacks on padding
-------------------------

Earlier TLS versions were vulnerable against the padding oracle attack discovered in 2002. A novel variant, called the Lucky Thirteen attack, was published in 2013. As of February 2013, TLS implementors were still working on developing fixes to protect against this form of attack.

POODLE attack
-------------

On October 14, 2014, Google researchers published a vulnerability in the design of SSL 3.0, which makes CBC mode of operation with SSL 3.0 vulnerable to the padding attack (CVE-2014-3566).
...
On December 8, 2014, a variant of POODLE was announced that impacts TLS implementations that do not properly enforce padding byte requirements.[172]

BERserk attack
--------------
On September 29, 2014 a variant of Daniel Bleichenbacher’s PKCS#1 v1.5 RSA Signature Forgery vulnerability [173] was announced by Intel Security: Advanced Threat Research. This attack, dubbed BERserk, is a result of incomplete ASN.1 length decoding of public key signatures in some SSL implementations, and allows a MITM attack by forging a public key signature.[174]

RC4 attacks
-----------

In spite of existing attacks on RC4 that break it, the cipher suites based on RC4 in SSL and TLS were at one time considered secure because of the way the cipher was used in these protocols defeated the attacks that broke RC4 until new attacks disclosed in March 2013 allowed RC4 in TLS to be feasibly completely broken. In 2011 the RC4 suite was actually recommended as a work around for the BEAST attack.[175] In 2013 a vulnerability was discovered in RC4 suggesting it was not a good workaround for BEAST...

Truncation attack
-----------------
A TLS truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. ...

Heartbleed Bug
--------------

...The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

MarkusI
Medlem
# Skrivet: 19 Feb 2015 00:27
Svara 


Fina färdigheter i selektiv copy & paste, grattis :)

Nisse
Medlem
# Skrivet: 19 Feb 2015 11:41
Svara 


Och så kommer nästa stora skandal:

http://www.idg.se/2.1085/1.609579/lenovo-anklagas- for-att-installera-spionprogram-i-nya-datorer---ka n-lasa-din-banktrafik?utm_source=dmdelivery&utm_me dium=email&utm_content=Lenovo%20anklagas%20f%C3%B6 r%20att%20insta&utm_campaign=Morgonens%20viktigast e%20nyheter%202

Lenovo installerar spionprogram redan i fabriken MED CERTIFIKAT:

"En svensk användare på Lenovos forum pekar också på en större risk med Superfish. På en skärmdump visar han eller hon att Superfish installerat ett eget kryptografiskt certificat i datorn som öppnar för en så kallad man-i-mitten-attack där trafiken mot en krypterad webbisda, som till exempel en bank, skulle kunna avlyssnas och läsas okrypterad av Superfish trots att webbläsaren visar att trafiken är säker."

Måste vi sluta använda banker över nätet och med datamaskin fullständigt ?

MarkusI
Medlem
# Skrivet: 19 Feb 2015 12:02 - Editerad av: MarkusI
Svara 


Jo, såg detdär också på en annan site.

Tydligen så har Lenovo smygit med ett program som lägger sig just under browsern och avlyssnar trafiken samt injicerar annan reklam på sidorna.

På samma gång har Lenovo smygit in ett certificat i trusted root-certificates i Windows certificate-store och därför litar IE och Chrome på sidorna fortsättningsvis. Firefox däremot litar inte på dessa på grund av att Firefox har sin egna certifikat-databas som Lenovo inte fingrar i.

Certifikatet behöver inte vara underskrivet av en pålitlig CA, den måste endast markeras som pålitlig i datorn och därför visar browsern gröna lampor. MITM-atacken här baserar igen på att kundens dator är under någon annans makt till att börja med.

Edit: Vad lär vi oss av detta: Jo, installera om maskinen med valfritt operativsystem, direkt efter köpet.

rahlskog
Medlem
# Skrivet: 19 Feb 2015 12:09 - Editerad av: rahlskog
Svara 


Nej du Guje, nu visar du igen upp dedär egenskaperna som jag sa förhindrar en vettig diskussion.

Du glömde vissa saker när du postade din skrämsellista.

Renegotiation attack
--------------------
...The attacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middle attack. A short-term fix is for web servers to stop allowing renegotiation...
...To fix the vulnerability, a renegotiation indication extension was proposed for TLS...
...This extension has become a proposed standard and has been assigned the number RFC 5746. The RFC has been implemented by several libraries.

Version rollback attacks
------------------------
Fanns inte mycket om denna på wikipedia, men om vi går djupare och läser texten från dem som gjort attacken.
Our attack enables an adversary to successfully impersonate a server to a random client after obtaining 2^40 signed elliptic curve keys from the original server. While attacking a specific client is improbable due to the high number of signed keys required during the lifetime of one TLS handshake, it is not completely unrealistic for a setting where the server has high computational power and the attacker contents itself with recovering one out of many session keys. We remark that popular open-source server implementations are not susceptible to this attack, since they typically do not support the explicit curve option. Finally we propose a fix that renders the protocol immune to this family of cross-protocol attacks.

2^40 e ganska stort tal.

BEAST attack
------------
BEAST är fixad, alla har patchat bort den, sist ute var Apple i slutet av 2013.


CRIME and BREACH attacks
------------------------
Denhär är en som fortfarande är aktiv, men det finns många sätt att arbeta runt problemet. Stänga av komprimering av HTTP och använda cross-site request forgery protection (vilket man borde ändå göra)

Timing attacks on padding
-------------------------
Du glömde A definite fix was released as the Encrypt-then-MAC extension to TLS released as RFC 7366

POODLE attack
-------------
POODLE, den som slutligen dödade SSL 3.0. Nya exploiten mot TLS e dock intressant, men det är inte ett fel i protokollet det är ett fel i implementation. Tyvärr verkar det som de är dom stora som har fuskat och måste patcha (
F5, A10, Fortinet, Cisco, IBM och Juniper)

BERserk attack
--------------
Edit: ojsan, missade denhär, nånting om att vara tankspridd före lunch
BERserk är inte ett fel i protokollet, åter igen så kommer svaga implementationer fram. Om man läser dokumenten som förklarar felet så ser man att attacken är begränsad till vissa exponenter och dessutom är patchad redan.

RC4 attacks
-----------
RC4 är påväg ut, jag skulle ju prata med banken om det men efter din lilla tidningsatrikel vet jag inte om jag vågar.

Mozilla and Microsoft recommend disabling RC4 where possible. RFC 7465 prohibits the use of RC4 cipher suites in all versions of TLS.

Truncation attack
-----------------
This vulnerability also requires access to the victim's computer.

Heartbleed Bug
--------------
Heartbleed är patchad och död.


Man kan inte bara läsa rubrikerna och ropa varg, sånt sysslar dom med på kvällstidningar.

Guje
Medlem
# Skrivet: 19 Feb 2015 13:52
Svara 


[Client-side-data (74 bytes)]
IDToken1=12345678&IDToken2=helloworld&goto=&enc oded=false&gx_charset=UTF-8


MarkusI
Medlem
# Skrivet: 19 Feb 2015 14:00
Svara 


1. Är kunddatorn kompromissad?
2. Tryckte kunden på JA-knappen när det frågades om man ville lita på vadsomhelst?
3. Trillade anslutningen ner till HTTP?

Klient-sertifikat hjälper inte ett jota ifall nått av punkterna i listan har inträffat.

Guje
Medlem
# Skrivet: 19 Feb 2015 14:25
Svara 


1. Nej
2. I mitt fall, Ja
3. Nej


Bra MarkusI! "Klient-sertifikat hjälper inte ett jota ifall nått av punkterna i listan har inträffat."

Exakt av samma åsikt. Det är alltför enkelt att lura kunden och då faller hela korthuset. Läste nånstans att åtminstone 20% av mänskorna klickar JA då dom inte borde.
Banken borde också ta sitt ansvar och kolla vem dom har i andra ändan. Engångslösenorden är för dåliga.

Johanh
Medlem
# Skrivet: 19 Feb 2015 15:13 - Editerad av: Johanh
Svara 


Här är lite grejer man borde titta på. Program som kan varna för och hindra ARP-spoofing. Jag vet ingenting om de här programmen, men tänkte kolla lite på Arpon; det verkar intressant.

Linux/Mac/Unix: http://arpon.sourceforge.net/

Android: http://mdl.frederick.ac.cy/WifiARPGuardAndroid.htm l

Windows: http://www.xarp.net/

Edit: Här är en artikel om Arpon: http://redes-privadas-virtuales.blogspot.fi/2012/0 1/shutting-out-arp-poisoning-and-spoofing.html

MarkusI
Medlem
# Skrivet: 19 Feb 2015 15:56
Svara 


Banken borde också ta sitt ansvar och kolla vem dom har i andra ändan. Engångslösenorden är för dåliga.

Tyvärr är det så att vad än banken kräver för ID av kunden så hjälper det inte ifall säkra tunneln eller något annat är kompromissat.

Guje
Medlem
# Skrivet: 19 Feb 2015 17:03
Svara 


MarkusI, så illa är det väl inte? Vi utgår väl ifrån att kunddatorn är i skick och inte kompromissad - som du säger. Inte kan banken skyffla hela ansvaret på kundens axlar heller! Det är ju deras system för tusan. Det är dom som har resurserna.

Bara som exempel: Ponera att banken också kräver ett certifikat av kunden i stället för de där "hemliga" engångskoderna. Då är det två som kollar om trafiken är ok, och inte som nu, bara kunden.

Jag säger INTE att de skall göra så, (jag är ingen expert på datasäkerhetsfrågor), utan kastar bara fram ett förslag hur man eventuellt kunde identifiera kunden på ett rätt sätt. Vi har ju andra banker utomlands som gör såna saker. T.ex. Nordea har nåt som Nisse använder. Vad är det?

Bankerna har sitt eget betalda folk som får ta fram en lösning. Jag ställer bara en enkel kund-fråga: Varför kör dom inte med dubbla certifikat? I tidningen valde dom att låta bli att svara.... eller, som det egentligen gick till, de drog bort sitt svar. Om det inte går, säg det! Min nästa enkla fråga är: "Vad går i så fall?" HSTS, STS, SSL pinning?

Guje
Medlem
# Skrivet: 19 Feb 2015 17:20
Svara 


Tack Johanh för ARP-länkarna. Skall läsa igenom.

Att skydda sig för ARP-spoofing är svårt. Jag lever i tron att det bara är Cisco och deras DAI som har nånting ordentligt på gångs.

http://www.cisco.com/c/en/us/td/docs/switches/lan/ catalyst6500/ios/12-2SXF/native/configuration/guid e/swcg/dynarp.html

Men, lite darrar även dom på stämman: "This capability protects the network from some man-in-the-middle attacks"
Vilket kanske samtidigt berättar nånting om svårighetsgraden att skydda sig...

rahlskog
Medlem
# Skrivet: 19 Feb 2015 17:25
Svara 


Guje, byter du omständigheter nu igen?

Om kunddatorn är i skick så kommer man långt redan som det är idag, och det är inte bankens system som felar här det är kundens dator eller kunden.

Ska vi ta situationen ifall banken kräver cert, ska banken ge ut det certet också? Ska kunden hålla det hemligt i sin dator, eller kanske på ett kort? Ska kunden få stoppa det kortet i andra datorer?

Ideal lösningen skulle vara att kunden kollar bankens thumbprint varje gång mot t.ex. ett papper. Och banken gör samma med ett certifikat kunden har (gå till banken och meddela din thumbprint). Då har vi eliminerat MITM och har bara kvar alla andra problem så som trojaner, Man In the Browser etc.

Lådan Nisse har så är en variant av de hemliga engångskoderna och erbjuder ingen övrig säkerhet så långt som jag kan se. Bankerna har andra viktigare problem att fundera på som hur länge till dom kan köra sina system utan att hamna investera pengar.

Jag är inte en "vän" av banken, har nog själv en sak eller två att säga om Chip+Pin kort och PayWave men har sen länge förstått att deras intresse ligger inte i säkerhet för kunden utan det ligger i säkerhet för dem själva och vi har det bättre så länge deras säkerhet är låg för då kan vi säga att vi blivit utsatta för brott och blir ersatta.

rahlskog
Medlem
# Skrivet: 19 Feb 2015 17:40
Svara 


Att undvika ARP-spoofing är enkelt men opraktiskt.
Man hårdkodar ARP tabellerna, det är en n^2 manuell arbetsinsats där n är hur många saker du har kopplat i ditt nätverk.
Sen är det bara å gråta då man vill koppla in nånting nytt. En softare variant är att hårdkoda ARP för gateway, sen vad som händer utanför din gateway är utanför din kontroll.

Kom ihåg att aldrig använda en dator som nån annan har installerat, ha inte heller flashplayer installerad eller java. Man bör också undvika att köra program som man inte har inspekterat källkoden till.

MarkusI
Medlem
# Skrivet: 19 Feb 2015 17:47
Svara 


Att undvika ARP-spoofing är enkelt men opraktiskt.
Man hårdkodar ARP tabellerna, det är en n^2 manuell arbetsinsats där n är hur många saker du har kopplat i ditt nätverk.
Sen är det bara å gråta då man vill koppla in nånting nytt. En softare variant är att hårdkoda ARP för gateway, sen vad som händer utanför din gateway är utanför din kontroll.


Japp, släpp inte in något obekant (typ Guje) på samma L2 och konfigurera era byanät så att olika hushåll inte ligger på samma L2 (PVLAN kvalificerar inte)

Det finns ett byanät, dikterat av underskrivande, som har hushållen på olika L2 och olika L3-subnät :)

Kom ihåg att aldrig använda en dator som nån annan har installerat, ha inte heller flashplayer installerad eller java. Man bör också undvika att köra program som man inte har inspekterat källkoden till.


Håller med, åtminstone OEM OS ska ut ur maskinerna illa kvickt.

Guje
Medlem
# Skrivet: 19 Feb 2015 18:18
Svara 


rahlskog: "Lådan Nisse har så är en variant av de hemliga engångskoderna ..."

Illa rädd för det även jag. Men då vi inte vet. Ett är säkert: Security by obscurity hör inte till dagens värld.

Den triviala lösningen på ARP-spoofningen är att "Man hårdkodar ARP tabellerna" - jovisst, men så svarar du ju själv också på den möjligheten.

Till slut:
"Ska vi ta situationen ifall banken kräver cert, ska banken ge ut det certet också? Ska kunden hålla det hemligt i sin dator, eller kanske på ett kort? Ska kunden få stoppa det kortet i andra datorer?"

Goda frågor du har! Är det över huvud taget bankens roll att identifiera oss finländare? Idag är det ju bankkoderna som identifierar oss t.ex. i nätbutikerna.

Nån som vågar tänka ytterom de finska ramarna?
https://e-estonia.com/e-residents/about/

Guje
Medlem
# Skrivet: 19 Feb 2015 18:35
Svara 


MarkusI: "Det finns ett byanät, dikterat av underskrivande, som har hushållen på olika L2 och olika L3-subnät "


Då finns det åtminstone två byanät med hushållen på olika L2 så att trafiken ändå tar kortaste vägen då två grannar kommunicerar. Ärligt talat - det har nog största delen av nätoperatörerna idag, vill jag tro. Lagstiftningen kräver ju det och i praktiken blir det L2 isolering. Men hur situationen ser ut då lägenheterna i ett höghus/radhus delar på en gemensam Internet är en helt annan sak. Trots att lagstiftningen även gäller sådana installationer. (Nå, den här diskussionen hör kanske hemma i en annan tråd).

Guje
Medlem
# Skrivet: 19 Feb 2015 21:40 - Editerad av: Guje
Svara 


Förstod jag rätt så skulle Finland bli ett föregångarland när det gäller datasäkerhet. Åtminstone var den politiska viljan kraftig. Men hur man tänkt köra förbi Estland är en gåta. De har ju hela sitt land trimmat för e-tiden: fiber-nät, e-tjänster, digitala signaturer. You name it! Här har vi Nokia ... hade ... och Saunalahti 3G.... sorry 4G.

Nisse, om vi ännu kikar på din Nordea burk. Kan du känna igen drag från sista stycket här nedan.

Citerar Estlands e-site från länken här ovan.

Because e-Estonia’s infrastructure is an open system, new services can always be integrated. Businesses can freely use the digital signature system as well, and have applied it to a variety of web-based services.

Estonia boasts one of the world’s most advanced digital signature systems thanks to two crucial developments:
In March 2000, Parliament passed a law giving electronic signatures the same legal weight as traditional paper signatures.
The nation’s groundbreaking electronic ID infrastructure has created an effective and universal system for secure identification.

When a website offers the digital signature option:
The user has entered the information to be signed (tax declaration, ballot choices, contracts, etc.).

The site asks the user if they would like to digitally sign the information.
If the user clicks ‘yes’, a window from a third-party Certificate Center pops up, asking for the PIN codes connected to the user’s electronic ID Card.
The Certificate Center verifies the codes and sends a confirmation back to the website.


Thomas Backa
Medlem
# Skrivet: 20 Feb 2015 09:22
Svara 


Hur många här har skaffat det finska elektroniska ID-kortet? Jag har, det är praktiskt när man reser inom Schengen. De tekniska lösningarna finns ju redan här i landet, men så länge staten tar 51€ var femte år för kortet och bankerna inte implementerar funktionen så...

Eller var det så att man sku lägga ner den elektroniska delen av kortet?

Guje
Medlem
# Skrivet: 20 Feb 2015 09:34
Svara 


Jag har det - aldrig använt det....jo eventuellt på nån resa utomlands.

Då du säger det så. Svagt minne om nånting med e-identifikationen i Finland och att bankerna skulle sköta. Bör kollas upp!

Guje
Medlem
# Skrivet: 20 Feb 2015 10:42
Svara 


På ENGELSKA wikin hittade jag information som styrker Thomas farhågor om det finska e-id-kortet.

http://en.wikipedia.org/wiki/Finnish_identity_card


"It was initially planned as a general network authentication device for both public and private sector strong authentication needs. In 2009, however, the card was viewed by a government committee as a failure. There has been less than 300000 cards around by 2011 out of population of 5.3 million. The rationale to apply for a card has mostly been traveling abroad. Only few dozen government services have adopted it, and only one bank adopted it as login card to their netbank. All banks in Finland use a national standard called TUPAS, which uses one-time passwords. Banks also provide TUPAS authentication to other Internet-enabled businesses. Since TUPAS requires no dedicated hardware, cost of a card reader and card itself have been main causes in the failure of the eID card "

....

"In 2009 a committee recommended discontinuation of eID card. The card and certification service development and maintenance costs were listed as being excessive compared to limited use the card had seen.[3] However, as of 2011 no action has been taken regarding the card or the citizen certificate. Finnish eID card experience, which is based on voluntary adoption and users-pay-full-costs-of-the-cards model, has proven to be a very different experience when compared to for example neighboring Estonian card."


Cain&Abel hälsar och tackar Finska staten!

[Client-side-data (74 bytes)]
IDToken1=12345678&IDToken2=helloworld&goto=&enc oded=false&gx_charset=UTF-8

Guje
Medlem
# Skrivet: 20 Feb 2015 11:13
Svara 


För en månad sedan skriver Cybercom följande på sin sida:

http://www.cybercom.com/sv/Om-Cybercom/Press--Medi a/Pressmeddelanden/snabbare-digitalisering-av-fins ka-offentliga-tjanster-genom-cybercom/

2015-01-15, 08:15
Cybercom fick förtroendet att implementera den finska regeringens e-identifieringstjänster och administrering av roller och behörigheter kopplade till den. Uppskattat totalt värde av affären är 2-2.500.000 euro och uppdraget löper över 2015-2017.
....
· En ny lag om autentisering och digitala signaturer träder i kraft den 1 januari 2016.



Så vi är exakt 16 år efter Estland. De fick sin lag år 2000.


Kanske det börjar finnas material för ytterligare en tidningsartikel. Det är ju inte enbart bankerna här i landet som äventyrar datasekretessen utan även staten. Som ju nog verkar ha vaknat - sent om sider.

Nisse
Medlem
# Skrivet: 20 Feb 2015 12:36
Svara 


Det börjar ju bli löjligt med pratet om "föregångarland". Snarast är det så att då politikerna pratar om "föregångsland" så betyder det precis motsatsen i verkligheten.

Ifråga om Nordeaburken så innehåller den inte koder utan en krypteringsnyckel. Man måste mata in en kod som man får från banken i burken som svarar med en annan kod som man sedan ger åt banken. Vad jag förstår så kan bara banken med sin nyckel bli verifierad. Man måste ju lita på någon och om banken är en skurk så blir det ju problem. Men ingen ute i nätet borde kunna göra nånting. I dosan har jag sedan satt in mitt bankkort och måste ge rätt PIN för att få ut svarskoden. Då jag definierat betalningarna måste jag ännu bekräfta dem med en kodutväxling. Det torde vara ganska svårt för någon skurk att bryta sej in och göra nånting. Han måste då ha en kopia av mitt bankkort med rätt PIN som han kan sätta in i en Nordeadosa. Då är det enklare att ta ut pengar från en automat vilket han i så fall kan göra om ahn kopierat mitt kort och fått PIN-koden.

Guje
Medlem
# Skrivet: 20 Feb 2015 13:31
Svara 


Du sa att din dosa kom från Sverige och då pratar vi knappast om finska TAPAS inloggningen med engångsnycklar. Processen du beskriver liknar inte heller den.

En sån här?
http://www.nordea.se/Images/39-21253/snabbguide-do sa.pdf

Nisse
Medlem
# Skrivet: 20 Feb 2015 13:56
Svara 


Jo, just precis den.

MarkusI
Medlem
# Skrivet: 20 Feb 2015 15:12
Svara 


MarkusI: "Det finns ett byanät, dikterat av underskrivande, som har hushållen på olika L2 och olika L3-subnät "


Då finns det åtminstone två byanät med hushållen på olika L2 så att trafiken ändå tar kortaste vägen då två grannar kommunicerar. Ärligt talat - det har nog största delen av nätoperatörerna idag, vill jag tro. Lagstiftningen kräver ju det och i praktiken blir det L2 isolering. Men hur situationen ser ut då lägenheterna i ett höghus/radhus delar på en gemensam Internet är en helt annan sak. Trots att lagstiftningen även gäller sådana installationer. (Nå, den här diskussionen hör kanske hemma i en annan tråd).



Guje: PVLAN är samma L2-broadcast domän. Ditt PVLAN-nät kvalificerar inte. Operatörernas konsument-nät kvalificerar inte heller. PVLAN är inte 100% vattentätt utan hårdkodade MAC och ARP-tabeller. Dessutom finns det stor risk för att man gör en topologimiss med PVLAN och orsakar läckage på det viset...

Somsagt, dethär kan höra till en annan tråd men ditt påstående stämmer inte.

<< . 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.