Blog

Malware detecteren in een MySQL-database

Een kwaadwillende gebruiker kan kwetsbaarheden vinden die de MySQL-database van een organisatie misbruiken. Het monitoren van databaseactiviteit zou dus een kernpraktijk van elk bedrijf moeten zijn. Hackers ontketenen aanvallen die zijn ontworpen om vertrouwelijke gegevens te stelen en hun primaire doelwit zijn de MySQL-databaseservers van een organisatie. Databases staan bekend als een van de meest gecompromitteerde activa.

Waarom wordt de database zo vaak getarget? Eenvoudig: de database is het hart van elke organisatie die klantrecords en andere vertrouwelijke bedrijfsgegevens opslaat. Organisaties geven de minste prioriteit als het gaat om het beschermen van deze cruciale activa.

Zodra hackers en kwaadwillende insiders toegang krijgen tot gevoelige gegevens, is hun volgende stap om snel waarde te extraheren, schade op te leggen of de bedrijfsvoering te beïnvloeden. Behalve financieel verlies of reputatieschade, leiden inbreuken ook tot overtredingen van de regelgeving, boetes en juridische kosten, enz.

Laten we eens kijken naar de onderstaande casestudy, waarin een klant miljoenen dollars heeft verloren door kwaadwillende activiteiten in hun database:

Casestudy

Bedrijfsnaam: Capital One

Koppeling: https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html

Probleem:

Capital One bank lijdt een van de belangrijkste verliezen van 150 miljoen als gevolg van een kwetsbaarheidsaanval.

Gevolg:

Een software-engineer en een voormalige medewerker van de Capital One-bank hebben de server van het bedrijf gehackt en daarbij klantgegevens opgeslagen en persoonlijke gegevens van meer dan 100 miljoen mensen gepocheerd. Amazon Web Services host de klantendatabase en overigens was de engineer eerder ook werkzaam bij Amazon.

Volgens de rechtbank en Capital One heeft de hacker 140.000 burgerservicenummers en 80.000 bankrekeningnummers gestolen. Naast de tientallen miljoenen creditcardaanvragen werden ook geschonden. De diefstal bracht een miljoen Canadese burgerservicenummers in gevaar, die gelijk zijn aan de burgerservicenummers voor de Amerikanen. Het bereik van gestolen gegevens was al in het jaar 2005 en de laatste in het jaar 2019.

De bank verstrekte de verklaring dat zij verwachtte dat de inbreuk haar tot $150 miljoen zou kosten, inclusief het betalen voor kredietbewaking voor getroffen klanten. De inbreuk was mogelijk omdat er een kwetsbaarheid open was in hun firewall en de hacker gemakkelijk toegang had tot de gehoste database in AWS.

Als voormalig werknemer bij AWS werd de kwetsbaarheid goed uitgebuit om de database te hacken en de klantgegevens te manipuleren. Mogelijke knowhow over hoe de kwetsbaarheid mogelijk is gebruikt.

Zoals we weten, worden databases gebruikt om alle klant- en transactiegegevens op te slaan. De hacker manipuleerde de database door gegevens toe te voegen / te verwijderen of zelfs uit de bankdatabase te halen.

Als ze de juiste beveiliging hadden gehad om deze database te bewaken, wat kan worden gedaan met het Zmanda ZRM-product, zou een dergelijke bedreiging kunnen zijn gedetecteerd en proactief kunnen worden gestopt. De bank heeft de kwetsbaarheid verholpen en beschikt nu over strengere methoden om dergelijke fraude te bestrijden.

Schadelijk detecteren MySQL-databaseactiviteit met behulp van Zmanda

De organisaties dienen een meerlagige strategie voor de beveiliging van databanken te hanteren. Met de toepassing van best practices kan het risico op gegevensblootstelling door verschillende aanvalsvectoren op een verstandige manier worden verminderd. Zo kan Zmanda kwaadaardige activiteiten detecteren vanuit databaseback-ups

ZRM voor MySQL slaat binaire MySQL-logboeken op als onderdeel van de databaseback-ups. De binaire logboeken bieden een goed controlespoor van alle database-activiteit. ZRM voor MySQL binair maakt gebruik van de mogelijkheid om logboeken te parseren voor een bepaald tijdstip in de tijdherstel, waarbij kwaadaardige databaseactiviteit wordt gedetecteerd met behulp van SQL-inspectie.

Met de ZRM voor MySQL-plug-ininterface kunnen DBA's (Database Administrator) log-parser-plug-inscripts schrijven om specifieke / alle database-activiteit bij te houden en te bewaken. De volgende code kan bijvoorbeeld het verwijderen van gegevens uit de PRODUCTS-tabel in de database detecteren. Dit script drukt alle exemplaren van verwijderde regelitems uit de PRODUCTS-tabel af.

@fields = split (/ \ | /, $ARGV [0]);

mijn $SQL_VERB = ”DELETE”;

mijn $TABLE_NAME = ”PRODUCTS”;

if (($fields [3] == "Query") && \

($fields [4] = ~ / $SQL_VERB * FROM. * `$TABLE_NAME` /)) {

print "$fields [2] $fields [4] \ n";

}

De opdracht mysql-zrm voert het aangepaste plug-inscript uit voor alle back-ups of een specifiek back-upimage. Met de volgende opdracht wordt gezocht naar verwijdering uit de PRODUCTS-tabel op een back-upimage van 9 december 2019.

# mysql-zrm –actie parse-binlogs \

–Brondirectory / var / lib / mysql-zrm / pricebook / 20061205142103 \

–Parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl

 

De uitvoer van de opdracht bevat zowel geldige verwijderingen als kwaadwillende verwijderingen van databases.

Op dezelfde manier kunnen klanten hun eigen script opzetten en het laten uitvoeren en verifiëren voor en na de back-up, afhankelijk van de behoefte en is een opvallende functie voor ZRM voor MySQL.

De onderstaande schermafbeelding verwijst naar de pagina Back-up | Hoe in ZRM, waar u de naam, het pad en de uitvoering van de plug-in kunt configureren.

MySQL

De Pre en Post backup-plugin parameter moet de naam en het volledige pad naar de plugin bevatten. De aanbevolen locatie voor plug-ins in de directory "/ usr / share / mysql-is database / plugins".

Afronden!

Ondanks het hoge bewustzijn van verschillende kwetsbaarheidsdreigingen is het aantal incidenten de afgelopen jaren toegenomen. Als gevolg van de kosten die de slachtoffers van deze incidenten hebben gemaakt, zijn de bedrijfskosten tot een zeer aanzienlijk niveau gestegen als gevolg van de toename van datalekken. Om de impact van deze gebeurtenissen te verminderen, moet een organisatie de juiste procedures toepassen om de totale kosten als gevolg van datalekken te minimaliseren en niet over een efficiënte monitoring- en detectietool beschikken.

Bekijk ook zeker het Punten om op te nemen in uw noodherstelplan

Laat een antwoord achter

nl_NLDutch
en_USEnglish fr_FRFrench it_ITItalian es_ESSpanish de_DEGerman pt_BRPortuguese sv_SESwedish tr_TRTurkish jaJapanese pl_PLPolish zh_TWChinese id_IDIndonesian ko_KRKorean ms_MYMalay thThai nl_NLDutch