SSH-experiment levert interessante wachtwoorden op
Een experiment waarbij een beveiligingsonderzoeker zijn SSH-server bewust liet aanvallen, heeft een aantal interessante trends en wachtwoorden opgeleverd. Servers waarbij gebruikers via SSH kunnen inloggen zijn een geliefd doelwit van aanvallers, die via brute force-aanvallen allerlei combinaties van gebruikersnamen en wachtwoorden proberen. Beveiligingsonderzoeker Steven Murdoch wilde zien wat voor soort aanvallen en woordenboeken de aanvallers gebruiken.
De meeste aanvallen die Murdoch in zijn experiment waarnam waren "saai", zoals hij het zelf omschrijft. Het gaat dan om zwakke, veel voorkomende wachtwoorden zoals 1234 en password, in combinatie met een beperkt aantal gebruikersnamen. Ook detecteerde hij pogingen op een groot aantal accounts die mogelijk zouden kunnen bestaan, maar per account werd slechts een klein aantal wachtwoorden geprobeerd.
FreeBSD
Toch waren er ook verschillende interessante aanvallen, merkt Murdoch op. Het gaat dan om wachtwoorden als “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, en “kx028897chebeuname+a”). Die zijn waarschijnlijk via een ongehashte wachtwoordendatabase of getrojaniseerde SSH-server of client verzameld. Andere vreemde pogingen bestonden uit platte en gesalte hashes en zelfs bestandsnamen kwamen langs.
Dat laat zien dat sommige aanvallers niet om de kwaliteit van hun wachtwoordendatabase geven en wachtwoorden die zinloos zijn om te gebruiken gewoon laten staan, stelt de onderzoeker. Verder ontving hij veel inlogpogingen, maar geen wachtwoorden, omdat de standaard FreeBSD configuratie alleen keyboard-interactive authenticatie ondersteunt, in plaats van de beperktere wachtwoord-authenticatie.
Hostname
Eén aanval die Murdoch nog nooit had gezien was het gebruik van gebruikersnamen en wachtwoorden gebaseerd op de hostname van de machine. "Dit was duidelijk geen woordenboek, maar zelfontwikkelde code die een reverse DNS-lookup van de host deed en dan mogelijke wachtwoorden genereerde. Murdoch adviseert gebruikers om sterke wachtwoorden te kiezen en niet via wachtwoorden op het root-account in te loggen, aangezien dit de meeste aanvallen kan voorkomen.
Beter nog:
-Inloggen met wachtwoorden en op basis van hostname e.d. uitschakelen en alleen met sleutels werken.
-Verder kan je ook aangeven welke gebruikers er mogen inloggen.
-Root toegang verbieden (zoals Murdoch zegt)
-In de firewall aangeven vanuit welke ip-adressen er een verbinding naar de ssh daemon mag worden opgezet.
-Uiteraard de ssh daemon wanneer nodig updaten!
Dit is het meest interessante onderzoek waar we iets over kunnen melden, mijn god... nee, niemand heeft dit eerder onderzocht... state of the art research!
Gebruik key plus wachtwoord!
oh wacht.....
http://blog.sucuri.net/2010/01/honeypot-analysis-looking-at-ssh-scans.html
normaal is het zo iets als MD5( $pass), maar met Salt MD5($pass + $salt), de waarde van Salt is willekeurig en brute forcen is bij een onbekende salt dus niet mogelijk, tenzij andere mogelijkheden van die hash heel toevallig gebruteforced zijn.
zo zou ik theorie de hash van bijvoorbeeld: askulhaJKLHFA7&#uear5uioah8 hetzelfde kunnen zijn als de hash van LIYG7fd, wat iets makkelijker te brute forcen is.
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.
