"Avlyssna" pokerspelares dator

[Agent Cooper]

Jag är rätt kass på allt som har med datorer och datorsäkerhet att göra så här kommer en dum fråga.

 

Kan en anställd hos min bredbandsleverantör "avlyssna" min dator och därigenom följa mitt pokerspelande och se mina kort?

 

(Och nej, jag misstänker inte att någon gör det mot mig och jag har heller inga som helst planer på att göra detta själv.)

[Loveless]

Utan åtkomst till din dator skulle jag svara nej. Informationen hos alla aktörer antar jag är krypterad så det går inte att se någonting.

 

Om din ISP (eller mer troligt någon annan) har lyckats installera program hos dig som samlar information så är det ju en helt an sak.

[Agent Cooper]

Ok.

 

Om informationen som skickas mellan min dator och pokernätverket är krypterad, är även avsändare och mottagare dolda? Annars kan man ju tänka sig att en anställd hos bredbandsleverantören ser att det skickas en jävla massa information mellan en av deras kunder och ett pokernätverk och därigenom välja ut ett offer för ett "angrepp".

[Loveless]

Nä, tänk dig ett Brev. Själva brevet inuti kan ju vara oläsligt men om man gör samma sak med adressen så får ju brevbäraren problem. Det man kan göra för att skydda sig mot detta är att skicka via en bulvan (dvs, stoppa brevet i ett annat brev, bulvanen öppnar det yttre och skickar det inre vidare). På dataspråk används engelskans proxy. Så ja, de skulle kunna filtrera ut offer att attackera.

 

För övrigt, kom på att man teoretiskt sätt skulle man kunna tänka sig att din ISP kör en man-in-the-middle attack mot dig också, liknande de som används mot bankernas internettjänster, för att komma runt krypteringen. Har inte koll på hur sajterna skyddar sig mot detta.

[brainslicer]

långssökt....tjaa, vet inte hur många pokerbolag använder nycklar och certifikat genererade på detta vis(Open ssl på debian) men....:

http://isc.sans.org/diary.html?date=2008-05-15

Scripts that allow brute forcing of vulnerable keys (see this as rainbow tables for SSH keys) are in the wild so we would like to remind all of you to regenerate SSH keys ASAP.

Please keep in mind that SSL certificates should be regenerated as well. This can be even more problematic if you had your certificates signed since you'll have to go through this process again (and possibly pay money again).

tex stars kom ju direkt med en krypterings update efter det blev känt

http://pokerforum.nu/forum/pokerstars/47476-viktigt-meddelande-till-pokerstars-spelare.html

 

http://www.sitic.se/publikationer/namnvart/openssl-film

OpenSSL-film

Nu har det gått en tid sedan OpenSSL-sårbarheten i Debian uppmärksammades. Ni har såklart patchat alla era system och skaffat nya nycklar/certifikat/lösenord? Om inte är denna film vårt sätt att påminna er att göra det...

...

...

[Bubblan]

Jag är rätt kass på allt som har med datorer och datorsäkerhet att göra så här kommer en dum fråga.

 

Kan en anställd hos min bredbandsleverantör "avlyssna" min dator och därigenom följa mitt pokerspelande och se mina kort?

 

(Och nej, jag misstänker inte att någon gör det mot mig och jag har heller inga som helst planer på att göra detta själv.)

 

Jag jobbar på en bredbandssupport och med dom system jag har ser vi då inte något om vilka hemsidor kunder går in på eller vilka pokerklienter en kund skulle kunna tänkas lira på eller så. Allt vi ser är att kunds modem har synk eller att datorn har kontakt med firbernätet och såna saker. Så det ska inte vara något man behöver fundera på

[sneakycastro]

Det absolut vanligaste sättet måste väl ändå vara att installera en trojan hos sitt offer som skickar information. T.ex. tar den skärmdumpar och skickar med ett inställt intervall eller när personen som styr trojanen känner för det. Att försöka komma åt trafiken som skickas från din dator till pokerservern låter lite långsökt men framförallt mycket svårare.

[strater]

Rent tekniskt finns det ju inget som förhindrar (skulle tom vara mycket lätt att ordna det) att de kan se all information du skickar. Däremot så kan det nog finnas rent lagliga aspekter som gör att de ej har satt det i system för sina anställda att göra det möjligt (men vem vet...).

Angående kryptering så har jag faktiskt ingen koll på om det används av några/alla pokersidor, men finns väl ingen anledning för dem att inte ha det, lätt att fixa etc etc... Nån som vet?

[sandis84]

För övrigt, kom på att man teoretiskt sätt skulle man kunna tänka sig att din ISP kör en man-in-the-middle attack mot dig också, liknande de som används mot bankernas internettjänster, för att komma runt krypteringen. Har inte koll på hur sajterna skyddar sig mot detta.

 

De använder certifikat. Du hämtar serverns publika nyckel från en tredje part och krypterar dina meddelanden med denna nyckel. Därmed kan ingen annan än den tänkta servern dekryptera dina meddelanden.

[Matfrid]

De använder certifikat. Du hämtar serverns publika nyckel från en tredje part och krypterar dina meddelanden med denna nyckel. Därmed kan ingen annan än den tänkta servern dekryptera dina meddelanden.

 

Det är ju just där som man kan byta ut certifikaten via en 'man-in-the-middle' exploit, precis som Loveless skrev om. Kaspersky antivirus använder t e x 'certificate substitution' för att scanna ssl-trafik. Den alltmer kraftfulla programvara internetleverantörer använder för att inspektera alla paket borde i princip klara av detta.

[sandis84]

Det är ju just där som man kan byta ut certifikaten via en 'man-in-the-middle' exploit, precis som Loveless skrev om. Kaspersky antivirus använder t e x 'certificate substitution' för att scanna ssl-trafik. Den alltmer kraftfulla programvara internetleverantörer använder för att inspektera alla paket borde i princip klara av detta.

 

Jag förstår inte vad du menar. Om jag ska gissa så är "certificate substitution" att virusprogrammet lägger sig som ett lager mellan din dator och din anslutning, för att kunna dekryptera trafiken innan den når dig. Men detta går inte att utföra som en MITM-attack, det går bara om programmet har fullständig kontroll över din dator.

 

Såhär går min anslutning till en server till:

Jag upprättar en säker anslutning till en Certificate Authority (CA) med hjälp av deras publika nyckel som följer med browsern. Det certifikatet jag får innehåller den publika nyckeln till servern jag vill ansluta till. Alla mina meddelanden till servern krypteras med denna publika nyckel, en säker anslutning upprättas. Det enda sättet något kan avlyssna denna trafik är att antingen se till att min browsers tilltrodda CAs innehåller en felaktighet, eller blixtsnabbt bruteforcar paketen jag skickar. Ingadera är möjligt för en ISP att göra.

[Matfrid]

Jag förstår inte vad du menar. Om jag ska gissa så är "certificate substitution" att virusprogrammet lägger sig som ett lager mellan din dator och din anslutning, för att kunna dekryptera trafiken innan den når dig. Men detta går inte att utföra som en MITM-attack, det går bara om programmet har fullständig kontroll över din dator.

 

Såhär går min anslutning till en server till:

Jag upprättar en säker anslutning till en Certificate Authority (CA) med hjälp av deras publika nyckel som följer med browsern. Det certifikatet jag får innehåller den publika nyckeln till servern jag vill ansluta till. Alla mina meddelanden till servern krypteras med denna publika nyckel, en säker anslutning upprättas. Det enda sättet något kan avlyssna denna trafik är att antingen se till att min browsers tilltrodda CAs innehåller en felaktighet, eller blixtsnabbt bruteforcar paketen jag skickar. Ingadera är möjligt för en ISP att göra.

 

Ok, låt oss ta denna anslutning som man-in-the-middle helt utanför datorn.

klienten (du) upprättar anslutningen till CA enligt ovan. Jag känner igen protokollet och kan manipulera varje steg i förhandlingen. All kommunikation går ju genom mig. Jag förmedlar vidare paketen och får tillbaka nyckeln. Jag byter ut den mot en egen nyckel.

När sedan klienten skickar meddelanden läser jag dem med min egen nyckel och krypterar dem med CA's nyckel innan de skickas vidare.

På samma sätt bollar jag med ev. övriga nycklar, om dessa används från båda sidorna i kommunikationen. På så sätt kan jag i detta fall läsa all din SSL trafik.

[sandis84]

Ok, låt oss ta denna anslutning som man-in-the-middle helt utanför datorn.

klienten (du) upprättar anslutningen till CA enligt ovan. Jag känner igen protokollet och kan manipulera varje steg i förhandlingen.

 

Med hjälp av CAns publika nyckel så har jag krypterat meddelandet med RSA-krypto. För dig, som inte har CAns privata nyckel, så förfaller meddelandet vara en slumpmässig sträng bitar.

 

http://en.wikipedia.org/wiki/RSA#Security

 

I detta meddelandet kan jag infoga en symmetrisk nyckel som vi båda använder fortsättningsvis för att kryptera alla meddelanden.

[Matfrid]

Med hjälp av CAns publika nyckel så har jag krypterat meddelandet med RSA-krypto. För dig, som inte har CAns privata nyckel, så förfaller meddelandet vara en slumpmässig sträng bitar.

 

http://en.wikipedia.org/wiki/RSA#Security

 

I detta meddelandet kan jag infoga en symmetrisk nyckel som vi båda använder fortsättningsvis för att kryptera alla meddelanden.

 

Du skriver att du har krypterat meddelandet med CA'ns publika nyckel. Men det har du inte gjort i det exempel jag gav.

 

Noter att du aldrig får CA'ns publika nyckel. Du får ett substitut från man-in-the-middle, som du använder för att kryptera. Om du senare under förhandlingen använder SSL-protokollet för ytterligare förhandlingar om nycklar, kan de bytas ut på samma sätt.

 

 

Klient <----> Man in the middle ngnstans hos internetleverantören <-----> Server

[sandis84]

Du skriver att du har krypterat meddelandet med CA'ns publika nyckel. Men det har du inte gjort i det exempel jag gav.

 

Noter att du aldrig får CA'ns publika nyckel. Du får ett substitut från man-in-the-middle, som du använder för att kryptera. Om du senare under förhandlingen använder SSL-protokollet för ytterligare förhandlingar om nycklar, kan de bytas ut på samma sätt.

 

 

Klient <----> Man in the middle ngnstans hos internetleverantören <-----> Server

 

Jag får CA'ns publika nyckel med browsern. Jag får den givetvis inte av CA'n själv. Publika nycklar distribueras aldrig så, såvida man inte kan bekräfta att nyckeln stämmer via nåt annat medium (typ IRL). Om jag inte har CA'ns publika nyckel så kan jag inte lita på den såvida inte nån av mina betrodda CA's kan gå i god för den. Det fungerar typ som ett web of trust, om du är bekant med det.

 

 

edit: http://en.wikipedia.org/wiki/Root_certificate

[Kafka]

Rent tekniskt finns det ju inget som förhindrar (skulle tom vara mycket lätt att ordna det) att de kan se all information du skickar. Däremot så kan det nog finnas rent lagliga aspekter som gör att de ej har satt det i system för sina anställda att göra det möjligt (men vem vet...).

 

Snart så måste de kanske http://frapedia.se/wiki/FRA-lagen

[Matfrid]

Jag får CA'ns publika nyckel med browsern. Jag får den givetvis inte av CA'n själv. Publika nycklar distribueras aldrig så, såvida man inte kan bekräfta att nyckeln stämmer via nåt annat medium (typ IRL). Om jag inte har CA'ns publika nyckel så kan jag inte lita på den såvida inte nån av mina betrodda CA's kan gå i god för den. Det fungerar typ som ett web of trust, om du är bekant med det.

 

 

edit: http://en.wikipedia.org/wiki/Root_certificate

 

Jag antar att du håller med om att SSL utan denna tredje part som CA kan utsättas för man-of-the-middle attacker. Det är principen för hur en sådan skulle gå till som jag har skissat på, och det kan vara bra för övriga här att veta om denna sårbarhet.

 

Sedan återstår att vi inte är överens om att användande av tredje parts CA är osårbar för samma metod.

 

När klienten initierar förhandling med servern - 'tsl client hello' - vet den inte vilken tredje parts CA som ska användas. En krypterad förbindelse har ännu inte upprättats. En man-in-the-middle kan då formulera om svaret. Det är inte nödvändigt att en tredje part används ( skulle tro att mycket av de ssl och tsl-förbindelser vi använder i webläsare och pokerklienter inte använder det), men OM det används står det fritt för man-in-the-middle att formulera om serverns svar. Han kan t ex ha skaffat ett certifikat hos Verisign, vilket inte är svårt, så att när klienten sedan ska bekräfta nyckeln är allt frid och fröjd. Han kan också köra sin egen CA och hänvisa till den.

 

Jag vill med detta inte ha sagt att det skulle vara 'en lätt sak', men hoppas att du håller med om att en sådan attack i princip är möjlig. [ edit: det gör inte sandis84, men det är kanske dags att avsluta diskussionen med att konstatera att vi inte är överens om den punkten]

[sandis84]

Jag antar att du håller med om att SSL utan denna tredje part som CA kan utsättas för man-of-the-middle attacker.

 

Ja.

 

Jag vill med detta inte ha sagt att det skulle vara 'en lätt sak', men hoppas att du håller med om att en sådan attack i princip är möjlig.

 

Nej.

 

Säg att jag ska ansluta till flashback.info. Det första som sker är INTE att jag skickar iväg en okrypterad förfrågan till flashback.info där jag frågar efter hur deras certifikat ser ut och var jag kan hitta det. Istället skriver jag följande förfrågan:

 

"skicka mig flashback.info:s public key"

 

Denna förfrågan krypterar jag med min CA's public key och skickar till min CA. Mitt meddelande innehåller också data för att upprätta en säker anslutning, så att även hans svar är krypterat.

 

Jag får det krypterade svaret:

 

"flashback.info:s public key är x"

 

När jag sedan skickar mitt meddelande till flashback.info så krypterar jag det med x. Alla meddelanden som åker ut på nätverket är krypterade med korrekta public keys, vid inget tillfälle kan man utföra en MITM-attack om man inte t.ex. har en trojan på användarens dator. Så som du verkar föreslå att certifikat funkar så fyller de ingen som helst funktion, och är helt värdelösa. Vilket syfte anser du att certifikat fyller?

 

 

 

Han kan också köra sin egen CA och hänvisa till den.

 

Ungefär halva mitt förra inlägg handlade om exakt det här scenariot och varför det inte kan inträffa.

 

 

EDIT: Om jag inte hittar rätt certifikat så kanske jag frågar flashback.info om hjälp med att hitta certifikatet, jag är osäker på hur protokollet är uppbyggt kring den detaljen. Men likväl så är det jag som skickar förfrågan till CA'n där jag ställer exakt den frågan jag skrev i mitt exempel. Och jag använder bara public keys som jag antingen redan har, eller får av CA's vars public key jag redan har. Alltså frågar jag bara efter certifikatet till 'flashback.info', och inte till hans phishing-sajt 'flaaaaashback.info'