Security Professionals
- ipfw add deny all from eindgebruikers to any
TCP DDoS mogelijk door non-conforme firewalls/netwerk apparatuur
Nieuw onderzoek, heel vervelend nieuws: https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
Reacties (5)
Man man man dit is al zoooooo oud!
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
Door ej__: Nieuw onderzoek, heel vervelend nieuws: https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
Het feitelijke paper :
https://www.usenix.org/system/files/sec21fall-bock.pdf
Wel een hoop randvoorwaarden - het gaat om firewalls (ze noemen vaak nation states, oftewel great firewall of china e.d.) die een HTTP block injecteren in een sessie *ook als ze maar de halve tcp sessie zien* .
(en de bron als clickable link - mensen, leer die URL tags ... https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/ )
Als hyperlink:
https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/
Waarom doe je die kleine moeite niet even? Je wilt toch dat mensen kennis nemen van dat artikel?
https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/
Waarom doe je die kleine moeite niet even? Je wilt toch dat mensen kennis nemen van dat artikel?
Door Anoniem: Man man man dit is al zoooooo oud!
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
Ik zou zeggen: verdiep je eerst eens in het artikel, en kom dan tot de conclusie dat het iets heel anders is dan jij denkt. Het gaat om een reflection, dus het sequence number is irrelevant voor degene waar het antwoord naar toe wordt gestuurd. Het gaat om network devices die zich NIET aan de standaarden houden, en een antwoord sturen ZONDER de tcp handshake. Voorbeeld: the Great Firewall of China. Prima te misbruiken voor een volumetrische tcp DDoS waarvan jij denkt dat die niet kan vanwege juist die standaard tcp handshaking.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
