Säkerhetsrisker med Open Source

Vi kan IT-säkerhet

Säkerhetsrisker med Open Source

Idag finns ett flertal aktörer på marknaden som hanterar publika arkiv med öppen källkod (så kallade “repositories”). Många av dess aktörer så som exempelvis Github har tagit detta ett steg längre. De har även integrerat stöd för ärende- och projekthantering vilket är ett bra stöd när det används rätt. När man använder det fel kan det tyvärr blir riktigt dåligt…

Jag gjorde en enkelt sökning på Github med följande sökord “‘sql injection’ state:open” och fick då över 3 000 träffar. Många av dessa träffar är naturligtvis inte relevanta men flera av dem dokumenterar svagheter för SQL-injections (ofta med tillhörande exempel). För en hacker blir detta som ett smörgåsbord med system att attackera. Detta är ju nästan som CVE-databasen men med den skillnaden att felen oftast inte är rättade samt att källkoden finns tillgänglig så att man enkelt kan utveckla och test attacken i lugn och ro.

Ett relativt stort projekt som jag undersökte hade dels en väldokumenterad svaghet i kombinationen med länkar till system på organisationens hemsida. Som ni förstår är ju denna kombination ytterst olycklig.

Felbeskrivningen var exemplarisk och i detta fall innehöll den även en PoC (Proof of Concept).

Efter jag läst felbeskrivningen sökte jag snabbt upp organisationens hemsida där jag inte helt otippat hittade länkar till flertalet demo-system. Jag kunden naturligtvis inte hejda mig utan var helt enkelt bara tvungen att testa om svagheten fanns i dessa system. Naturligtvis var jag noga med att först säkerställa att det verkligen rörde sig om ett demo-system och att mitt test inte skulle förstöra eller på annat sätt orsaka några problem.

Mycket riktigt så kan jag via en mycket enkelt förändring i URL:en få systemet att berätta för mig vilken databas som används. Jag fortsatte inte mina efterforskningar efter detta men att jag via denna sårbarhet har möjlighet att obehindrat läsa ur systemets databas är självklart, beroende lite på serverns konfiguration kanske det även hade funnits möjlighet att ta denna attack ännu längre.

Lärdomen av detta är att “Open Source” är inte alltid det bästa alternativet för säkerheten även om det idag finns de som stark förespråkar att en öppenhet gör att felen då uppmärksammas på ett annat sätt och kan rättas.

Använder ni “Open Source” i Er produktionsmiljö så kan jag starkt rekommendera att ni mer eller mindre dagligen bevakar vad som händer i dessa projekt för att slippa drabbas av intrång.

Lämna ett svar