Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Meerdere beveiligingsgaten gevonden in 4g lte-standaard

In 4g lte zijn beveiligingsgaten gevonden die het mogelijk maken voor aanvallers om gebruikers naar malafide websites te sturen en hun browsinggedrag in kaart te brengen. Voor de aanvallen geldt een maximale afstand van 2 kilometer en een paar duizend euro aan apparatuur is vereist.

Een van de aanvallen, genaamd aLTEr, behelst het onderscheppen van 4g-verkeer en het spoofen van de dns-server door die van de aanvaller, waarna het doelwit bijvoorbeeld naar een phishingwebsite gestuurd wordt. Dit is mogelijk doordat een deel van de wederzijdse authenticatie tussen netwerk en smartphone niet fatsoenlijk versleuteld is. De datapakketjes worden onderschept, het dns-adres in de request wordt aangepast naar een malafide dns, die het doelwit weer naar bijvoorbeeld een phishingwebsite stuurt.

Het in kaart brengen van de browsinggeschiedenis is mogelijk in de vorm van een passieve aanval. Een sniffer kan een verbinding afluisteren en aan de hand van de grootte van de packets en de frequentie waarmee ze verstuurd worden, bepalen welke website of domein het om gaat. Dit gebeurt volgens de onderzoekers door fingerprints te maken van de datastromen van populaire websites en die te vergelijken met de datapakketjes die naar het doelwit gaan. In testopstellingen zouden de onderzoekers bij deze methode een slagingspercentage hebben bereikt van rond de 89 procent.

Voor de aanvallen is een zogenaamde software-defined radio nodig voor de aanvaller om zich voor te doen als de netwerkoperator. Een dergelijk apparaat kost volgens Ars Technica zo'n 4000 dollar. Dit zorgt ervoor dat de aanval, die weliswaar mogelijk is, veel geld, kennis en inzet vergt. Dat op zijn beurt zorgt ervoor dat het waarschijnlijker is dat de aanval alleen op bijzondere doelwitten zou worden gebruikt, zoals politici en journalisten.

De onderzoekers, die van de Ruhr-Universiteit in Bochum en de NYU Abu Dhabi komen, hebben hun bevindingen al gemeld bij de GSM Association, die op zijn beurt netwerkproviders en de 3GPP informeerde. Die laatste is het orgaan dat verantwoordelijk is voor het opstellen van bijvoorbeeld de 5g-specificatie. De onderzoekers willen dat de beveiligingsparameter die deze aanvallen zou voorkomen, verplicht ingeschakeld wordt bij 5g. In de huidige 5g-specificatie is deze nog optioneel. In een reactie stelt de 3GPP dat het de actieve aanval waarbij de dns-server gespoofed wordt zeer serieus neemt, maar dat het op een dergelijke korte termijn verder nog niets concreets kan melden. Ook tekent het aan dat dns spoofing overal in de keten tussen gebruiker en dns-server plaats kan vinden en dat alleen e2e-beveiliging dat kan tegengaan.

Van de proof of concept hebben de onderzoekers een video gemaakt. Het volledige onderzoeksrapport is ook te downloaden.

Door Mark Hendrikman

Nieuwsposter

01-07-2018 • 11:16

56 Linkedin Google+

Reacties (56)

Wijzig sortering
Al in 2015 kwam deze paper naar buiten waar een groep onderzoekers uit Finland en Duitsland het voor elkaar kregen om met $1400 aan apparatuur 4G LTE apparaten hun GPS locatie te laten lekken en ze te laten downgraden naar minder veilige 2G/3G verbindingen.

Ik heb daar sindsdien niet veel meer over gelezen, maar worden dit soort gaten ook gedicht?
Of is een standaard als deze dusdanig 'vastgespijkerd' dat hier niets aan te doen valt, omdat veel apparaten nou eenmaal geen updates meer krijgen?
Het voorkomen van downgrade naar 2G/3G kun je niet zomaar doen helaas. De enige manier is het uitschakelen van 2G/3G in je telefoon. Dat kan ook alleen maar als VoLTE wordt gebruikt. Helaas is dat vaak alleen in het thuisland zo, dus in andere landen (nog) niet, daar móet je 2G/3G gebruiken.

Zelfs als 2G/3G op het netwerk uit zouden staan, kun je alsnog 4G verstoren waardoor het mobieltje naar 2G/3G schakelt op een random door jezelf verzonnen frequenties waarbij je de netwerk-ID van het netwerk spooft. Zelfs al heeft het netwerk bijvoorbeeld geen 2G meer actief, dan nog zal het mobieltje naar de malafide 2G schakelen. En op 2G is er dus totaal geen authenticatie van het basisstation, dus als ik een OpenBTS opzet met het ID van KPN, dan ziet jouw mobieltje gewoon KPN en heeft het geen idee dat het mijn fake-basisstation is...

Je eigen veiligheid binnen Nederland upgraden kan door je telefoon te locken op 4G, mits je een provider hebt die VoLTE ondersteunt, en je ermee kunt leven dat er bij alle providers nog kleine plekken zijn zonder LTE waar je gesprek hakkelt of wegvalt.
Helpt een VPN hiertegen?
Helpt wel met het beschermen van data, maar niet tegen bijvoorbeeld het afluisteren van je telefoongesprekken. Ook zal een VPN data op 2G duidelijk langzamer maken waarschijnlijk.
Ook zal een VPN data op 2G duidelijk langzamer maken waarschijnlijk.
De handshake duurt ietsje langer. Het verschil tussen 2G zonder VPN en 2G met VPN is te verwaarlozen. De overhead van een VPN is met alle protocollen miniem. Wel kan het zo zijn dat een site-to-site VPN toegang geeft tot bijvoorbeeld een netwerk waarbij men aanneemt dat de client op LAN zit of iets van breedband heeft -- icm 2G met alle gevolgen van dien. Dat ligt niet aan de cryptografie of het protocol; dat ligt aan de combinatie van de grootte v/d data plus de verbinding. Als de VPN encryptie deed via /dev/null had je vrijwel dezelfde ervaring. Een VPN die default gateway wordt kan bovendien trucjes doen als compressie, ad blocking, enz. Sterker nog, wanneer je gebruik maakt van 4G zal je machine in korte tijd meer moeten encrypten/decrypten. Je zou wel nog iets als WireGuard kunnen gebruiken om inderdaad de maximale throughput the halen.

[Reactie gewijzigd door Jerie op 1 juli 2018 16:28]

Wat je zegt over de vpn-gateway qua extra compressie klopt. Ik weet even niet precies hoe het zit met zaken als SSH waarbij je continu heel erg kleine pakketjes verstuurt. Is dat even efficiënt/klein?

Wat betreft 4G: deze encryptie/decryptie zit in de chip, zal niet veel effect hebben verwacht ik. Net als dat hardware-accelerated vpn-encryptie dat ook niet zal hebben. Het ging mij puur om de latency van wat er door de lucht vliegt.
Hoe bedoel je de encryptie/decryptie zit in de chip? In welke chip? Geldt dat voor alle 4G chips en alle VPNs?

VPNs zijn wel een aanslag op je batterij, ja, hoewel dat bij WireGuard relatief nog meevalt. Latency zal over het algemeen ook hoger zijn dan zonder wanneer je gebruik maakt van default gateway. Bij site-to-site is het latency verschil verwaarloosbaar want anders had je ook naar dat netwerk verbonden maar dan zonder cryptografie.

Een SSH VPN kan alleen TCP IIRC, en ook dat is een aanslag op je batterij.

Waar je wel mee kunt spelen is keep alive settings. Als je die hoger zet, dan kost dat minder data en bandwidth.
De standaard encryptie voor LTE zit in bijv. de Snapdragon-chips die in veel telefoons zitten. Alle radio-logica zit daarin, gaat vrij ver. Het komt dan decrypted / rauw het Android OS binnen.

Daarom was er een tijdje geleden ook het eea te doen over kwetsbaarheden in Snapdragon-chips. Ik weet alleen niet meer of dat nou via de drivers opgelost was of dat het dieper zat.
Een VPN wordt gebruikt bovenop LTE. Andere layer.
Ligt eraan hoe en welke VPN wordt toegepast....
https://www.quora.com/Whi...model-does-VPN-operate-in

Based on the OSI model layers, VPNs can be divided into the following three main categories:

Data link layer VPNs
Network layer VPNs
Application layer VPNs

Data Link Layer VPNs

With data link layer VPNs, two private networks are connected on Layer 2 of the OSI model using a protocol such as Frame Relay or ATM. Although these mechanisms provide a suitable way of creating VPNs, they are often expensive, because they require dedicated Layer 2 pathways to be created. Frame Relay and ATM protocols inherently do not provide encryption mechanisms. They only allow traffic to be segregated based on which Layer 2 connection it belongs to. Therefore, if you need further security, it is important to have some sort of encryption mechanism in place.

Network Layer VPNs

Network layer VPNs are created using Layer 3 tunneling and/or encryption techniques. An example is the use of the IPsec tunneling and encryption protocol to create VPNs. Other examples are GRE and L2TP protocols. It is interesting to note that although L2TP tunnels Layer 2 traffic, it uses Layer 3, the IP layer, to do this. Therefore, it is classified as a network layer VPN.

The following chapters focus on network layer VPNs. Network layers provide a very suitable place to do encryption. The network layer is low enough in the stack to provide seamless connectivity to all applications running on top of it and is high enough to allow suitable granularity for the traffic that needs to be part of the VPN based on the extensive IP Addressing architecture in place. Due to its natural positioning in the IP market, Cisco focuses on network layer encryption as the main mechanism for creating VPNs.

Application Layer VPNs

Application layer VPNs are created to work specifically with certain applications. One very good example of such VPNs are SSL-based VPNs. SSL provides encryption between Web browsers and servers running SSL. Another good example is SSH. SSH is pushed as a mechanism for encrypted and secure login sessions to various network devices. SSH can encrypt and thus create VPNs for other application layer protocols, such as FTP and HTTP.

One of the main drawbacks of application layer VPNs is that often they are not seamless. The user must perform an action to enable the end devices for creating the VPN for each of the various applications. As new services and corresponding applications are added, support for them must be developed as well. This is unlike network layer and link layer VPNs, which provide seamless VPN connectivity for all applications after the basic VPN has been set up.

[Reactie gewijzigd door F. Scaglietti op 1 juli 2018 23:23]

Other examples are GRE and L2TP protocols. It is interesting to note that although L2TP tunnels Layer 2 traffic, it uses Layer 3, the IP layer, to do this. Therefore, it is classified as a network layer VPN.
En GRE wordt gebruikt voor PPTP VPNs; ook onveilig.

Verder is de aanval op layer 2, maar als je alleen route via je VPN en anders de traffic blocked (of site-to-site gebruikt), en je gebruikt public key authentication, dan is er eigenlijk niets aan de hand. MITM faalt dan, en je hebt geen toegang tot de VPN of het internet. Als je vervolgens op een lokatie zit waar je wel signaal behoort te hebben, dan weet je ook dat er iets aan de hand is.

Als je dan kijkt naar https://www.tutorialspoin...protocol_stack_layers.htm dan is het alleen IPsec.

OpenVPN, WireGuard, en SNTs gebruiken allemaal layer 7.

[Reactie gewijzigd door Jerie op 1 juli 2018 23:37]

Hoe stel je dit in op Android? Ik gebruik het KPN-netwerk.
Je kunt wel 3G/2G tijdelijk even aanzetten als je wilt telefoneren. Of andersom, 2G/3G uitzetten wanneer je rustig wilt browsen.
Bij gebeld worden is het niet handig :+
Volgens mij is dit wel mogelijk met bijv XPrivacyLua? Verder kun je ipv VoLTE ook SIP gebruiken.

Wat je in ieder geval kunt doen is 3G uitschakelen en 2G je fallback voor 4G later zijn. Al is het alleen maar omdat 2G en 4G beter zijn voor de batterij.
2G is nog minder veilig dan 3G. Qua accu is 2G alleen zuiniger bij kleinere hoeveelheden data trouwens.
Ik ben er van overtuigd dat inlichtingendiensten al jaren geïnfiltreerd zijn in standaarden comités van internet- en communicatiestandaarden om afluisteren mogelijk te maken. Er is echt geen reden waarom er wéér een zwakheid zit in een communicatie protocol (dit keer geen authenticatie, voorheen zwakke algoritmes).

In de VS hebben inlichtingendiensten de opdracht gekregen de standaardisering niet te saboteren, maar waarschijnlijk was deze standaard al gemaakt voordat dit decreet van kracht werd of ze negeren het.

[Reactie gewijzigd door ArtGod op 1 juli 2018 13:09]

Ik ben er van overtuigd dat inlichtingendiensten al jaren geïnfiltreerd zijn in standaarden comités van internet- en communicatiestandaarden om afluisteren mogelijk te maken.
Hoewel ik je uitspraak niet betwist, ze zijn er ongetwijfeld, weet ik nog niet of hun invloed echt zo groot is.
Ten eerste omdat dit soort comités redelijk in openheid werken, juist om te veel invloed van een enkel lid te vermijden.
Er is echt geen reden waarom er wéér een zwakheid zit in een communicatie protocol (dit keer geen authenticatie, voorheen zwakke algoritmes).
Dat kun je ook omdraaien he, er is geen reden waarom het nu voor het eerst wél zou lukken om wel een echt veilig systeem te ontwikkelen?
Beveiliging is gewoon verschrikkelijk moeilijk. Niet voor niets is het devies al jaren "Nooit je eigen crypto schrijven" want het gaat steeds weer fout. De academici vinden al zoveel fouten in elkaars werk dat je daar geen geheime dienst meer voor nodig hebt.

Ik denk dat geheime diensten inderdaad invloed hebben op de ontwikkeling van dit soort standaarden, maar in mijn ogen is het vooral zo dat ze dat kunnen doen omdat het zo'n verschrikkelijk moeilijk gebied is vol onduidelijkheden. Ik geloof niet dat we zonder hun inmenging wel echt veilige systemen zouden hebben.

Wat ook de reden voor alle onveiligheid is, verdedigen zullen we toch moeten. Zelfs als de communicatieprotocollen zelf veilig zijn, dan kan het op talloze andere punten alsnog fout gaan. De beste oplossing is om meerdere lagen verdediging te leggen.
Als ik zie hoe vaak er zonder duidelijk aanwijsbare reden weer vage nauwelijks-geteste cryptografie gebruikt wordt in dit soort standaarden, dan krijg ik toch sterk de indruk dat er inderdaad partijen zijn die hiervoor aan het lobbyen zijn (of dat dan inlichtingendiensten zijn of niet).

Er zijn gewoon goed-geteste en breed ondersteunde opties voor dit soort doeleinden, maar die worden nog te vaak niet gebruikt. Het lijkt er ook op dat binnen organisaties als de IETF er nauwelijks of geen cryptografen bij betrokken zijn. Dan is het wachten tot het mis gaat.

Samengevat: ja, beveiliging is moeilijk. Maar de huidige failure modes hebben daar doorgaans weinig mee te maken, en lijken eerder veroorzaakt te worden door het constante onnodige gebruik van 'offbeat cryptography' en dergelijke.
Authenticatie is een standaard onderdeel van elke cryptografische versleuteling, juist om dit soort aanvallen (bit-flipping) onmogelijk te maken. Je gaat mij toch niet vertellen dat de mensen die het cryptografische gedeelte van dit soort belangrijke protocollen ontwerpen niets van cryptografie afweten? Ik geloof dit gewoon niet!

En de ciphers die gebruikt worden zijn vaak bijzonder zwak. En als ze al een goede gebruiken, zoals AES, dan zitten er weer allerlei toeters en bellen omheen die het zwak maken.

[Reactie gewijzigd door ArtGod op 2 juli 2018 10:05]

Je gaat mij toch niet vertellen dat de mensen die het cryptografische gedeelte van dit soort belangrijke protocollen ontwerpen niets van cryptografie afweten? Ik geloof dit gewoon niet!
Helaas lijkt dat precies te zijn wat er aan de hand is.
Er zijn meerdere redenen te bedenken waarom ook in dit protocol zwaktes zitten.

Je noemt zelf al dat wetgeving ook hier (nog) geen argument was. Maar zelfs al was dat het wel dan betwijfel ik dat er geen argumenten zijn die van grotere invloed zijn

Als er geen andere argumenten zouden zijn dan zou dat betekenen dat iedereen weg kijkt. Zowel tijdens het bedenken, het definitief maken en na de implementatie. En dat dan onder het argument dat iedereen het eens is met de belangen van veel verschillende landen. Wetenschappers, technici, juristen, bedrijfseconomen van honderden verschillende achtergronden, organisaties en landen die allemaal jou beeld zouden volgen dat het belang van inlichtingen diensten absoluut is. Dat lijkt me niet realistisch.

Ik vermoed dat dit soort zwakke plekken in protocollen bestaan doordat we met zijn alleen toch te weinig bezig zijn (geweest) om die zwaktes te voorkomen en daarna ook weinig moeite doen om de zwaktes te vinden. Anders zou je ook kunnen beargumenteren dat iedereen met verstand van deze protocollen, die niet bij het ontwerp betrokken was, in de afgelopen 15 jaren deze zwaktes had kunnen ontdekken. Veilige protocollen maken en dan wereldwijd toepassen is dus van meer afhankelijk dan een argument tegen.
Ik geloof er niets van. Je gaat mij niet vertellen dat de mensen die het cryptografische gedeelte van dit soort belangrijke protocollen ontwerpen niets van cryptografie afweten.

[Reactie gewijzigd door ArtGod op 2 juli 2018 16:02]

De 3GPP specs zijn volledig openbaar voor iedereen. Wijs maar aan welke delen door de inlichtingendiensten zijn bepaald en waar de backdoors zitten.
De 3GPP specs zijn volledig openbaar voor iedereen. Wijs maar aan welke delen door de inlichtingendiensten zijn bepaald en waar de backdoors zitten.
De truuk is dat er BEWUST onduidelijkheden worden gelaten , bijvoorbeeld het niet in de standaard op nemen van een minimum encryptie sterkte is een bekende truuk.
als er staat sha256 een combinatie van sterkte varianten was het geen probleem , ook is het mogelijk dat closed source software leveranciers zich niet houden aan minimun standaarden , door een fallback optie in te bouwen of bepaalde checks weg te laten.

[Reactie gewijzigd door bluegoaindian op 1 juli 2018 14:40]

Bewust onduidelijkheid creëren door vaag te zijn lijkt me geen oplossing. Die vaagheid en onduidelijkheid zijn juist redenen om een zwakte te vermoeden. En als iedereen die onduidelijkheid vertaald in een zwakke implementatie dan is de onduidelijkheid toch ergens heel duidelijk.
De operator kan er inderdaad voor kiezen de beveiligingsoptie die deze hack onmogelijk maakt uit te laten. Waarschijnlijk gaat met aanzetten de batterij van de telefoon sneller leeg waardoor er commercieel belang bij is om minder encryptie toe te staan.
Zodra deze hack daadwerkelijk regelmatig wordt uitgevoerd en de klanten er last van hebben is er juist weer commercieel belang om alle mogelijke veiligheden aan te zetten.
Inlichtingsdiensten van de overheden hebben sowieso al toegang tot het netwerk door middel van het zetten van een tap en nu ook door 'vangnet' afluisteren van alle verkeer dus die boeit het niet hoe sterk de encryptie vanaf het mobieltje is.
De operator kan er inderdaad voor kiezen de beveiligingsoptie die deze hack onmogelijk maakt uit te laten. Waarschijnlijk gaat met aanzetten de batterij van de telefoon sneller leeg waardoor er commercieel belang bij is om minder encryptie toe te staan.
Zodra deze hack daadwerkelijk regelmatig wordt uitgevoerd en de klanten er last van hebben is er juist weer commercieel belang om alle mogelijke veiligheden aan te zetten.
Inlichtingsdiensten van de overheden hebben sowieso al toegang tot het netwerk door middel van het zetten van een tap en nu ook door 'vangnet' afluisteren van alle verkeer dus die boeit het niet hoe sterk de encryptie vanaf het mobieltje is.
niet geheel mee eens backdoors zijn net als hoeren ze doen waar je ze voor betaald maar heb ze nooit voor je aleen....
Het is idd waar dat elk land gevorderde hacker via SS7 een ander netwerk kan afluisteren.
het telefoon is al jaren stuk.
niet geheel mee eens backdoors zijn net als hoeren ze doen waar je ze voor betaald maar heb ze nooit voor je aleen....
Het is idd waar dat elk land gevorderde hacker via SS7 een ander netwerk kan afluisteren.
Ik heb het helemaal niet over backdoors gehad en het is stukken makkelijker om een Android telefoon te hacken om een telkens een conference call op te zetten of om op een andere manier het gesprek te laten opnemen dan om een netwerk te hacken en datzelfde via SS7 te bereiken.
[...]

Ik heb het helemaal niet over backdoors gehad en het is stukken makkelijker om een Android telefoon te hacken om een telkens een conference call op te zetten of om op een andere manier het gesprek te laten opnemen dan om een netwerk te hacken en datzelfde via SS7 te bereiken.
SS7 is in elk land in de wereld beschikbaar , eenmaal op het netwerk is de sucurity zwak.
er zijn genoeg landen waar je access probleemloos kan kopen.
SS7 is in elk land in de wereld beschikbaar , eenmaal op het netwerk is de sucurity zwak.
er zijn genoeg landen waar je access probleemloos kan kopen.
En als je dan ook een SCCP global title naar je gerouteerd krijgt en MAP(M) berichten kan versturen kan je SMS spammen tot je geblokt wordt. Hoe vaak zie je dat nog?
Email wordt ontelbaar vaker gespammed daar is de security pas zwak.
Ik ben er van overtuigd dat inlichtingendiensten al jaren geïnfiltreerd zijn in standaarden comités van internet- en communicatiestandaarden om afluisteren mogelijk te maken. Er is echt geen reden waarom er wéér een zwakheid zit in een communicatie protocol (dit keer geen authenticatie, voorheen zwakke algoritmes).

In de VS hebben inlichtingendiensten de opdracht gekregen de standaardisering niet te saboteren, maar waarschijnlijk was deze standaard al gemaakt voordat dit decreet van kracht werd of ze negeren het.
Dit heeft alles van een backdoor.
Als je bewust ben ook redelijk makkelijk te omzeilen , door vpn.
openvpn zal dit meteen detecteren.
en verder openvpn zo in stallen dat aleen bij verbinding er netwerk verkeer mogelijk is , en het toestel lekt niets meer kwa internet data.
Werkt dit nog steeds met DNSSEC?
De alternatieve DNS-server liegt gewoon keihard: nee hoor, dit domein maakt geen gebruik van DNSSEC. Vrijwel geen enkel systeem gaat zelf controleren of dat klopt. DNSSEC is leuk, maar het werkt eigenlijk alleen goed als je zelf de controle hebt over de recursieve server, of deze kunt vertrouwen (inclusief de verbinding daar naartoe).
DNS over HTTPS (doh) zou dan weer wel veilig zijn, gezien hierbij geen MiTM mogelijk is zonder dat dit gemerkt wordt door de cliënt (er van uitgaand dat de cliënt certificaten controleert), juist?
DNS over HTTPS (doh) zou dan weer wel veilig zijn, gezien hierbij geen MiTM mogelijk is zonder dat dit gemerkt wordt door de cliënt (er van uitgaand dat de cliënt certificaten controleert), juist?
DNS gebruikt poort 53, HTTPS gebruikt poort 443.
Een oplossing a la RDP over SSL (remote desktop gateway) zou wel een mooie oplossing zijn, maar daar zal dan eerst weer een standaard voor moeten komen.
Vandaar DNS over HTTPS. Niet DNS-op-poort-443, maar DNS-met-HTTPS-als-transportkanaal.

Daar is gewoon een standaard voor en die heet... (tromgeroffel) DNS over HTTPS. ;)
https://en.wikipedia.org/wiki/DNS_over_HTTPS

De standaard is nog niet super populair maar wordt ondersteunt door een paar grote jongens, waaronder de DNS-servers van Google.
Ik weet niet waarom je minpunten krijgt want je hebt helemaal gelijk.
Vrijwel geen enkel systeem gaat zelf controleren of dat klopt.
DNSSEC is leuk, maar het werkt eigenlijk alleen goed als je zelf de controle hebt over de recursieve server, of deze kunt vertrouwen (inclusief de verbinding daar naartoe).
Alle systemen die ik ken die DNSSEC ondersteunen doen dat wel hoor. Toegegeven dat zijn er niet zo veel, maar ze bestaan ; ) Het wordt steeds gewoner om zelf een lokale resolver te hebben om dit probleem op te lossen. Het beetje RAM die je daar voor nodig hebt is tegenwoordig niet zo'n probleem meer.

Het blijft wachten tot MS, Google of Apple het standaard aan durft te zetten. Het aantal problemen en storingen is de laatste tijd scherp afgenomen, voor mijn gevoel is het punt wel bijna bereikt dat je het "gewoon" aan kan zetten.

Het zou snel kunnen gaan. Volgens mij hebben de meeste moderne Windows- en Linux-varianten DNSSEC ondersteuning aan boord, al staat het nog niet aan. Geen idee hoe het bij Apple zit, maar ik ga er van uit dat ze daar ook wel voorbereidingen hebben getroffen.
Lijkt mij van niet. DNSSEC maakt gebruik van een RRSIG token. De originele DNS server "signed" een DNS response. Een custom MITM DNS server, zoals te zien in het filmpje, kan een dergelijk RSIG token niet meegeven in een response en valt dan dus door de mand. Zolang het domein DNSSEC geactiveerd heeft, zou de client moeten merken.

Ik ben echter geen expert op dit gebied dus ik durf het niet met 100% zekerheid te zeggen dat clients toch gefopt kunnen worden met DNSSEC i geachakeld op het domein.

Als DNSSEC overigens wel een oplossing zou zijn, dan zou je op je telefoon ook een "DNSSEC only" policy kunnen opnemen ipv een VPN verbinding zodat je alleen nog verbinding kunt maken met websites dir DNSSEC gebruiken. De adoptie van DNSSEC is helaas nog niet heel erg goed dus of je dat nu echt zou willen doen..

[Reactie gewijzigd door Rainb0w op 1 juli 2018 11:57]

Als DNSSEC overigens wel een oplossing zou zijn, dan zou je op je telefoon ook een "DNSSEC only" policy kunnen opnemen ipv een VPN verbinding zodat je alleen nog verbinding kunt maken met websites dir DNSSEC gebruiken. De adoptie van DNSSEC is helaas nog niet heel erg goed dus of je dat nu echt zou willen doen..
DNSSEC-only is inderdaad een beetje te veel gevraagd, maar "gewoon" DNSSEC heeft dat niet nodig. Zoals je al aangeeft zal de client detecteren dat er iets aan de hand is en weigeren om het gemanipuleerde antwoord te accepteren. Je krijgt dan gewoon helemaal geen verbinding. Een beetje slimme resolver zal het trouwens via verschillende routes proberen. Wat dat betreft heeft het een flink voordeel op traditioneel DNS dat gewoon het eerste het beste antwoord accepteert.
Dat was ook wat ik me afvroeg. Maar aangezien de dns dan bij de root server gesigned wordt, lijkt het me dat het domein dan niet zal werken - mits de provider hier op controleert en dnssec daadwerkelijk ingesteld is voor het domein.
Helaas...…..
DNSSEC gaat er van uit dat het certificaat klopt.
Als de MITM/hacker/agency echter een root*.* certificaat/fake_authority gebruikt gaat het fout. Het probleem van PKI/X standaarden is dat het ontworpen is voor de veilige telecom infrastructuur, het gebruik op een onveilig IP netwerk vereist vele extra's die soms wel of niet aanwezig zijn op je telefoon/PC.
De meeste telefoons en computers gaan op zoek naar de makkelijkste weg, en kiezen standaard DNS als DNSSEC niet lukt.
Probeer een VPN op te zetten met een goede App zoals PIA en je voorkomt veel van bovenstaande problemen,
Helaas...…..
DNSSEC gaat er van uit dat het certificaat klopt.
Als de MITM/hacker/agency echter een root*.* certificaat/fake_authority gebruikt gaat het fout. Het probleem van PKI/X standaarden is dat het ontworpen is voor de veilige telecom infrastructuur, het gebruik op een onveilig IP netwerk vereist vele extra's die soms wel of niet aanwezig zijn op je telefoon/PC.
Volgens mij is dat precies hoe het hoort. Als iemand een/het certificaat vervalst dan krijg je geen verbinding.
De meeste telefoons en computers gaan op zoek naar de makkelijkste weg, en kiezen standaard DNS als DNSSEC niet lukt.
Oh, welke? Tenminste, van de systemen die ik ken die out-of-the-box DNSSEC doen werkt er niet één zo. Technisch gezien werken alle systemen die DNSSEC niet ondersteunen zo, maar goed.

Als dat echt zo is dan is het natuurlijk een domme keuze. Op die manier heeft geen enkele beveiliging zin.
Zo iets kun je even doen tijdens de invoering, maar een productiesysteem zou je nooit zo moeten configureren.
Verder ken ik nog wel dnssec-trigger maar dat is een gespecialiseerde tool voor mensen die weten wat ze doen.
International Mobile Subscriber Identity catchers (IMSI) en dan het toestel besnuffelen die je te pakken hebt. Met 2G is dit enorm makkelijk en gelukkig kun je dit uitschakelen op BlackBerry en Android os. Op Apple ios gaat dit helaas niet, maar advies is dan om 2G netwerk uit te schakelen en te kiezen voor 3/4G welke beter beveiligd is mits je toestel beveiligd is met de laatste security updates en hierdoor duidelijk een beveiligd netwerk pakt.

Dit is waarom BlackBerry encrypted calls heeft met secusmart en samenwerkt met samsung en hierbij samsung KNOX mee kan beveiligen via mobile toestellen en tablets als het gaat om bellen en data. Zo zijn er alleen al in Duitsland 12.000 mensen binnen de overheid die op deze manier bellen. Een hele manier om je device te beschermen tegen spoofers en vooral in het buitenland.

[Reactie gewijzigd door Noresponse op 1 juli 2018 12:23]

Ik kan helaas op mijn toestel niet 3G+4G only doen. In Nederland is dat ook (nog) niet handig, behalve als je op Tele2 of T-Mobile zit. KPN en vooral Vodafone hebben nog wat plekjes waar alleen 2G is.
Je hebt hier niet zozeer speciale devices voor nodig. Als ik een telefoongesprek voer via Whatsapp of Signal, dan is dat ook e2e encrypted. Alles gaat dan over de dataverbinding en hooguit kan de versleutelde stream afgeluisterd worden. Zonder de juiste keys heb je daar echt helemaal niets aan.

Dat gezegd hebbende, "gelukkig" hebben mensen ongetwijfeld andere apps die toegang tot de microfoon hebben. De gehele beveiliging is zo sterk als de zwakste schakel, dus ik vermoed dat - als je een doelwit bent - inlichtingendiensten toch wel mee kunnen luisteren.
Je hebt hier niet zozeer speciale devices voor nodig. Als ik een telefoongesprek voer via Whatsapp of Signal, dan is dat ook e2e encrypted. Alles gaat dan over de dataverbinding en hooguit kan de versleutelde stream afgeluisterd worden. Zonder de juiste keys heb je daar echt helemaal niets aan.

Dat gezegd hebbende, "gelukkig" hebben mensen ongetwijfeld andere apps die toegang tot de microfoon hebben. De gehele beveiliging is zo sterk als de zwakste schakel, dus ik vermoed dat - als je een doelwit bent - inlichtingendiensten toch wel mee kunnen luisteren.
facebook en messenger zo snel mogelijk verwijderen en omzetten naar een app als metal.
Wacht even, ik had juist verwacht dat dat met Apple (iOS) zou werken.
Of lees ik het verkeerd?
Dan moet je dat dus wel in iedere request aanpassen, lijkt me niet echt te doen. Je kunt beter verkeer volledig afvangen omrouteren via een ander netwerk, heb je alles in één keer gecoverd.
4000 dollar? De hackRF one is al voor 500 euro met antenne te koop..
Een hoop moeite voor weinig gain. Nier echt intetessant voor doorsnee criminelen of zelfs maar overheidsdiensten (maargoed, die laatste doen het dan gewoon rechtstreeks via de provider).
Het wordt tijd dat we allemaal eens overschakelen naar Secure DNS.
Helaas...…..
Secure DNS gaat er van uit dat het certificaat klopt.
Zie mijn reactie boven van 7:59
Voor de aanvallen geldt een maximale afstand van 2 kilometer en een paar duizend euro aan apparatuur is vereist.
Dit lek lijkt me een big deal, zeker in grote steden. Aangezien ik alles via 4G doe, toch maar overwegen om weer een vaste verbinding te nemen en/of een VPN server op te zetten.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True