Heisann,

kan starte med å unnskylde for dårlig tittel; unnskyld, ikke skyt meg.

Har seg slik at jeg har brukt Plex Media Server en stund nå, er godt fornøyd med det, men det store minuset; den støtter kun "en bruker". For å ha forskjellige statuser på om en TV-serie er sett eller ikke må man ha "myPlex" / "plexPass". Dette koster $80, noe som ikke er mye i det - tvertimot ganske rimelig. Problemet jeg har med det er at man ikke vet hvilken data de tar vare på og sender over nettet. Man MÅ ha internett for å bruke det(Ikke alltid jeg har nett, oftest da jeg vil se TV-serier og filmer). Tjenestene deres har en tendens til å være svært treg til tider.

Så planen min var å se på pakkene som ble sendt. De går over HTTPS og er forsåvidt ikke så veldig avanserte. Har skrevet et program i Python for å håndtere innlogging og registrering, bare som en test. Problemet mitt oppstår her; jeg setter my.plexapp.com til å peke til localhost i hosts fila. Men når den prøver å koble til krever den en HTTPS-tilkobling fra PMS sin side. Satt derfor opp en HTTPS server istedefor vanlig HTTP, dette fungerte heller ikke.

Det jeg mistenker nå er at den sjekker sertifikatet eller noe lignende for å verifisere at den kobler til rett host. Så nå sitter jeg her og klør meg i hode å lurer på hvordan jeg kan går rundt dette?

Forslag mottas med takk og mest sannsynlig oppfølgings spørsmål. Tips mottas med et innslag i "ToDo"-listen min.

Har ikke noe godt svar på akkurat dette, men jeg vet Plex har et API, kanskje du kan finne ut noe der: http://dev.plexapp.com/docs/api/

Vet det, ikke det jeg ser etter
Tanken er å "reverse engineer" PlexPass delen av Plex Media Server (altså den delen som er låst og driftes av Plex selv).

HTTPS er HTTP protokoll kryptert med SSL algorithmen, SSL bruker Public key certificate noe som vil si at både server og klient har en public key og en private key, for å kunne identifisere hosten så signeres sertifikatene av en CA (Certificate authority). CA kan være et offentlig bedrift som Buypass eller verisign som selger sertifikater signert av dem, eller CA kan være en privat person/bedrift som signerer sertifikater til eget/begrenset bruk.

Ved å vertifisere signatur(ene - ved signering over flere ledd) mot en "trusted" CA's signatur så kan man fastslå at den hosten man kommuniserer med er den som den utgir seg for å være.

Som tidligere nevt så har hver host en private key, denne nøkkelen må holdes hemmelig og hele sikkerheten i krypteringen er avhengig av at den ikkje er kjent, public key blir generet utfra private key'en. Public key'en der i mot må deles med den man kommuniserer med for å kunne opprette en kryptert forbindelse.

I ditt tilfelle så ser jeg at Plex TV bruker sertifikater signert av DigiCert på websiden dems, så det er ikkje utenkelig at dem bruker samme eller andre sertifikater signert av DigiCert i programvaren sin. For at du skal kunne "lure" programvaren til å tro at den kommuniserer med Plex TV sine servere, så er du avhengig av private key'en til CA'en, i dette tilfelle enten Plex TV eller DigiCert.

Dette her er en meget hyppig brukt algorithme som er ansett som meget sikkert, så jeg kan med 99,9% sikkerhet si at du ikkje kommer til å klare å knekke den, så fremt du ikkje finner et stort sikkerhetshull i algorithmen, men det tror jeg er utelukket.

Hm-m.. Ser ut som også PlexPass bruker DigiCert.

Så hvordan fungerer dette på Plex Media Server(som kjører lokalt hos meg og kobler til PlexPass)-siden når det kommer til å gjenkjenne at den faktisk kobler til PlexPass og ikke min liksom-PlexPass server? Hvilke angrepsvektorer finnes mot slikt?

Kort forklart: Jeg vil redirecte https://my.plexapp.com til https://localhost slik at når Plex Media Server kobler til PlexPass kobler den egentlig til localhost istedefor.

Den vil vertifisere signaturen opp mot root sertifikatet, stemmer ikkje denne så vil handshaken avsluttes.

Som dyret nevnte, så er vel et MiTM (Man-in-the-middle) angrep den beste løsningen, ved å skifte ut sertifikatet som programvaren bruker med ditt eget og kjøre trafikken igjennom en proxy, der trafikken til proxyen blir kryptert med ditt eget sertifikat og trafikken ut fra proxyen blir kryptert med det autentiske sertifikatet til Plex TV. Da vil du kunne avlytte og dekryptere trafikken mellom deg og proxyen med private key'en fra ditt hjemmelagde sertifikat.

Poenget her er jo ikke å utføre et MITM angrep, men å erstatte my.plexapp.com siden med min egen.

PMS(lokalt) --> my.plexapp.com

til

PMS(lokalt) --> localhost


For deretter å implementere funksjonene som finnes hos my.plexapp.com på min egen skrevne server.

Det som er problemet mitt nå er at det virker som(dere begge, 0xFF og Dyret har nevnt) at den avslutter tilkoblingen når den kobler til localhost.

Så for å få den til å spørre mot min localhost la jeg det bare inn i hosts fila. Starta min egen "server" som skal erstatte my.plexapp.com. Starter Plex Media Server. Når Plex Media Server prøver å koble til my.plexapp.com(som nå peker til localhost) så dreper den bare tilkoblingen. Går derfor utifra at sertifikatet er "innebygd" i Plex Media Server, korrekt?

Å koble til din egen server vil være sluttproduktet, men inntil da må du jo studere protokollen for å kunne replikere oppførselen. Derfor blir første steg å sette opp en MITM-løsning der du kan se hva som skjer. Sannsynligvis spør Plex serveren noe sånt som "GET /api/news.json HTTP/1.1" og så svarer serveren din med "404 Not Found". Da antar applikasjonen at programvaren sin er for gammel, eller at det er feil på servicen, og avbryter. Alternativt så avbrøt den øyeblikkelig når sertifikatet ga mismatch. Hvis ønsket ditt er å lure appen til å tro at den er koblet til den ordentlige serveren, så må serveren din være satt opp på en sånn måte at den ser ut som den ordentlige serveren.

For alt jeg vet så kan det hende at Plex ikke sjekker sertifikatene i det hele tatt, men dette finner du jo ut lett som en plett ved å kikke i webserverloggene dine eller i favorittsnifferen din (som du mater med sertifikatet serveren bruker).

Du har allerede studert trafikken? Da vil jeg stille spørsmålet om hvordan du har klart det når den bruker HTTPS protokollen? SSL protokollen er ende-til-ende kryptering, det betyr at dataen som sendes blir kryptert i programvaren, sendt til serveren og dekryptert når den kommer frem til programvaren, det er ingen ledd trafikken går igjennom som er ukryptert.

Ta en screenshot av wireshark vinduet og post den her, jeg misstenker det er SSL trafikken du har fanget opp.

Ok, da forstår jeg bedre!

Du må nesten se nøyere på hva serveren din faktisk sender tilbake, og sammenligne det dekrypterte innholdet. Hvis du allerede har en server kjørende med SSL så er det bare å gi Wireshark tilgang til sertifikatet så burde du kunne sjekke. Enten så feiler krypteringen, eller så er det noe i responsen(e) som klienten ikke liker. Kanskje noe så dumt som en header du ikke får - eller at dataene du har sniffet tidligere er gått ut på dato.

@0xFF
Vel, den ene enden er jo min PC lokalt, og det å starte opp Fiddler2, huka av "Decode" og vise deg at pakken kommer opp blir litt for dumt.. men ser nesten slik ut.



Så jeg bør se nærmere på responsen min og kan rulle ut at den sjekker opp mot noe sertifikat som kommer med installasjonsfilene?

Som er definisjonen på MITM. Se på http://mitmproxy.org for grei pakkeinspeksjon. Jeg regner med HTTPS'en du satte opp lokalt hadde et selvsignert sertifikat, noe som ikke er godt nok. Den krever nok et gyldig sertifikat, utstedt av en ekte CA.

Definisjonen av "en ekte CA" er derimot helt opp til maskinen som spør, så det er fullt mulig å be operativsystemet stole på en egenprodusert CA - og bruke den til å signere sertifikater

Alle som har et root sertifikat, har et selvsignert sertifikat, om dem er kommersielle distributør av sertifikater eller om man har laget det hjemme. Root sertifikatet er toppen av sertifikat treet og kan dermed ikkje bli signert av andre en seg selv.

Samme gjelder CA, som dyret nevnte så er det ingenting som heter "ekte CA", man beskriver det som "trusted CA" i sertifikat verden, og den hjemme oppsatte CA'en kan være like så "trusted CA" som den VeriSign hoster.