Aanvallers stelen wachtwoorden via lek in MySQL-tool Adminer
Aanvallers maken misbruik van een beveiligingslek in Adminer, een populaire tool voor het beheren van MySQL- en PostgreSQL-databases, om wachtwoorden van webwinkels te stelen. Dat laat de Nederlandse beveiligingsonderzoeker Willem de Groot in een analyse weten.
Om de wachtwoorden te kunnen stelen moeten aanvallers een open Adminer-installatie van het slachtoffer verbinding met een kwaadaardige MySQL-server laten maken. "Dit is niet lastig, aangezien veel mensen het in de root van hun website installeren", aldus De Groot. Adminer maakt dan verbinding met de kwaadaardige servers. De aanvallers vragen Adminer om een specifiek bestand dat het wachtwoord van geïnstalleerde applicaties gaat. Het gaat dan bijvoorbeeld om webwinkels die op het Magento-platform zijn gebaseerd, of WordPress-websites.
De kwetsbaarheid zou al sinds augustus 2018 bekend zijn. De Groot laat weten dat de aanvalsmethode al op z'n minst sinds oktober 2018 door criminelen wordt gebruikt. Destijds had de onderzoeker nog niet door wat er precies plaatsvond. Wel zag hij dat criminelen het lek gebruikten om op verschillende grote webwinkels een skimmer te injecteren die creditcardgegevens van klanten opving en terugstuurde.
De Groot merkt op dat hij Adminer versie 4.3.1 tot en met 4.6.2 heeft getest en al deze versies zijn kwetsbaar. Adminer versie 4.6.3, die vorig jaar juni verscheen, blijkt niet kwetsbaar te zijn. "Het is onduidelijk of het beveiligingslek opzettelijk is verholpen of per ongeluk, aangezien Adminer geen beveiligingsupdate vermeld", aldus de onderzoeker. Beheerders krijgen het advies om naar de laatste versie (4.7.0) te upgraden en toegang tot de database via een extra wachtwoord of ip-filter te beschermen.
Lekken komen in iedere programmeertaal voor, het is afhankelijk van de programmeur.
Wat een misvatting dat er geen verschillen zouden bestaan in de syntax van een bepaalde taal.
Is babel niet beter als plain javascipt voor specifieke toepassingen.
Daarnaast telt ook de interactie met de omgeving.
Denk aan de specifieke DOM-XSS ellende met bijvoorbeeld bootstrap.js en min.js etc.
Ook het voortduren van deze kwestbaarheden, nadat het ontwerpersteam het doortrok naar de volgende versie 3.0.4
Zie: https://snyk.io/vuln/npm:bootstrap:20180529 -
Gecompromitteerde websites kunnen vaak gelinkt worden met kwaadaardig script & het kan reeds fout gaan bij niet juist toepassen van installatiescripts.
Voorbeeldje af te voeren bibliotheek -> http://turkeytoday.org/media/jui/js/jquery.min.js?939b0ef64cfbe0ecf88c0a66e2818945
jQuery versions with known weaknesses
Bug 9521 - $("#<img src=x onerror=...>")
Bug 11290 - $("element[attribute='<img src=x onerror=...>'")
jQuery issue 2432 - 3rd party $.get() auto executes if content type is text/javascript
jQuery issue 11974 - parseHTML executes inline scripts like event handlers (uit de dagen van pre-HTML javascript).
Bij gepatchte code en niet toegevoegde extra hardening door middel van extra security maatregelen,
moet het sein veilig altijd nog weer getoetst worden.
Daar doen mindere en beter coderende developers helaas niets aan af en toe.
Brendan Eich bijvoorbeeld heeft zelf toegegeven, wat persistente ad-tracking van grote Big Tech Data Miners allemaal al voor ellende t.a.v. JavaScript heeft gebracht. Niet iedereen is er van op de hoogte dat zelfs het pre-loaden van webpagina's niet volgens de regels gebeurt, maar om Google chrome beter af te schilderen tegenover andere browsers.
Tot het moment dat zulk soort zaken openbaar worden aangekaart, gaan men ermee door.
Men past zich steeds aan als een kameleon. Nu gaan de pagina's pas te zien zijn als ze geheel geladen zijn.
Niet hoog tijd om het eens gezamenlijk structureel en fundamenteel aan de tand te voelen,
en dan "call a spade a spade". Waarom gebeurt dat dan maar zo mondjesmaat.
luntrus
Aanvaller moeten eerst een kwetsbare "open" adminer.php zien te vinden.
Fluitje van een cent via een shodannetje etc.
Opnieuw php, nu rond lekkende wachtwoorden. Het houdt maar niet op.
# sockpupet
Het is een prima taal om code zoals een website in te schrijven.
PHP 7.4 zal zelfs Java onder druk zetten (nee, niet javascript).
JavaScript was ook als een hobby taaltje begonnen door een enkele persoon, wat nu uitgegroeid is tot een volwaardige taal, zie NodeJS wat veel sprongen gemaakt heeft.
Zelf ben ik een voorstander voor PHP, Python (PyPy vanwege doei doei GIL of Cython) en C++.
Voor de rest, Java is een draak van een programmeer omgeving, veel resources nodig wat veelvuldig vaak niet nodig is.
Anyway, Symfony/Laravel is zeer populair de laatste tijd onder web and API programmeurs, dus ik zie het probleem niet.
phpMyAdmin nooit meer gebruikt sinds ik via MySQL command line alles kan doen.
Daarnaast, werkt HeidiSQL ook prima, via een VPN connecten naar de server, en de rest firewallen, klaar...
Maar met het blootleggen van kwetsbaarheden op een website CMS moet je wel blijvend doorspitten.
Vergelijk de algemene scan hier https://retire.insecurity.today/#!/scan/b2730c739adb8993201689359cdf96726cabc4186695df06b2bfc6221a3494d7
met de scan voor jquery.min.js/JSTag_1[c8fd][b28e] ,die we aanvankelijk niet hebben meegenomen.
Vervolgens blijkt die ook kwetsbaar, zie:
https://retire.insecurity.today/#!/scan/7187586fc2d44df7e5693019bd9efadbcd8530630d21e8eec7986cfba644e704
Vooral php-gebaseerd CMS (Magento, Word Press, Joomla) in de handen van degenen, die code-security niet voldoende op het netvlies hebben, alsmede het toepassen van een verhoogde beveiligingsgraad door het toepassen van zogeheten "best policies" vaak achterwege laten.
Dan hebben we het nog niet eens gehad in het bovenstaande geval over de DOM-XSS sources & sinks in de gebruikte script en bibliotheken, respectievelijk voor de onderhavige 41 sources en 17 sinks. Die leveren stuk voor stuk natuurlijk niet allemaal een toepasbare exploit/bug op, maar desalniettemin. Ik zie er te weinig oog voor en ik zie het ,vooral bij amateurs, teveel ellende opleveren.
In hoeverre php-code op zich inherent onveilig is blijft natuurlijk onderwerp van discussie. Af te voeren PHP code vormt altijd een risico, maar soms zit je met verplicht backporten. Met het voortdurend moeten checken van de code op bijvoorbeeld een
#sockpuppet
phpAdminer zou het in dat geval heten. Ik denk dat ze twee vliegen in een klap hebben geslagen en meteen hebben onderschoffeld dat het tooltje in PHP is geschreven.
Een 'mooie universe programmeertaal'? Weet je eigenlijk wel wat je schrijft? Natuurlijk wordt PHP veel gebruikt want het is goedkoop. De resulterende technical debt van al dat PHP-gebruik is voor ons allemaal een groot probleem.
Die misvatting is wijdverbreid. De programmeur heeft natuurlijk invloed, echter als je het echt wilt verklooien moet je de verkeerde programmeertaal gebruiken. Of erger nog, een taaltje dat helemaal niet is bedoeld voor serieus werk in professionele toepassingen. Omdat het goedkoop is en omdat jij de technical debt toch niet zelf hoeft op te lossen.
#sockpuppet
Ik denk dat je 'polariserend' bedoelt. Want ik wil zeker niet PHP populariseren. Voor de rest ben ik het met je eens. #sockpuppet ;-)
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.
Technisch Consultant Cyber Security
Zijn ontwerpen en implementaties op het gebied van next-gen firewalls, IPS, DLP, antivirus, antispam en WAF producten dagelijkse kost voor jou? Dan heeft Axians de uitdaging van je leven en dit bij de meest toonaangevende opdrachtgevers.
Challenge Developer
Wil je werken bij het beste securitybedrijf van Nederland en je coding skills in te zetten voor het ontwikkelen van de latest en greatest security challenges? Een Certified Secure challenge developer is een coder, een échte. Je snapt dat syntax niet het probleem is en dat de uitdaging van coding ligt in het zoeken naar de meest efficiënte oplossing en het cleanste design.