Moderne databases slaan allerlei soorten gegevens op. Van triviaal tot hooggevoelig. De restaurants die we bezoeken, onze kaartlocaties, onze identiteitsgegevens (bijvoorbeeld burgerservicenummers, adressen, medische dossiers, bankgegevens, enz...), en alles daartussenin is meer dan waarschijnlijk ergens in een database opgeslagen. Geen wonder dat gegevens zo waardevol zijn.
Databasetechnologieën ontwikkelen zich in een razend tempo. Innovatie, vooruitgang, integriteit en verbeteringen in overvloed staan op de voorgrond als een direct resultaat van het werk van intelligente en toegewijde ingenieurs, ontwikkelaars en robuuste gemeenschappen die deze leveranciers ondersteunen.
Toch is er een andere kant aan de medaille. Dat bestaat helaas naast elkaar in deze datagestuurde wereld in de vorm van malware, virussen en exploits op een enorme, ongekende schaal.
Data is ook waardevol voor de partijen aan die kant van de operatie. Maar om verschillende redenen. Elk van hen kan zijn, maar is niet beperkt tot, macht, chantage, financieel gewin en toegang, controle, plezier, grappen, boosaardigheid, diefstal, wraak... Je snapt het idee. De lijst is eindeloos.
Helaas moeten we werken met een veiligheidsmindset. Zonder deze mentaliteit laten we onze systemen kwetsbaar voor dit soort aanvallen. PostgreSQL is net zo vatbaar voor compromittering, misbruik, diefstal, ongeautoriseerde toegang/controle als andere vormen van software.
Dus welke maatregelen kunnen we nemen om het aantal risico's voor onze PostgreSQL-installaties te verminderen?
Ik ben er sterk van overtuigd dat het bevorderen van het bewustzijn van de bekende bedreigingen die er zijn, een even goede plek is om te beginnen. Kennis is macht en we moeten alles gebruiken dat tot onze beschikking staat. Trouwens, hoe kunnen we dat controleren waarvan we ons niet eens bewust zijn om de beveiliging van die PostgreSQL-instanties aan te scherpen en de gegevens die zich daar bevinden te beschermen?
Ik heb onlangs gezocht naar bekende 'bezorgdheden' en 'bedreigingen' op het gebied van beveiliging, gericht op de PostgreSQL-omgeving. Mijn zoekopdracht omvatte recente rapporten, artikelen en blogposts in het eerste kwartaal van 2018. Naast dat specifieke tijdsbestek, heb ik bekende, al lang bestaande zorgen onderzocht die vandaag nog steeds levensvatbare bedreigingen zijn (namelijk SQL-injectie), hoewel niet gepolijst of gebrandmerkt als 'recent ontdekt '.
Een fotomoment
Een diepe duik in database-aanvallen [Deel III]:waarom de foto van Scarlett Johansson mijn Postgres-database heeft gekregen om Monero te gaan delven
Het bericht over deze sluwe malware-aanval leverde de meeste 'hits' op uit mijn objectieve zoekresultaten.
We bezoeken een van de vele geweldige blogposts en een overzicht van de inhoud ervan. Ik heb ook aanvullende blogposts toegevoegd aan het einde van dit gedeelte, dus zorg ervoor dat u deze ook bezoekt die deze inbreuk beschrijven.
Waarnemingen
Informatie van Imperva, meldt dat hun honeypot-database (StickyDB) een malware-aanval op een van hun PostgreSQL-servers heeft ontdekt. Het honeypot-net, zoals Imperva het systeem noemt, is ontworpen om aanvallers te misleiden om de database aan te vallen, zodat zij (Imperva) erover kunnen leren en veiliger worden. In dit specifieke geval is de payload een malware die Monero cryptomineert, ingesloten in een foto van Scarlett Johansson.
De payload wordt tijdens runtime op schijf gedumpt met de functie lo_export. Maar blijkbaar gebeurt dit omdat lo_export een item is in pg_proc versus normaal direct bellen (lo_export).
Interessante details rechtstreeks uit de blogpost hier voor extreme duidelijkheid (zie geciteerd artikel),
Nu kan de aanvaller lokale systeemopdrachten uitvoeren met één eenvoudige functie:fun6440002537. Deze SQL-functie is een wrapper voor het aanroepen van een C-taalfunctie, "sys_eval", een kleine geëxporteerde functie in "tmp406001440" (een binair bestand gebaseerd op sqlmapproject), die in feite fungeert als proxy om shell-opdrachten van de SQL-client aan te roepen.
Dus wat zullen de volgende stappen van de aanval zijn? Enige verkenning. Dus het begon met het verkrijgen van de details van de GPU door lshw -c video uit te voeren en ging verder met cat /proc/cpuinfo om de CPU-details te krijgen (Figuur 3-4). Hoewel dit in het begin vreemd aanvoelt, is het volkomen logisch als je einddoel is om meer van je favoriete cryptocurrency te minen, toch?
Met een combinatie van databasetoegang en de mogelijkheid om code op afstand uit te voeren, en dat allemaal terwijl u 'onder de radar vliegt ' van monitoringoplossingen, downloadt de overtreder vervolgens de payload via een foto van Scarlett Johansson.
(Opmerking:de foto is sindsdien verwijderd van de gehoste locatie. Zie het linkartikel voor de vermelding.)
Volgens het rapport is de payload in binair formaat. Die binaire code is aan de foto toegevoegd om tijdens het uploaden door te gaan voor een echte foto, waardoor een zichtbare foto mogelijk is.
Zie figuur 6 van de post voor de SQL die verantwoordelijk is voor het gebruik van wget, dd en het uitvoeren van chmod voor permissies op het gedownloade bestand. Dat gedownloade bestand maakt vervolgens een ander uitvoerbaar bestand dat verantwoordelijk is voor het daadwerkelijk minen van de Monero. Natuurlijk zijn er na al dit snode werk schoonmaak en opruimen nodig.
Afbeelding 7 toont de uitvoerende SQL.
Imperva raadt aan om deze lijst met potentiële inbreukgebieden in het slotgedeelte te controleren:
- Pas op voor directe PostgreSQL-aanroepen naar lo_export of indirecte aanroepen via vermeldingen in pg_proc.
- Pas op voor PostgreSQL-functies die naar binaire bestanden in de C-taal aanroepen.
- Gebruik een firewall om uitgaand netwerkverkeer van uw database naar internet te blokkeren.
- Zorg ervoor dat uw database niet is toegewezen met een openbaar IP-adres. Als dit het geval is, beperk dan de toegang tot alleen de hosts die ermee communiceren (toepassingsserver of clients die eigendom zijn van DBA's).
Imperva voerde ook verschillende antivirustests uit, samen met details over hoe aanvallers mogelijk kwetsbare PostgreSQL-servers kunnen lokaliseren. Hoewel ik ze hier voor de beknoptheid niet heb opgenomen, kun je het artikel raadplegen voor de volledige details van hun bevindingen.
Aanbevolen lectuur
- Imperva heeft 2 voorgaande artikelen die deel 3 vergezellen (degene die hier wordt besproken). Hoewel deze PostgreSQL niet zwaar richten op wat we zojuist hebben verdoezeld, zijn ze zeer informatief:
- Deel 1
- Deel 2
- De Scarlett Johansson PostgreSQL-malware-aanval
- Hackers richten zich op PostgreSQL-DB's met Coinminer verborgen in Scarlett Johannsson-afbeelding
- Een Hacker News-thread over de exploit.
CVE-details, rapport en kwetsbaarheden
Ik heb deze site bezocht, die de nieuwste beveiligingsbedreigingen per leverancier plaatst en in het eerste kwartaal van 2018 4 kwetsbaarheden ontdekte. De PostgreSQL-beveiligingsinformatiepagina heeft ze ook vermeld, dus aarzel niet om die bron te raadplegen.
Hoewel ze bijna allemaal zijn behandeld, vond ik het belangrijk om deze in dit bericht op te nemen om lezers die er misschien nog niet van wisten, bewust te maken. Ik heb het gevoel dat we van hen allemaal kunnen leren. Vooral in de verschillende manieren waarop kwetsbaarheden worden ontdekt.
Ze worden hieronder weergegeven in volgorde van publicatiedatum:
Ik. CVE-2018-1052 publicatiedatum 2018-02-09 :Updatedatum 10-3-2018
Overzicht:
Kwetsbaarheid van het vrijgeven van geheugen in tabelpartitionering werd gevonden in PostgreSQL 10.x vóór 10.2, waardoor een geverifieerde aanvaller willekeurige bytes servergeheugen kan lezen via een speciaal gemaakte insert in een gepartitioneerde tabel.
Deze kwetsbaarheid is verholpen met de hier bevestigde release van PostgreSQL 10.2. Oudere 9.x-versies die ook zijn opgelost, worden ook genoemd, dus bezoek die link om uw specifieke versie te controleren.
II. CVE-2018-1053 publicatiedatum 2018-02-09 :Updatedatum 15-3-2018
Overzicht:
In PostgreSQL 9.3.x vóór 9.3.21, 9.4.x vóór 9.4.16, 9.5.x vóór 9.5.11, 9.6.x vóór 9.6.7 en 10.x vóór 10.2, maakt pg_upgrade een bestand aan in de huidige werkmap met de uitvoer van `pg_dumpall -g` onder umask die van kracht was toen de gebruiker pg_upgrade aanriep, en niet onder 0077 die normaal wordt gebruikt voor andere tijdelijke bestanden. Hierdoor kan een geverifieerde aanvaller dat ene bestand lezen of wijzigen, dat versleutelde of niet-versleutelde databasewachtwoorden kan bevatten. De aanval is onuitvoerbaar als een directorymodus de aanvaller blokkeert bij het doorzoeken van de huidige werkdirectory of als de heersende umask de aanvaller blokkeert om het bestand te openen.
Net als bij de vorige CVE-2018-1052 heeft PostgreSQL 10.2 dit deel van de kwetsbaarheid verholpen:
Zorg ervoor dat alle tijdelijke bestanden die zijn gemaakt met "pg_upgrade" niet leesbaar zijn voor de hele wereld
Veel oudere versies van PostgreSQL zijn getroffen door dit beveiligingslek. Zorg ervoor dat en bezoek de verstrekte link voor al die vermelde versies.
III. CVE-2017-14798 publicatiedatum 01-03-2018 :Updatedatum 26-3-2018
Overzicht:
Een racevoorwaarde in het PostgreSQL-initscript kan worden gebruikt door aanvallers die toegang hebben tot het PostgreSQL-account om hun rechten naar root te escaleren.
Hoewel ik nergens op de koppelingspagina kon vinden dat PostgreSQL-versie 10 werd genoemd, zijn er veel oudere versies, dus bezoek die link als u oudere versies gebruikt.
Gebruikers van Suse Linux Enterprise Server zijn mogelijk geïnteresseerd in 2 gelinkte artikelen hier en hier waarin deze kwetsbaarheid is verholpen voor versie 9.4 init-script.
IV. CVE-2018-1058 publicatiedatum 02-03-2018 :Updatedatum 22-03-2018
Overzicht:
Er is een fout gevonden in de manier waarop PostgreSQL een gebruiker toestond het gedrag van een zoekopdracht voor andere gebruikers aan te passen. Een aanvaller met een gebruikersaccount zou deze fout kunnen gebruiken om code uit te voeren met de machtigingen van superuser in de database. Versies 9.3 tot en met 10 worden beïnvloed.
Deze update-release vermeldt deze kwetsbaarheid met een interessant gekoppeld document dat alle gebruikers zouden moeten bezoeken.
Het artikel biedt een fantastische gids van de community, getiteld A Guide to CVE-2018-1058:Protect Your Search Path, met een ongelooflijke hoeveelheid informatie over de kwetsbaarheid, risico's en best practices om deze te bestrijden.
Ik zal mijn best doen om het samen te vatten, maar bezoek de gids voor uw eigen voordeel, begrip en begrip.
Overzicht:
Met de komst van PostgreSQL versie 7.3 werden schema's in het ecosysteem geïntroduceerd. Met deze verbetering kunnen gebruikers objecten in afzonderlijke naamruimten maken. Als een gebruiker een database maakt, maakt PostgreSQL standaard ook een openbaar schema waarin alle nieuwe objecten worden gemaakt. Gebruikers die verbinding kunnen maken met een database, kunnen ook objecten maken in dat openbare schema van de database.
Dit gedeelte rechtstreeks uit de gids is zeer belangrijk (zie geciteerd artikel):
Met schema's kunnen gebruikers objecten een naamruimte geven, zodat objecten met dezelfde naam in verschillende schema's in dezelfde database kunnen voorkomen. Als er objecten met dezelfde naam in verschillende schema's zijn en het specifieke schema/object-paar niet is opgegeven (d.w.z. schema.object), beslist PostgreSQL welk object moet worden gebruikt op basis van de instelling zoekpad. De instelling zoekpad specificeert de volgorde waarin de schema's worden doorzocht bij het zoeken naar een object. De standaardwaarde voor search_path is $user,public waarbij $user verwijst naar de naam van de verbonden gebruiker (die kan worden bepaald door SELECT SESSION_USER uit te voeren;).
Een ander belangrijk punt is hier:
Het probleem dat wordt beschreven in CVE-2018-1058 draait om het standaard "openbare" schema en hoe PostgreSQL de instelling zoekpad gebruikt. De mogelijkheid om objecten met dezelfde namen in verschillende schema's te maken, gecombineerd met hoe PostgreSQL naar objecten binnen schema's zoekt, biedt een gebruiker de mogelijkheid om het gedrag van een query voor andere gebruikers te wijzigen.
Hieronder vindt u een lijst op hoog niveau die de gids aanbeveelt om deze praktijken toe te passen zoals bepaald om het risico op deze kwetsbaarheid te verminderen:
- Gebruikers niet toestaan nieuwe objecten in het openbare schema te maken
- Stel het standaard zoekpad in voor databasegebruikers
- Stel het standaard zoekpad in in het PostgreSQL-configuratiebestand (postgresql.conf)
SQL-injectie
Elke 'beveiligingsthema ' SQL-blogpost of -artikel kan zichzelf niet als zodanig labelen zonder SQL-injectie te vermelden. Hoewel deze aanvalsmethode niet tot de verbeelding spreekt, is 'the new kid on the block ', het moet worden opgenomen.
SQL-injectie is altijd een bedreiging en misschien nog wel meer in de webtoepassingsruimte. Elke SQL-database -inclusief PostgreSQL- is er potentieel kwetsbaar voor.
Hoewel ik geen diepgaande kennis heb van SQL-injectie, ook wel bekend als SQLi, zal ik mijn best doen om een korte samenvatting te geven, hoe dit mogelijk uw PostgreSQL-server kan beïnvloeden en uiteindelijk hoe u de risico's van een prooi kunt verkleinen ernaar toe.
Raadpleeg de links aan het einde van dit gedeelte, die allemaal een schat aan informatie, uitleg en voorbeelden bevatten op die gebieden die ik niet adequaat kan communiceren.
Helaas bestaan er verschillende soorten SQL-injecties en ze hebben allemaal het gemeenschappelijke doel om aanstootgevende SQL in te voegen in query's voor uitvoering in de database, misschien niet oorspronkelijk bedoeld of ontworpen door de ontwikkelaar.
Niet-gesaneerde gebruikersinvoer, slecht ontworpen of niet-bestaande typecontrole (AKA-validatie), samen met niet-ontsnapte gebruikersinvoer, kunnen allemaal de deur wagenwijd openlaten voor potentiële aanvallers. Veel webprogrammeer-API's bieden enige bescherming tegen SQLi:bijv. ORM's (Object Relational Mapper), geparametriseerde query's, typecontrole, enz.... Het is echter de verantwoordelijkheid van de ontwikkelaar om alles in het werk te stellen en de belangrijkste scenario's voor SQL-injectie te verminderen door implementatie die omleidingen en mechanismen tot hun beschikking.
Hier zijn opmerkelijke suggesties om het risico van SQL-injectie te verminderen uit de OWASP SQL Injection Prevention Cheat Sheet. Zorg ervoor en bezoek het voor volledige detaillering van voorbeeldgebruik in de praktijk (zie geciteerd artikel).
Primaire verdediging:
- Optie 1:gebruik van voorbereide verklaringen (met geparametriseerde zoekopdrachten)
- Optie 2:Gebruik van opgeslagen procedures
- Optie 3:Validatie van invoer op de witte lijst
- Optie 4:ontsnappen aan alle door de gebruiker geleverde invoer
Extra verdedigingen:
- Ook:de minste privileges afdwingen
- Ook:validatie van invoer op de witte lijst uitvoeren als secundaire verdediging
Aanbevolen lectuur:
Ik heb aanvullende artikelen toegevoegd met veel informatie voor verdere studie en bewustwording:
- Wat is SQL-injectie? Deze oldie maar goodie kan je webapplicaties pijn doen
- SQL-injectie (Wikipedia)
- SQL-injectie (CLOUDFLARE)
- SQL-injectie (w3schools.com)
- SQL-injectiepreventie Cheatsheet
- Testen voor SQL-injectie
- Kwetsbaarheden voor SQL-injectie en hoe ze te voorkomen
- Cheatsheet voor SQL-injectie
Postgres-rolrechten
We hebben een gezegde voor iets in de trant van "We zijn onze eigen ergste vijand ."
We kunnen het zeker toepassen op het werken binnen de PostgreSQL-omgeving. Verwaarlozing, misverstanden of gebrek aan zorgvuldigheid zijn net zo goed een kans voor aanvallen en ongeoorloofd gebruik als aanvallen die met opzet worden gelanceerd.
Misschien zelfs nog meer, omdat ze onbedoeld gemakkelijker toegang, routes en kanalen toestaan voor overtredende partijen om aan te boren.
Ik zal een gebied noemen dat altijd van tijd tot tijd moet worden geherwaardeerd of opnieuw beoordeeld.
Ongerechtvaardigde of externe rolprivileges.
- SUPERUSER
- CREATROLE
- CREATEDB
- SUBSIDIE
Deze samensmelting van privileges is zeker het bekijken waard. SUPERUSER en CREATROLE zijn extreem krachtige commando's en zouden beter bediend kunnen worden door een DBA in plaats van door een analist of ontwikkelaar, denk je niet?
Heeft de rol echt het CREATEDB-attribuut nodig? Hoe zit het met GRANT? Dat kenmerk kan in verkeerde handen worden misbruikt.
Weeg alle opties goed af voordat u deze attributen in uw omgeving een rol geeft.
Strategieën, best practices en versterking
Hieronder vindt u een lijst met nuttige blogposts, artikelen, checklists en handleidingen die een 'jaar terug' (op het moment van schrijven) van zoekresultaten terugkwamen. Ze worden niet in volgorde van belangrijkheid vermeld en bieden elk opmerkelijke suggesties.
- Eenvoudige manieren om uw Postgres-servers te beschermen tegen een onwaarschijnlijke aanvalsvector:een bedrieglijke foto van Scarlett Johansson
- Helpen bij het beveiligen van uw PostgreSQL-database
- Wees niet koppig... Verhard uw PostgreSQL-database om veiligheid te garanderen
- Hoe u uw PostgreSQL-database kunt beveiligen - 10 tips
- PostgreSQL beveiligen tegen externe aanvallen
- PostgreSQL-rechten en beveiliging - het openbare schema afsluiten
Conclusie
In deze blog hebben we de beveiligingsproblemen besproken die PostgreSQL-beheerders over de hele wereld bezighouden:deze omvatten SQL-injectie, de heilige graal van alle beveiligingsincidenten, fouten in de basisbenadering van de behandeling gegevens veilig, zoals het niet goed aanscherpen van machtigingen in uw infrastructuur, en ook enkele minder bekende beveiligingsproblemen die mogelijk over het hoofd worden gezien. Als het gaat om de beveiliging van onze gegevens, is het van cruciaal belang dat we advies inwinnen en toepassen van vertrouwde partijen zoals Imperva en dergelijke, die ons manieren bieden om onszelf te beschermen tegen zowel basisaanvallen als tegen 0-dagen (exploits die nog niet zijn bekend), want een gerenommeerd advies betekent een goede toekomst voor onze databases en infrastructuur als geheel.
Houd er rekening mee dat de beveiligingsmaatregelen die we moeten nemen sterk afhangen van de kwetsbaarheden die we willen afweren, maar in het algemeen, alle noodzakelijke verdedigingen kennen om SQL-injectie af te weren, op de juiste manier privileges, en het is van cruciaal belang dat we altijd proberen ons risiconiveau met betrekking tot kwetsbaarheden te verlagen. Op de hoogte blijven van wat er gebeurt in de PostgreSQL-beveiligingsruimte zal ons ook wonderen doen:we kunnen onze servers (en dus onze gegevens) alleen goed verdedigen als we weten waar de aanvallers naar op zoek zijn.
Als u op zoek bent naar meer best practices voor het verbeteren van de beveiliging of prestatie van uw PostgreSQL-installaties, ga dan naar ClusterControl:aangezien de tool is ontwikkeld door vooraanstaande database-experts van over de hele wereld, laat uw databases in een mum van tijd zingen. Het product wordt ook geleverd met een gratis proefperiode van 30 dagen, dus zorg ervoor dat u niet alle functies mist die ClusterControl voor uw bedrijf kan bieden en probeer het vandaag nog.
Voor meer informatie over hoe u uw PostgreSQL-database-instances moet beveiligen, raadpleegt u de blog van Verschillend.nl voor advies:leren hoe u beveiligingsaudits voor PostgreSQL kunt automatiseren, zal zeker een stap in de goede richting zijn. Zorg ervoor dat je ons volgt op Twitter, LinkedIn en abonneer je op onze RSS-feed voor meer updates, en we zien je in de volgende.