Moderne databaser gemmer alle slags data. Fra trivielt til højsensitivt. De restauranter, vi besøger, vores kortplaceringer, vores identitetsoplysninger (f.eks. CPR-numre, adresser, sygejournaler, bankoplysninger osv...), og alt derimellem er mere end sandsynligt gemt i en database et eller andet sted. Ikke underligt, at data er så værdifulde.
Databaseteknologier udvikler sig i et hæsblæsende tempo. Innovation, progression, integritet og forbedringer i overflod er på forkant som et direkte resultat af arbejdet fra intelligente og dedikerede ingeniører, udviklere og robuste fællesskaber, der understøtter disse leverandører.
Alligevel er der en anden side af mønten. Det eksisterer desværre side om side i denne datadrevne verden i form af malware, vira og udnyttelser i en massiv, alle tiders høj skala.
Data er også værdifulde for parterne på den side af operationen. Men af forskellige årsager. Enhver af dem kunne være, men er ikke begrænset til, magt, afpresning, økonomisk vinding og adgang, kontrol, sjov, pranks, ondskab, tyveri, hævn... Du forstår. Listen er uendelig.
Desværre er vi nødt til at operere med en sikkerhedstankegang. Uden denne tankegang efterlader vi vores systemer sårbare over for disse typer angreb. PostgreSQL er lige så modtagelig for kompromittering, misbrug, tyveri, uautoriseret adgang/kontrol som andre former for software.
Så hvilke foranstaltninger kan vi tage for at mindske antallet af risici for vores PostgreSQL-installationer?
Jeg føler stærkt, at det er et lige så godt sted at starte at fremme bevidstheden om, hvilke kendte trusler der er derude. Viden er magt, og vi bør bruge alt, hvad vi har til rådighed. Desuden, hvordan kan vi politi for det, vi ikke engang er opmærksomme på, for at stramme op på sikkerheden på disse PostgreSQL-instanser og beskytte de data, der findes der?
Jeg har for nylig søgt efter kendte "sikkerhedsbekymringer" og "trusler", rettet mod PostgreSQL-miljøet. Min søgning omfattede nylige rapporter, artikler og blogindlæg inden for det første kvartal af 2018. Ud over den specifikke tidsramme udforskede jeg velkendte langvarige bekymringer, som stadig er levedygtige trusler i dag (nemlig SQL Injection), mens de ikke er polerede eller markeret som 'for nylig opdaget '.
En fotomulighed
Et dybt dyk ned i databaseangreb [Del III]:Hvorfor Scarlett Johanssons billede fik min Postgres-database til at starte minedrift Monero
Ordet om dette listige malware-angreb gav flest 'hits' ud af mine objektive søgeresultater.
Vi vil besøge et af flere gode blogindlæg og en gennemgang af dets indhold. Jeg har også inkluderet yderligere blogindlæg i slutningen af dette afsnit, så sørg for at besøge dem, der også beskriver denne indtrængen.
Observationer
Oplysninger fra Imperva rapporterer, at deres honeypot-database (StickyDB) opdagede et malwareangreb på en af deres PostgreSQL-servere. Honeypot-nettet, som Imperva kalder systemet, er designet til at narre angribere til at angribe databasen, så de (Imperva) kan lære om det og blive mere sikre. I dette særlige tilfælde er nyttelasten en malware, der kryptominerer Monero, indlejret i et billede af Scarlett Johansson.
Nyttelasten dumpes til disk ved kørsel med lo_export-funktionen. Men tilsyneladende sker dette, fordi lo_export er en post i pg_proc versus normalt direkte opkald (lo_export).
Interessante detaljer direkte fra blogindlægget her for ekstrem klarhed (se citeret artikel),
Nu er angriberen i stand til at udføre lokale systemkommandoer ved hjælp af en simpel funktion - fun6440002537. Denne SQL-funktion er en indpakning til at kalde en C-sprog funktion, "sys_eval", en lille eksporteret funktion i "tmp406001440" (en binær baseret på sqlmapproject), som grundlæggende fungerer som proxy til at påkalde shell-kommandoer fra SQL-klient.
Så hvad bliver de næste skridt i angrebet? Noget rekognoscering. Så det startede med at få detaljerne om GPU'en ved at udføre lshw -c video og fortsatte med at cat /proc/cpuinfo for at få CPU-detaljerne (figur 3-4). Selvom dette føles mærkeligt i starten, giver det fuldstændig mening, når dit endelige mål er at udvinde mere af din foretrukne kryptovaluta, ikke?
Med en kombination af databaseadgang og muligheden for at udføre kode eksternt, alt imens 'flyver under radaren ' af overvågningsløsninger, downloader overtræderen derefter nyttelasten via et foto af Scarlett Johansson.
(Bemærk:Billedet er siden blevet fjernet fra dets hostede placering. Se link-artiklen for omtale.)
Ifølge rapporten er nyttelasten i binært format. Den binære kode blev føjet til billedet for at kunne overføres til et faktisk billede under upload, hvilket muliggjorde et billede, der kan ses.
Se figur 6 i indlægget for SQL, der er ansvarlig for at bruge wget, dd og udføre chmod for tilladelser på den downloadede fil. Den downloadede fil opretter derefter en anden eksekverbar fil, som er ansvarlig for rent faktisk at udvinde Monero. Selvfølgelig er der brug for husholdning og oprydning efter alt dette uhyggelige arbejde.
Figur 7 viser den udførende SQL.
Imperva anbefaler at overvåge denne liste over potentielle brudområder i den afsluttende sektion:
- Pas på direkte PostgreSQL-kald til lo_export eller indirekte opkald gennem indtastninger i pg_proc.
- Pas på med PostgreSQL-funktioner, der kalder til C-sprog binære filer.
- Brug en firewall til at blokere udgående netværkstrafik fra din database til internettet.
- Sørg for, at din database ikke er tildelt en offentlig IP-adresse. Hvis det er det, skal du kun begrænse adgangen til de værter, der interagerer med den (applikationsserver eller klienter ejet af DBA'er).
Imperva udførte også forskellige antivirustests sammen med detaljer om, hvordan angribere potentielt kan lokalisere sårbare PostgreSQL-servere. Selvom jeg ikke inkluderede dem her for kortheds skyld, kan du konsultere artiklen for at få alle detaljer om deres resultater.
Anbefalet læsning
- Imperva har 2 foregående artikler, der ledsager del 3 (den diskuterede her). Selvom de ikke er rettet mod PostgreSQL i høj grad som det, vi lige har sluppet over, er de meget informative læsninger:
- Del 1
- Del 2
- Scarlett Johansson PostgreSQL malware-angrebet
- Hackere målretter mod PostgreSQL DB'er med Coinminer skjult i Scarlett Johannsson-billede
- En Hacker News-tråd om udnyttelsen.
CVE-detaljer, rapport og sårbarheder
Jeg besøgte dette websted, som offentliggør de seneste sikkerhedstrusler pr. leverandør og opdagede 4 sårbarheder i 1. kvartal af 2018. Siden PostgreSQL Security Information har dem også opført, så du er velkommen til at konsultere den ressource.
Selvom de fleste af dem er blevet behandlet, følte jeg det vigtigt at inkludere disse i dette indlæg for at skabe opmærksomhed til læsere, som måske ikke har kendt til dem. Jeg føler, at vi kan lære af dem alle. Især i de forskellige måder at opdage sårbarheder på.
De er anført nedenfor i rækkefølge efter publiceringsdato:
Jeg. CVE-2018-1052 dato offentliggjort 2018-02-09:Opdateringsdato 3/10/2018
Oversigt:
Sårbarhed for hukommelsesoffentliggørelse i tabelpartitionering blev fundet i PostgreSQL 10.x før 10.2, hvilket gør det muligt for en autentificeret angriber at læse vilkårlige bytes af serverhukommelse via specialfremstillet insert til en partitioneret tabel.
Denne sårbarhed blev rettet med udgivelsen af PostgreSQL 10.2 bekræftet her. Ældre 9.x-versioner, som også er rettet, er også nævnt, så besøg dette link for at kontrollere din specifikke version.
II. CVE-2018-1053 dato offentliggjort 2018-02-09:Opdateringsdato 15/3/2018
Oversigt:
I PostgreSQL 9.3.x før 9.3.21, 9.4.x før 9.4.16, 9.5.x før 9.5.11, 9.6.x før 9.6.7 og 10.x før 10.2 opretter pg_upgrade en fil i den aktuelle arbejdsmappe, der indeholder outputtet af `pg_dumpall -g` under umask, som var i kraft, da brugeren påkaldte pg_upgrade, og ikke under 0077, som normalt bruges til andre midlertidige filer. Dette kan give en godkendt angriber mulighed for at læse eller ændre den ene fil, som kan indeholde krypterede eller ukrypterede databaseadgangskoder. Angrebet er umuligt, hvis en mappetilstand blokerer for angriberen, der søger i den aktuelle arbejdsmappe, eller hvis den gældende umask blokerer for, at angriberen åbner filen.
Som med den tidligere CVE-2018-1052 rettede PostgreSQL 10.2 denne del af sårbarheden:
Sørg for, at alle midlertidige filer lavet med "pg_upgrade" er ikke-verdenslæsbare
Mange ældre versioner af PostgreSQL er påvirket af denne sårbarhed. Vær sikker på og besøg det medfølgende link for alle de nævnte versioner.
III. CVE-2017-14798 dato offentliggjort 2018-03-01:Opdateringsdato 26/3/2018
Oversigt:
En race-tilstand i PostgreSQL init-scriptet kunne bruges af angribere, der er i stand til at få adgang til PostgreSQL-kontoen for at eskalere deres privilegier til root.
Selvom jeg ikke kunne finde nogen steder på linkingssiden, at PostgreSQL version 10 blev nævnt, er mange ældre versioner det, så besøg det link, hvis du kører ældre versioner.
Suse Linux Enterprise Server-brugere kan være interesseret i 2 linkede artikler her og her, hvor denne sårbarhed blev rettet for version 9.4 init-script.
IV. CVE-2018-1058 dato offentliggjort 2018-03-02:Opdateringsdato 22/3/2018
Oversigt:
Der blev fundet en fejl i den måde, PostgreSQL tillod en bruger at ændre adfærden af en forespørgsel for andre brugere. En angriber med en brugerkonto kunne bruge denne fejl til at udføre kode med superbrugerens tilladelser i databasen. Version 9.3 til 10 er berørt.
Denne opdateringsudgivelse omtaler denne sårbarhed med et interessant linket dokument, som alle brugere bør besøge.
Artiklen giver en fantastisk guide fra fællesskabet med titlen A Guide to CVE-2018-1058:Protect Your Search Path, der har en utrolig mængde information om sårbarhed, risici og bedste praksis for at bekæmpe det.
Jeg vil gøre mit bedste for at opsummere, men besøg guiden for din egen fordel, forståelse og forståelse.
Oversigt:
Med fremkomsten af PostgreSQL version 7.3 blev skemaer introduceret i økosystemet. Denne forbedring giver brugerne mulighed for at oprette objekter i separate navnerum. Som standard, når en bruger opretter en database, opretter PostgreSQL også et offentligt skema, hvor alle nye objekter oprettes. Brugere, der kan oprette forbindelse til en database, kan også oprette objekter i databasens offentlige skema.
Dette afsnit direkte fra vejledningen er meget vigtigt (se citeret artikel):
Skemaer tillader brugere at navngive objekter, så objekter af samme navn kan eksistere i forskellige skemaer i den samme database. Hvis der er objekter med det samme navn i forskellige skemaer, og det specifikke skema/objekt-par ikke er angivet (dvs. schema.object), beslutter PostgreSQL, hvilket objekt der skal bruges, baseret på indstillingen søgesti. Søgesti-indstillingen angiver rækkefølgen, som skemaerne søges i, når de leder efter et objekt. Standardværdien for søgesti er $user,public, hvor $user refererer til navnet på den tilsluttede bruger (som kan bestemmes ved at udføre SELECT SESSION_USER;).
Et andet vigtigt punkt er her:
Problemet beskrevet i CVE-2018-1058 er centreret omkring standard "offentlige" skemaet og hvordan PostgreSQL bruger søgesti-indstillingen. Evnen til at oprette objekter med de samme navne i forskellige skemaer, kombineret med hvordan PostgreSQL søger efter objekter i skemaer, giver en bruger mulighed for at ændre adfærden af en forespørgsel for andre brugere.
Nedenfor er en liste på højt niveau, guiden anbefaler anvendelse af disse fremgangsmåder som foreskrevet for at reducere risikoen for denne sårbarhed:
- Tillad ikke brugere at oprette nye objekter i det offentlige skema
- Indstil standardsøgestien for databasebrugere
- Indstil standardsøgestien i PostgreSQL-konfigurationsfilen (postgresql.conf)
SQL-injektion
Ethvert 'sikkerhedstema ' SQL blogindlæg eller artikel kan ikke mærke sig selv som sådan uden at nævne SQL-injektion. Selvom denne angrebsmetode på ingen måde er fantasifuld, er 'den nye knægt på blokken ', skal den inkluderes.
SQL Injection er altid en trussel og måske endnu mere i webapplikationsområdet. Enhver SQL-database - inklusive PostgreSQL- er potentielt sårbar over for det.
Selvom jeg ikke har en dyb videnbase om SQL Injection -også kendt som SQLi- vil jeg gøre mit bedste for at give en kort oversigt, hvordan det potentielt kan påvirke din PostgreSQL-server, og i sidste ende hvordan man reducerer risikoen for at blive byttet. til det.
Se linkene i slutningen af dette afsnit, som alle indeholder et væld af oplysninger, forklaringer og eksempler på de områder, jeg ikke er i stand til at kommunikere tilstrækkeligt med.
Desværre findes der flere typer SQL-injektioner, og de deler alle det fælles mål om at indsætte stødende SQL i forespørgsler til udførelse i databasen, måske ikke oprindeligt tiltænkt eller designet af udvikleren.
Usanificeret brugerinput, dårligt designet eller ikke-eksisterende typekontrol (AKA-validering), sammen med uundgået brugerinput kan alle potentielt lade døren stå åben for potentielle angribere. Mange webprogrammerings-API'er giver en vis beskyttelse mod SQLi:f.eks. ORM's (Object Relational Mapper), parametriserede forespørgsler, typekontrol osv.. Det er dog udviklerens ansvar at gøre alt, hvad der er muligt og reducere de primære scenarier for SQL-injektion ved at implementere disse afledninger og mekanismer til deres rådighed.
Her er bemærkelsesværdige forslag til at reducere risikoen for SQL-injektion fra OWASP SQL Injection Prevention Cheat Sheet. Vær sikker på og besøg den for at få fuldstændige detaljerede eksempler på brug i praksis (se citeret artikel).
Primære forsvar:
- Mulighed 1:Brug af forberedte udsagn (med parametrerede forespørgsler)
- Mulighed 2:Brug af lagrede procedurer
- Mulighed 3:Validering af hvidliste-input
- Mulighed 4:Undgå alle brugerleverede input
Yderligere forsvar:
- Også:Håndhævelse af mindste privilegier
- Også:Udførelse af hvidliste-inputvalidering som et sekundært forsvar
Anbefalet læsning:
Jeg har inkluderet yderligere artikler med en masse information til yderligere undersøgelse og bevidsthed:
- Hvad er SQL-injektion? Denne gamle men gode ting kan få dine webapplikationer til at skade
- SQL-injektion (Wikipedia)
- SQL-injektion (CLOUDFLARE)
- SQL Injection (w3schools.com)
- SQL Injection Prevention Cheat Sheet
- Test for SQL-injektion
- SQL-injektionssårbarheder og hvordan man forebygger dem
- SQL Injection Cheat Sheet
Postgres-rolleprivilegier
Vi har et ordsprog for noget i stil med "Vi er vores egen værste fjende ."
Vi kan helt sikkert anvende det til at arbejde i PostgreSQL-miljøet. Forsømmelse, misforståelser eller mangel på omhu er lige så meget en mulighed for angreb og uautoriseret brug som dem, der med vilje er lanceret.
Måske endnu mere, ved utilsigtet at tillade lettere adgang, ruter og kanaler for krænkende parter at benytte sig af.
Jeg vil nævne et område, der altid har brug for revurdering eller revurdering fra tid til anden.
Ubegrundede eller uvedkommende rolleprivilegier.
- SUPERBRUGER
- CREATROLE
- CREATEDB
- GIV
Denne sammenlægning af privilegier er bestemt et kig værd. SUPERUSER og CREATROLE er ekstremt kraftfulde kommandoer og ville være bedre tjent i hænderne på en DBA i modsætning til en analytiker eller udvikler, ville du ikke tro?
Har rollen virkelig brug for CREATEDB-attributten? Hvad med GRANT? Den egenskab har potentiale for misbrug i de forkerte hænder.
Overvej alle muligheder, før du tillader roller disse attributter i dit miljø.
Strategier, bedste praksis og hærdning
Nedenfor er en liste over nyttige blogindlæg, artikler, tjeklister og vejledninger, der vendte tilbage for et 'år tilbage' (på tidspunktet for skrivningen) af søgeresultater. De er ikke opført i nogen rækkefølge af betydning, og de giver hver især bemærkelsesværdige forslag.
- Enkle måder at beskytte dine Postgres-servere mod en usandsynlig angrebsvektor:Et slyngelagtigt billede af Scarlett Johansson
- Hjælp til at sikre din PostgreSQL-database
- Vær ikke hårdfør... Hærd din PostgreSQL-database for at sikre sikkerhed
- Sådan sikrer du din PostgreSQL-database - 10 tips
- Sikring af PostgreSQL mod eksternt angreb
- PostgreSQL-privilegier og sikkerhed - Låsning af det offentlige skema
Konklusion
I denne blog har vi gennemgået de sikkerhedsproblemer, der bekymrer PostgreSQL-administratorer over hele kloden:disse inkluderer SQL-injektion, som er den hellige gral for alle sikkerhedshændelser, fejl i grundlæggende tilgange til håndtering data sikkert, såsom at undlade at stramme tilladelserne korrekt på tværs af din infrastruktur, og også nogle mindre kendte sikkerhedsproblemer, der kan blive overset. Når det drejer sig om sikkerheden af vores data, er det afgørende, at vi tager og anvender råd fra betroede parter, såsom Imperva og lignende, som giver os måder at beskytte os selv mod både grundlæggende angreb og fra 0-dage (udnyttelse, der endnu ikke er blevet brugt). kendt før), fordi velrenommeret rådgivning betyder en god fremtid for vores databaser og infrastruktur som helhed.
Husk på, at de sikkerhedsforanstaltninger, vi skal tage, i høj grad vil afhænge af de sårbarheder, vi ønsker at afværge, men generelt kender vi alle de nødvendige forsvar for at afværge SQL-injektion, korrekt ved hjælp af privilegier, og altid at forsøge at reducere vores risikoniveau vedrørende sårbarheder er afgørende. At holde sig ajour med, hvad der sker i PostgreSQL-sikkerhedsområdet, vil også gøre os underværker:vi kan kun forsvare vores servere (og dermed vores data) godt, hvis vi ved, hvad angriberne kan være ude efter.
Skal du søge efter flere bedste praksisser for at forbedre sikkerheden eller ydeevnen for dine PostgreSQL-installationer, så vend til ClusterControl:da værktøjet er udviklet af førsteklasses databaseeksperter fra hele verden, vil få dine databaser til at synge på ingen tid. Produktet leveres også med en 30-dages gratis prøveperiode, så sørg for at du ikke går glip af at prøve alle de funktioner, som ClusterControl kan tilbyde til din virksomhed, og prøv det i dag.
For mere indhold om, hvordan du skal sikre dine PostgreSQL-databaseforekomster, kan du henvende dig til Severalnines-bloggen for at få råd:At lære, hvordan du automatiserer sikkerhedsrevisioner for PostgreSQL, vil helt sikkert være et skridt i den rigtige retning. Sørg for at følge os på Twitter, LinkedIn, og abonner på vores RSS-feed for flere opdateringer, så ses vi i den næste.