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
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Operational Technology Security Officer
Onze trams rijden altijd veilig. Dankzij jouw waterdichte Cyber Securitybeleid. Jouw werk als Operational Technology Security officer heeft een enorme impact. Op de RET en op de mensen die wij vervoeren. Jij gaat namelijk over de veiligheid van onze technische automatisering ofwel OT infrastructuur.
Adviseur Informatiebeveiliging en Privacy
College ter Beoordeling van Geneesmiddelen
Als Adviseur Informatiebeveiliging en Privacy werk je voor de CISO en maak je onderdeel uit van een klein team Informatiebeveiliging en Privacy (IB&P) binnen de afdeling IV. Het IB&P-team is verantwoordelijk voor de beveiliging van informatie en informatie-systemen en het waarborgen van privacy binnen het CBG.