Magento-webshops bewaarden mislukte inlogpogingen klanten in plaintext
Een beveiligingslek in de zeer populaire webwinkelsoftware Magento zorgde ervoor dat mislukte inlogpogingen van klanten in plaintext in de database werden opgeslagen. Hoewel het probleem inmiddels is verholpen zijn de opgeslagen gebruikersnamen en verkeerde wachtwoorden nooit verwijderd.
Daarvoor heeft Adobe, dat de Magento-webwinkelsoftware onderhoudt, een hotfix uitgebracht. Vorig jaar oktober kwam Magento met een beveiligingsupdate voor een kwetsbaarheid waardoor mislukte inlogpogingen van klanten zoals gezegd in plaintext werden opgeslagen. Een aanvaller met toegang tot de database zou op deze manier het juiste wachtwoord van gebruikers kunnen afleiden.
De beveiligingsupdate zorgde ervoor dat Magento mislukte inlogpogingen niet meer in plaintext bewaarde. Al opgeslagen inlogpogingen bleven echter gewoon in de database achter. Daarvoor is nu een hotfix verschenen, die al deze inlogpogingen verwijdert. "De informatie zou alleen toegankelijk zijn wanneer de webwinkel op een andere manier was gecompromitteerd. Desondanks raden we aan om de update zo snel als mogelijk te installeren", aldus het Magento Security Team.
#WebAuthn
Om ook iets inhoudelijker te reageren ben ik dit ook nog wel eens tegen gekomen. Het loggen hoeft zeker niet bewust te gebeuren. Wanneer je bijvoorbeeld naam en wachtwoord naar een API stuurt en hierbij niet opmerkt dat deze in de URL staan. In tegenstelling tot een POST body, zijn ze dan terug te vinden in standaard webserver logs. Daar zit dan geen kwade intentie achter, maar het is wel slordig en zorgt er voor dat wachtwoorden minder goed beschermd zijn dan wanneer deze gehashed worden.
Die zijn er al lang. zie b.v. https://en.wikipedia.org/wiki/Digest_access_authentication
Mijn IP cameras gebruiken deze inlogmethode en ook mijn Synology nas. Het wachtwoord word lokaal gehashed via een JS en de server ontvangt alleen de hash en ziet het wachtwoord nooit. Het geheel wordt zelfs nog een keer gehashed met de session cookie.
Dus uiteindelijk dubbel gehashed zodat je er niets aan hebt als dit door een fout in het log zou komen.
Die zijn er al lang. zie b.v. https://en.wikipedia.org/wiki/Digest_access_authentication
Mijn IP cameras gebruiken deze inlogmethode en ook mijn Synology nas. Het wachtwoord word lokaal gehashed via een JS en de server ontvangt alleen de hash en ziet het wachtwoord nooit. Het geheel wordt zelfs nog een keer gehashed met de session cookie.
Dus uiteindelijk dubbel gehashed zodat je er niets aan hebt als dit door een fout in het log zou komen.
Mijn punt ten aanzien van een secret-key gebaseerde authenticatie methode dat geldt ook voor digest access authentication. Of het wachtwoord nu 1 of 2 keer gehashed wordt, wanneer er een hash is valt deze te kraken middels brute force aanvallen. Sinds jaar en dag is bekend dat veel wachtwoorden niet sterk (lang en willekeurig) genoeg zijn en hergebruikt worden op meerdere sites. Dat is fundamenteel het probleem en wordt bij het gebruik an digest authenticatie niet opgelost. Met digest authenticatie voorkom je wel dat een wachtwoord per ongelukt in plaintext opgeslagen kan worden ergens aan de server kant.
De echte oplossing is dus om gebruik te maken van digitale handtekeningen (SSH authenticatie, TLS client certificates, WebAuthn) omdat een server dan alleen publieke informatie hoeft te bewaren.
Er zijn genoeg systemen waar je in de log dit soort dingen kunt vinden:
Failed password for root from .....
Dat is ook slecht want als je per ongeluk het password tikt ergens waar de user gevraagd wordt dan wordt
dit ook gelogd. Dus als er ineens iets staat van:
Failed password for idYdYtaEs3uC from ...
dan kun je er donder op zeggen dat dit het password van een van de gebruikers is.
Waarschijnlijk de gebruiker die direct daarna wel succesvol inlogt.
#WebAuthn
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.
