Moderna databaser lagrar alla typer av data. Från trivialt till högkänsligt. Restaurangerna vi besöker, våra kartplatser, våra identitetsuppgifter (t.ex. personnummer, adresser, journaler, bankinformation, etc...), och allt däremellan lagras mer än troligt i en databas någonstans. Inte konstigt att data är så värdefulla.
Databasteknologier går framåt i en rasande takt. Innovation, progression, integritet och förbättringar i överflöd ligger i framkant som ett direkt resultat av arbetet från intelligenta och hängivna ingenjörer, utvecklare och robusta gemenskaper som stödjer dessa leverantörer.
Ändå finns det en annan sida av myntet. Det, tyvärr, samexisterar inom denna datadrivna värld i form av skadlig programvara, virus och exploateringar i en enorm, genom tiderna hög skala.
Data är värdefull även för parterna på den sidan av verksamheten. Men av olika anledningar. Vilken som helst av dem kan vara men är inte begränsad till makt, utpressning, ekonomisk vinning och tillgång, kontroll, nöje, spratt, illvilja, stöld, hämnd... Du förstår. Listan är oändlig.
Tyvärr måste vi arbeta med ett säkerhetstänkande. Utan detta tänkesätt lämnar vi våra system sårbara för dessa typer av attacker. PostgreSQL är lika känsligt för kompromisser, missbruk, stöld, obehörig åtkomst/kontroll som andra former av programvara.
Så vilka åtgärder kan vi vidta för att minska antalet risker för våra PostgreSQL-installationer?
Jag känner starkt att det är en lika bra plats att börja med att främja medvetenheten om vilka kända hot som finns där ute. Kunskap är makt och vi bör använda allt som står till vårt förfogande. Dessutom, hur kan vi polisa för det som vi inte ens är medvetna om för att skärpa säkerheten för dessa PostgreSQL-instanser och skydda data som finns där?
Jag sökte nyligen upp kända säkerhetsproblem och "hot", med inriktning på PostgreSQL-miljön. Min sökning omfattade senaste rapporter, artiklar och blogginlägg under första kvartalet 2018. Utöver den specifika tidsramen utforskade jag välkända långvariga problem som fortfarande är livskraftiga hot idag (nämligen SQL Injection), även om de inte är polerade eller markeras som 'nyligen upptäckt '.
En fotomöjlighet
En djupdykning i databasattacker [Del III]:Varför Scarlett Johanssons bild fick min Postgres-databas att börja bryta Monero
Ordet om denna listiga skadliga attack gav flest "träffar" av mina objektiva sökresultat.
Vi kommer att besöka ett av flera bra blogginlägg och en sammanfattning av dess innehåll. Jag har också inkluderat ytterligare blogginlägg i slutet av det här avsnittet, så se till att besöka dem som beskriver detta intrång.
Observationer
Information från Imperva rapporterar att deras honeypot-databas (StickyDB) upptäckte en malware-attack på en av deras PostgreSQL-servrar. Honeypot-nätet, som Imperva kallar systemet, är utformat för att lura angripare att attackera databasen så att de (Imperva) kan lära sig om det och bli säkrare. I det här specifika fallet är nyttolasten en skadlig kod som kryptominerar Monero, inbäddad i ett foto av Scarlett Johansson.
Nyttolasten dumpas till disken vid körning med lo_export-funktionen. Men uppenbarligen händer detta eftersom lo_export är en post i pg_proc kontra normalt direktanrop (lo_export).
Intressanta detaljer direkt från blogginlägget här för extrem tydlighet (se citerad artikel),
Nu kan angriparen utföra lokala systemkommandon med en enkel funktion – fun6440002537. Denna SQL-funktion är ett omslag för att anropa en C-språkfunktion, "sys_eval", en liten exporterad funktion i "tmp406001440" (en binär baserad på sqlmapproject), som i princip fungerar som proxy för att anropa skalkommandon från SQL-klienten.
Så vad blir nästa steg i attacken? En del spaning. Så det började med att få detaljerna om GPU:n genom att köra lshw -c video och fortsatte att cat /proc/cpuinfo för att få CPU-detaljerna (figur 3-4). Även om det här känns konstigt till en början, är det fullständigt vettigt när ditt slutmål är att bryta mer av din favoritkryptovaluta, eller hur?
Med en kombination av databasåtkomst och möjligheten att exekvera kod på distans, allt medan "flyger under radarn ' av övervakningslösningar laddar inkräktaren sedan ner nyttolasten via ett foto av Scarlett Johansson.
(Obs! Fotot har sedan tagits bort från sin värdplats. Se länkartikel för omnämnandet.)
Enligt rapporten är nyttolasten i binärt format. Den binära koden lades till i fotot för att passera för ett verkligt foto under uppladdningen, vilket möjliggör en synlig bild.
Se figur 6 i inlägget för SQL som är ansvarig för att använda wget, dd och köra chmod för behörigheter för den nedladdade filen. Den nedladdade filen skapar sedan en annan körbar fil som är ansvarig för att faktiskt bryta Monero. Naturligtvis behövs hushållning och städning efter allt detta skändliga arbete.
Figur 7 visar SQL som utförs.
Imperva rekommenderar att du övervakar den här listan över potentiella intrångsområden i det avslutande avsnittet:
- Se upp för direkta PostgreSQL-anrop till lo_export eller indirekta anrop genom poster i pg_proc.
- Se upp för PostgreSQL-funktioner som anropar binärfiler på C-språk.
- Använd en brandvägg för att blockera utgående nätverkstrafik från din databas till Internet.
- Se till att din databas inte är tilldelad en offentlig IP-adress. Om så är fallet, begränsa åtkomsten endast till de värdar som interagerar med den (programserver eller klienter som ägs av DBA).
Imperva utförde också olika antivirustester tillsammans med detaljer om hur angripare potentiellt kan lokalisera sårbara PostgreSQL-servrar. Även om jag inte inkluderade dem här för korthetens skull, konsultera artikeln för fullständig information om deras resultat.
Rekommenderad läsning
- Imperva har två föregående artiklar som åtföljer del 3 (den som diskuteras här). Även om de inte riktar in sig så mycket på PostgreSQL som det vi just har förbiskat, är de mycket informativa läsningar:
- Del 1
- Del 2
- Scarlett Johansson PostgreSQL skadlig programvara attack
- Hackare riktar in sig på PostgreSQL DB:er med Coinminer gömd i Scarlett Johannsson-bild
- En Hacker News-tråd om utnyttjandet.
CVE-detaljer, rapport och sårbarheter
Jag besökte den här webbplatsen, som publicerar de senaste säkerhetshoten per leverantör och upptäckte fyra sårbarheter under första kvartalet 2018. PostgreSQL-säkerhetsinformationssidan har dem också listade, så konsultera gärna den resursen.
Även om de flesta har tagits upp, kände jag att det var viktigt att inkludera dessa i det här inlägget för att göra läsare medvetna som kanske inte kände till dem. Jag känner att vi kan lära av dem alla. Särskilt i de olika sätten för upptäckta sårbarheter.
De listas nedan i den ordningsföljd de publicerades:
Jag. CVE-2018-1052 datum publicerat 2018-02-09:Uppdateringsdatum 3/10/2018
Översikt:
Minnesavslöjande sårbarhet i tabellpartitionering hittades i PostgreSQL 10.x före 10.2, vilket gör att en autentiserad angripare kan läsa godtyckliga byte av serverminne via specialtillverkad infogning till en partitionerad tabell.
Denna sårbarhet åtgärdades med utgivningen av PostgreSQL 10.2 bekräftad här. Äldre 9.x-versioner som också fixats nämns också så besök den länken för att kontrollera din specifika version.
II. CVE-2018-1053 datum publicerat 2018-02-09:Uppdateringsdatum 3/15/2018
Översikt:
I PostgreSQL 9.3.x före 9.3.21, 9.4.x före 9.4.16, 9.5.x före 9.5.11, 9.6.x före 9.6.7 och 10.x före 10.2, skapar pg_upgrade filen i aktuell arbetskatalog som innehåller utdata av `pg_dumpall -g` under umask som gällde när användaren anropade pg_upgrade, och inte under 0077 som normalt används för andra temporära filer. Detta kan tillåta en autentiserad angripare att läsa eller ändra den ena filen, som kan innehålla krypterade eller okrypterade databaslösenord. Attacken är omöjlig om ett katalogläge blockerar angriparen som söker i den aktuella arbetskatalogen eller om den rådande umasken blockerar angriparen att öppna filen.
Liksom med föregående CVE-2018-1052, fixade PostgreSQL 10.2 denna del av sårbarheten:
Se till att alla temporära filer som skapats med "pg_upgrade" inte är läsbara i världen
Många äldre versioner av PostgreSQL påverkas av denna sårbarhet. Var säker och besök den medföljande länken för alla de angivna versionerna.
III. CVE-2017-14798 datum publicerad 2018-03-01 :Uppdateringsdatum 2018-03-26
Översikt:
Ett rasvillkor i PostgreSQL init-skriptet kan användas av angripare som kan komma åt PostgreSQL-kontot för att eskalera sina privilegier till root.
Även om jag inte kunde hitta någonstans på länksidan att PostgreSQL version 10 nämndes, finns det många äldre versioner, så besök den länken om du kör äldre versioner.
Suse Linux Enterprise Server-användare kan vara intresserade av 2 länkade artiklar här och här där denna sårbarhet åtgärdades för version 9.4 init-skript.
IV. CVE-2018-1058 publicerat datum 2018-03-02:Uppdateringsdatum 2018-03-22
Översikt:
Ett fel hittades i hur PostgreSQL tillät en användare att ändra beteendet hos en fråga för andra användare. En angripare med ett användarkonto kan använda detta fel för att exekvera kod med behörigheter från superanvändare i databasen. Versioner 9.3 till 10 påverkas.
Denna uppdateringsversion nämner denna sårbarhet med ett intressant länkat dokument som alla användare bör besöka.
Artikeln ger en fantastisk guide från communityn med titeln A Guide to CVE-2018-1058:Protect Your Search Path som har en otrolig mängd information om sårbarhet, risker och bästa praxis för att bekämpa den.
Jag ska göra mitt bästa för att sammanfatta, men besök guiden för din egen fördel, förståelse och förståelse.
Översikt:
Med tillkomsten av PostgreSQL version 7.3 introducerades scheman i ekosystemet. Denna förbättring tillåter användare att skapa objekt i separata namnutrymmen. Som standard, när en användare skapar en databas, skapar PostgreSQL också ett offentligt schema där alla nya objekt skapas. Användare som kan ansluta till en databas kan också skapa objekt i databasens offentliga schema.
Det här avsnittet direkt från guiden är mycket viktigt (se citerad artikel):
Schema tillåter användare att namnområdesobjekt, så objekt med samma namn kan finnas i olika scheman i samma databas. Om det finns objekt med samma namn i olika scheman och det specifika schema/objekt-paret inte är specificerat (d.v.s. schema.object), bestämmer PostgreSQL vilket objekt som ska användas baserat på sökvägsinställningen. Inställningen sökväg anger i vilken ordning scheman genomsöks när man letar efter ett objekt. Standardvärdet för sökväg är $user,public där $user refererar till namnet på den anslutna användaren (vilket kan bestämmas genom att köra SELECT SESSION_USER;).
En annan viktig punkt är här:
Problemet som beskrivs i CVE-2018-1058 kretsar kring standardschemat "public" och hur PostgreSQL använder sökvägsinställningen. Möjligheten att skapa objekt med samma namn i olika scheman, kombinerat med hur PostgreSQL söker efter objekt inom scheman, ger en användare möjlighet att ändra beteendet hos en fråga för andra användare.
Nedan finns en lista på hög nivå som guiden rekommenderar tillämpning av dessa metoder som föreskrivs för att minska risken för denna sårbarhet:
- Tillåt inte användare att skapa nya objekt i det offentliga schemat
- Ange standardsökväg för databasanvändare
- Ange standardsökvägen i PostgreSQL-konfigurationsfilen (postgresql.conf)
SQL-injektion
Alla "säkerhetstema ' SQL blogginlägg eller artikel kan inte märka sig själv som sådan utan att nämna SQL-injektion. Även om denna angreppsmetod inte är någonting för fantasin "den nya ungen på kvarteret ', måste den inkluderas.
SQL Injection är alltid ett hot och kanske ännu mer i webbapplikationsutrymmet. Alla SQL-databaser - inklusive PostgreSQL - är potentiellt sårbara för det.
Även om jag inte har en djup kunskapsbas om SQL Injection - även känd som SQLi - ska jag göra mitt bästa för att ge en kort sammanfattning, hur det potentiellt kan påverka din PostgreSQL-server, och i slutändan hur man minskar riskerna för att falla offer. till det.
Se länkarna i slutet av det här avsnittet, som alla innehåller en mängd information, förklaringar och exempel inom de områden som jag inte kan kommunicera på ett adekvat sätt.
Tyvärr finns det flera typer av SQL-injektioner och de delar alla det gemensamma målet att infoga stötande SQL i frågor för exekvering i databasen, kanske inte ursprungligen avsedda eller designade av utvecklaren.
Osanerad användarinmatning, dåligt utformad eller obefintlig typkontroll (AKA-validering), tillsammans med ohälsoad användarinmatning kan alla potentiellt lämna dörren vidöppen för potentiella angripare. Många webbprogrammerings-API:er ger visst skydd mot SQLi:t.ex. ORM:s (Object Relational Mapper), parametriserade frågor, typkontroll, etc.. Det är dock utvecklarens ansvar att göra allt och minska prime scenarier för SQL-injektion genom att implementera de avledningar och mekanismer som står till deras förfogande.
Här är anmärkningsvärda förslag för att minska risken för SQL-injektion från OWASP SQL Injection Prevention Cheat Sheet. Var säker och besök den för fullständiga detaljerade exempel på användningar i praktiken (se citerad artikel).
Primära försvar:
- Alternativ 1:Användning av förberedda uttalanden (med parametriserade frågor)
- Alternativ 2:Användning av lagrade procedurer
- Alternativ 3:Vitlista Indatavalidering
- Alternativ 4:Avsluta all indata från användaren
Ytterligare försvar:
- Även:Upprätthålla minsta privilegium
- Även:Utför validering av indata från vitlistan som ett sekundärt försvar
Rekommenderad läsning:
Jag har inkluderat ytterligare artiklar med en mängd information för vidare studier och medvetenhet:
- Vad är SQL-injektion? Den här gamla men godingen kan göra dina webbapplikationer skadade
- SQL-injektion (Wikipedia)
- SQL-injektion (CLOUDFLARE)
- SQL Injection (w3schools.com)
- SQL Injection Prevention Cheat Sheet
- Testar för SQL-injektion
- SQL-injektionssårbarheter och hur man förhindrar dem
- SQL Injection Cheat Sheet
Postgres rollprivilegier
Vi har ett talesätt för något i stil med "Vi är vår egen värsta fiende ."
Vi kan definitivt tillämpa det på att arbeta inom PostgreSQL-miljön. Försummelse, missförstånd eller bristande noggrannhet är lika mycket en möjlighet för attacker och otillåten användning som de som medvetet lanseras.
Kanske ännu mer, vilket oavsiktligt tillåter enklare åtkomst, rutter och kanaler för kränkande parter att utnyttja.
Jag kommer att nämna ett område som alltid behöver omvärderas eller omvärderas då och då.
Omotiverade eller ovidkommande rollbehörigheter.
- SUPERANVÄNDARE
- CREATROLE
- SKAPADB
- BEHANDLING
Denna sammanslagning av privilegier är definitivt värd att titta på. SUPERUSER och CREATROLE är extremt kraftfulla kommandon och skulle fungera bättre i händerna på en DBA i motsats till en analytiker eller utvecklare skulle du inte tro?
Behöver rollen verkligen attributet CREATEDB? Hur är det med GRANT? Det attributet har risk för missbruk i fel händer.
Väg alla alternativ noggrant innan du tillåter roller dessa attribut i din miljö.
Strategier, bästa praxis och härdning
Nedan finns en lista över användbara blogginlägg, artiklar, checklistor och guider som kom tillbaka för ett "år tillbaka" (när detta skrivs) med sökresultat. De är inte listade i någon ordning av betydelse och var och en erbjuder anmärkningsvärda förslag.
- Enkla sätt att skydda dina Postgres-servrar från en osannolik attackvektor:A Rogue Picture of Scarlett Johansson
- Hjälper till att säkra din PostgreSQL-databas
- Var inte hård i huvudet... Förstärk din PostgreSQL-databas för att garantera säkerheten
- Hur du säkrar din PostgreSQL-databas - 10 tips
- Säkra PostgreSQL från extern attack
- PostgreSQL-privilegier och säkerhet - Låsa det offentliga schemat
Slutsats
I den här bloggen har vi gått igenom säkerhetsfrågorna som berör PostgreSQL-administratörer över hela världen:de inkluderar SQL-injektion som är den heliga gralen för alla säkerhetsincidenter, misstag i grundläggande tillvägagångssätt för hantering data säkert som att misslyckas med att skärpa behörigheterna i din infrastruktur, och även några mindre kända säkerhetsproblem som kan förbises. När det gäller säkerheten för vår data är det viktigt att vi tar och tillämpar råd från pålitliga parter som Imperva och liknande som ger oss sätt att skydda oss både från grundläggande attacker och från 0-dagars (exploateringar som ännu inte har skett) kända tidigare), eftersom seriös rådgivning innebär en god framtid för våra databaser och infrastruktur som helhet.
Tänk på att de säkerhetsåtgärder vi behöver vidta till stor del beror på de sårbarheter vi vill avvärja, men i allmänhet, att känna till alla nödvändiga försvar för att avvärja SQL-injektion, korrekt med hjälp av privilegier, och att alltid försöka minska vår risknivå avseende sårbarheter är avgörande. Att hålla sig uppdaterad med vad som händer i PostgreSQL-säkerhetsutrymmet kommer också att göra oss underverk:vi kan bara försvara våra servrar (och följaktligen vår data) väl om vi vet vad angriparna kan vara ute efter.
Om du letar efter fler bästa metoder för att förbättra säkerheten eller prestandaställningen för dina PostgreSQL-installationer, vänd dig till ClusterControl:eftersom verktyget är utvecklat av förstklassiga databasexperter från hela världen, kommer att få dina databaser att sjunga på nolltid. Produkten kommer också med en 30-dagars gratis provperiod, så se till att du inte missar att prova alla funktioner som ClusterControl kan erbjuda för ditt företag och ge det en chans idag.
För mer innehåll om hur du bör gå tillväga för att säkra dina PostgreSQL-databasinstanser, vänd dig till Severalnines-bloggen för råd:att lära dig hur du automatiserar säkerhetsrevisioner för PostgreSQL kommer säkert att vara ett steg i rätt riktning. Se till att följa oss på Twitter, LinkedIn och prenumerera på vårt RSS-flöde för fler uppdateringar, så ses vi i nästa.