Security Professionals - ipfw add deny all from eindgebruikers to any

Poort 5555 scan door allerlei system zelfs 8.8.8.8

01-04-2020, 14:04 door Anoniem, 10 reacties
Ik zie een flink aantal scans naar TCP poort 5555 vandaag, en deze komen zelfs vanaf adres 8.8.8.8
Kennelijk is er weer iets uitgebroken waar alle wannabe portscanners als vliegen op de stroop op af komen,
maar wat het is is lastig te bepalen omdat er vrij veel services dit "mooie poortnummer" in gebruik genomen
hebben.
Echter dat er zelfs scans (TCP SYN) komen vanaf adres 8.8.8.8 dat is wel opvallend. Het kan natuurlijk
gespoofed zijn, maar wat zou dat voor zin hebben? Zou google tegenwoordig ook in de "met smoes dat
het goed bedoeld is scannen van het hele internet voor een searchable database" manie gedoken zijn?
En zouden ze dan niet beter een ander source adres kunnen gebruiken?
Reacties (10)
01-04-2020, 16:06 door Anoniem
Aanvulling: het lijkt wel een worm. Ik heb een lijst met IP adressen verzameld met aantal pogingen en het overgrote
deel bestaat uit adressen die maar 1 poging doen. Daarnaast zijn er natuurlijk ook die meerdere pogingen doen, en
8.8.8.8 zit daar bij maar is lang niet de koploper.
01-04-2020, 17:09 door Anoniem
Zeer geachte topic-starter,

Twee opmerkingen aangaande dit soort scans:
https://www.experts-exchange.com/questions/22726184/Port-5555-is-open.html

Het scannen is naar een Android Device Debug Poort:
https://www.bleepingcomputer.com/news/security/tens-of-thousands-of-android-devices-are-exposing-their-debug-port/
Zie: https://www.shodan.io/search?query=Android+Debug+Bridge+port%3A5555&language=en

Met die duizenden Google Propriety Android apparaten en IoT-zooi niet vreemd, ook op 8.8.8.8.

-> https://www.shodan.io/host/8.8.8.8/raw
Men wil dus contact maken met een openstaande ADB poort om te kunnen "rooten".
Waarom - namelijk om een Miner worm te installeren en soortgelijk ongewenste zooi.

Disablen dus: http://www.hacktabs.com/enable-disable-adb-wifi-rooted-non-rooted-android/

groetjes,

luntrus
01-04-2020, 17:11 door Anoniem
Voeg aan je firewall een DROP statement toe aan alles wat je niet wilt.
01-04-2020, 18:00 door Erik van Straten
Door Anoniem: Ik zie een flink aantal scans naar TCP poort 5555 vandaag
Misschien een nieuwe Mirai variant? Uit 2018: https://isc.sans.edu/diary/Worm+%28Mirai%3F%29+Exploiting+Android+Debug+Bridge+%28Port+5555tcp%29/23856

Sans ziet overigens geen spike: https://isc.sans.edu/port.html?port=5555.

Door Anoniem: Echter dat er zelfs scans (TCP SYN) komen vanaf adres 8.8.8.8 dat is wel opvallend. Het kan natuurlijk gespoofed zijn, maar wat zou dat voor zin hebben?
Bedrijven die 8.8.8.8 als (backup) DNS server hebben ingesteld, zouden pakketjes vanaf dat adres wel eens door kunnen laten (immers, grotere DNS replies gaan via TCP). Maar hoe de aanvallers dan zien of er iets reageert en zo ja wat, snap ook ik niet. Tenzij ze al verder in jouw infrastructuur zijn binnengedrongen natuurlijk.

Nb. Mocht je een Draytek router gebruiken, voor een aantal exemplaren daarvan zijn er exploits die netwerkverkeer sniffen in die router. Dergelijke kwetsbaarheden zouden natuurlijk ook in routers van andere merken kunnen zitten.
01-04-2020, 19:01 door Anoniem
Door Anoniem: Voeg aan je firewall een DROP statement toe aan alles wat je niet wilt.

Dat is toch wel één van de foutere antwoorden die ik hier had verwacht.

Je antwoord had natuurlijk moeten zijn, DROP alles en ALLOW alleen het verkeer wat je toe wilt staan.
Zowel inkomend als uitgaand.
01-04-2020, 19:47 door Anoniem
Kijk anders eens op Greynoise:
https://viz.greynoise.io/query/?gnql=port%3A5555
01-04-2020, 19:49 door Anoniem
Inmiddels is het me opgevallen dat deze "scans vanaf 8.8.8.8" binnenkomen met verschillende MSS waardes, geen
van allen de verwachte 1460 voor een dergelijke host. Vaak 1452 maar ook kleinere waarden.
Dit geeft een beetje de hint dat het inderdaad een nieuwe versie van de Mirai bot zou kunnen zijn (die 2 jaar geleden
hiermee het nieuws haalde) en dan op routers die achter PPPoE zitten.
Het zou kunnen dat die worm soms 8.8.8.8 als source adres gebruikt (niet 8.8.4.4. trouwens) en dat de routers die bij
zo'n lame ISP zitten die geen source adres filtering doet dit dan doorlaten.
Niet om andere routers te infecteren natuurlijk, want dat werkt niet op deze manier. Als ik deze connecties zou accepteren
zou het antwoord immers naar google gaan... ik heb overigens ook wel eens gezien dat dergelijke truukjes gebruikt
werden voor een DDoS, maar dan werd een normaal gangbare poort zoals 80 of 443 gebruikt. Een SYN sturen met een
gespoofed adres en hoppa, het slachtoffer gaat een serie SYN ACKs sturen naar het "slachtoffer van de DDoS".
Maar ik denk niet dat iemand er in gelooft dat je op deze manier Google kunt DDoSen dus dat is het vast niet...

Hoe ik er achter kwam dat dit probleem er was (terwijl ik echt niet de hele dag in logjes of traces zit te kijken) dat laat
ik graag als raadsel en ter overdenking over aan de mensen hier die wel eens gedacht hebben aan maatregelen
tegen poortscanners!
02-04-2020, 07:54 door Anoniem
Door Anoniem:
Door Anoniem: Voeg aan je firewall een DROP statement toe aan alles wat je niet wilt.

Dat is toch wel één van de foutere antwoorden die ik hier had verwacht.

Je antwoord had natuurlijk moeten zijn, DROP alles en ALLOW alleen het verkeer wat je toe wilt staan.
Zowel inkomend als uitgaand.

Potato, potatoe, same thing. Lost in language.
02-04-2020, 11:43 door Erik van Straten
Door Anoniem:
Door Anoniem:
Door Anoniem: Voeg aan je firewall een DROP statement toe aan alles wat je niet wilt.

Dat is toch wel één van de foutere antwoorden die ik hier had verwacht.

Je antwoord had natuurlijk moeten zijn, DROP alles en ALLOW alleen het verkeer wat je toe wilt staan.
Zowel inkomend als uitgaand.

Potato, potatoe, same thing. Lost in language.
Onjuist. Te vaak heb ik initialisatiescripts voor iptables gezien met daarin een aantal DROP of REJECT statements, zonder dat de default policy was aangepast, en zonder dat de lijst eindigde met "DROP de rest". Da's blacklisten en vaak niet effectief voor een doortastende aanvaller, vooal niet als deze via een e-mail bijlage van binnenuit verbindingen naar buiten wil maken (bijv. met een C&C server).

De meeste packet-based-firewalls hebben een lijst van regels (zowel voor input als voor output, en mogelijk ook voor forward) die ze tegen elk netwerkpakketje aanhouden. Bij een match wordt die regel uitgevoerd en is de firewall klaar. Als een regel niet matcht wordt de volgende regel geprobeerd, totdat alle regels zijn afgehandeld. Als er geen match was, bepaalt de default policy wat er met het pakketje gebeurt. Voor iptables/netfilter (en, als ik me niet vergis, ook voor pf) is dat ALLOW - met andere woorden: verwerk het pakketje alsof er geen firewall bestond.

De vermoedelijke reden dat dit zo vaak fout gaat is dat configureerders niet goed snappen hoe packet-based firewall rules werken (dat is, toegegeven, ook best lastig). Voor je het weet heb je geen verbinding omdat retourpakketjes worden geblokkeerd. En als je remote werkt (bijv. via ssh) kan het uitvoeren van 1 DROP regeltje ervoor zorgen dat je in de auto moet stappen en op locatie de boel moet fixen... (eerst op een lokaal systeem testen dus).

Zie bijv. https://www.openbsd.org/faq/pf/filter.html#defdeny en http://linux-training.be/networking/ch14.html#idp69772096.
02-04-2020, 12:19 door Anoniem
Het scannen vanaf 8.8.8.8 gaat nog door. Ik dacht nog even aan een 1-april grap maar dat is het kennelijk ook niet.
En nee, het gaat me niet om hoe ik dit kan blokkeren. Dat is de vraag helemaal niet. Alles wordt default geblokkeerd
door de juiste rule aan het eind van iedere tabel. Mijn vraag/discussie is "wat is er hier gaande" en misschien zit ik
ook wel een beetje te wachten op mensen die door dit grapje een probleem gehad hebben met hun "slimme firewall"
en zich nu realiseren dat het toch niet zo slim was wat ze deden. (ik had geen probleem, ik wist dat al, het viel alleen op)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.