Sårbarhetsskanning och säker utveckling. Del 1

In professional activities, developers, pentesters, and security experts often encounter processes such as Vulnerability Management (VM) and (Secure) SDLC.
These phrases encompass various sets of practices and tools used, which are interconnected, although their users differ.

Technological progress has not yet reached the point where a single tool can replace a person in conducting an analysis of the security of infrastructure and software.
It is interesting to understand why this is the case and what problems are encountered.

Processer

The Vulnerability Management process is designed for continuous monitoring of the security of infrastructure and patch management.
The Secure SDLC process is intended to support the security of the application during development and operation.

A similar part of these processes is the Vulnerability Assessment process, which involves vulnerability scanning.
The main difference in scanning within VM and SDLC is that the former aims to detect known vulnerabilities in third-party software or configuration. For example, an outdated version of Windows or the default community string for SNMP.
In the latter case, the goal is to identify vulnerabilities not only in third-party components (dependencies) but primarily in the code of the new product.

This creates differences in tools and approaches. In my opinion, the task of finding new vulnerabilities in applications is significantly more interesting, as it does not reduce to fingerprinting versions, gathering banners, password cracking, etc.
For high-quality automated application vulnerability scanning, algorithms are needed that take into account the semantics of the application, its purpose, and specific threats.

Infrastructure scanners can often be replaced by a timer, as expressed by avleonov.The point is that, purely statistically, you can consider your infrastructure vulnerable if you haven't updated it, say, in a month.

Verktyg

Scanning, like security analysis, can be performed as a black box or a white box.

Black Box

In black box scanning, the tool must be able to interact with the service through the same interfaces that users work with.

Infrastrukturverktyg (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, osv.) söker efter öppna nätverksportar, samlar "bannerar", identifierar versioner av installerad programvara och söker i sin kunskapsdatabas efter sårbarheter i dessa versioner. De försöker även upptäcka konfigurationsfel, såsom standardlösenord eller öppet datåtkomst, svaga SSL-krypteringar, osv.

Webbapplikationsverktyg (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, osv.) kan också identifiera kända komponenter och deras versioner (t.ex. CMS, ramverk, JS-bibliotek). Huvudstegen för skannern är crawling och fuzzing.
Under crawlingen samlar skannern information om befintliga gränssnitt för applikationen och HTTP-parametrar. Under fuzzing injiceras muterade eller genererade data i alla upptäckta parametrar för att provocera fram ett fel och upptäcka en sårbarhet.

Sådana applikationsskannrar tillhör klasserna DAST och IAST – respektive Dynamisk och Interaktiv Applikationssäkerhetstestning.

Vit låda

Vid vitlådeskanning finns det fler skillnader.
I processen för VM får skannrar (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, osv.) ofta tillgång till system, vilket möjliggör autentiserad scanning. På så sätt kan skannern ladda ner installerade paketversioner och konfigurationsparametrar direkt från systemet utan att gissa dem från banners av nätverkstjänster.
Skanningen blir mer exakt och fullständig.

När det kommer till vitlådeskanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, osv.) av applikationer handlar det vanligtvis om statisk kodanalys och användning av lämpliga verktyg från SAST – Statisk Applikationssäkerhetstestning.

Problem

Det uppstår många problem med scanning! Jag ställs ofta personligen inför dem i samband med att erbjuda tjänster för att bygga scanningprocesser och säker utveckling, samt vid genomförande av sårbarhetsanalys.

Jag vill lyfta fram tre huvudgrupper av problem som bekräftas av samtal med ingenjörer och chefer för informationssäkerhetstjänster i många olika företag.

Problem med scanning av webbapplikationer

1. Svårigheter med implementering. Skanners måste implementeras, konfigureras och anpassas för varje applikation, skapa en testmiljö för skanningar och integreras i CI/CD-processen för att vara effektiva. Annars blir det en meningslös formell procedur som bara ger falska positiva.
2. Varaktighet av skanningen. Skanners har fortfarande problem med deduplicering av gränssnitt även 2019 och kan skanna tusen sidor med 10 parametrar var, i flera dagar och ändå anse dem som olika, trots att samma kod ansvarar för dem. Samtidigt måste beslut om distribution i produktion inom utvecklingscykeln fattas snabbt.
3. Sparsmakade rekommendationer. Skanners ger ganska allmänna rekommendationer, och utvecklare kan inte alltid snabbt förstå hur de ska sänka risknivån, och framför allt, om de behöver göra det just nu eller om det kan vänta.
4. Destruktiv påverkan på applikationen. Skanners kan mycket väl utföra en DoS-attack på applikationen och kan även skapa ett stort antal enheter eller ändra befintliga (till exempel skapa tiotusentals kommentarer i en blogg), så det är bättre att inte köra skanning i produktion utan eftertanke.
5. Låg kvalitet på sårbarhetsdetektering. Skanners använder vanligtvis en fast mängd payloads och kan lätt missa en sårbarhet som inte passar in i deras kända beteendemönster.
6. Bristande förståelse av applikationens funktioner hos skanners. Skanners vet inte vad "internetbank", "betalning" eller "kommentar" är. De ser bara länkar och parametrar, så ett stort antal potentiella sårbarheter i affärslogiken förblir helt oskyddade, de kommer inte att förstå hur man gör en dubbel debitering, titta på andras data via ID eller justera saldot via avrundning.
7. Bristande förståelse av sidornas semantik hos skanners. Skanners kan inte läsa FAQ, de kan inte känna igen captcha, de kan inte själva förstå hur man registrerar sig, och att de måste logga in igen, vad som inte går att klicka på "logga ut", och hur man signerar förfrågningar vid ändring av parameter värden. Som ett resultat kan en stor del av applikationen förbli helt oskannad.

Problem med att skanna källkoden.

1. Falska positiva. Statisk analys är en komplex uppgift, där man ofta måste göra många kompromisser. Man tvingas ofta offra noggrannhet, och även dyra företagslösningar kan ge en enorm mängd falska positiva resultat.
2. Svårigheter med implementering. För att öka noggrannheten och fullständigheten i den statiska analysen måste skanningsreglerna förbättras, och att skriva dessa regler kan vara alltför arbetsamt. Ibland är det enklare att hitta alla ställen i koden med ett specifikt fel och åtgärda dem, än att skriva en regel för att detektera sådana fall.
3. Brist på stöd för beroenden. Stora projekt är beroende av många bibliotek och ramverk som utökar programmeringsspråkets möjligheter. Om skannerens kunskapsbank saknar information om farliga punkter ("sinks") i dessa ramverk, blir det en blind fläck, och skannern kommer inte att förstå koden.
4. Varaktighet av skanningen. Att hitta sårbarheter i koden är en komplex uppgift även i termer av algoritmer. Därför kan processen ta tid och kräva betydande beräkningsresurser.
5. Låg täckning. Trots resursförbrukningen och den långa skanningstiden måste utvecklarna av SAST-verktyg fortfarande göra kompromisser och analysera inte alla tillstånd som programmet kan befinna sig i.
6. Reproducerbarhet av fynd. Att ange en specifik rad och anropsstack som leder till en sårbarhet är utmärkt, men i praktiken ger skannern ofta inte tillräckligt med information för att verifiera existensen av en sårbarhet utifrån. Faktum är att problemet kan finnas i död kod som är oåtkomlig för en angripare.

Problem med skanning av infrastruktur.

1. Otillräcklig inventering. I stora infrastrukturer, särskilt de som är geografiskt åtskilda, är det ofta svårast att förstå vilka värdar som behöver skannas. Med andra ord är skanningsuppgiften tätt kopplad till asset management-uppgiften.
2. Dålig prioritering. Nätverkskanners ger ofta många resultat med brister som i praktiken inte kan utnyttjas, men som formellt har hög risknivå. Konsumenten får en rapport som är svår att tolka och det är oklart vad som behöver åtgärdas först.
3. Sparsmakade rekommendationer. I kunskapsbasen för skannern finns ofta bara mycket allmän information om sårbarheten och hur den kan åtgärdas, så administratörer får vända sig till Google. Situationen är något bättre med whitebox-skannrar, som kan ge specifika kommandon för att åtgärda problem.
4. Manuell arbete. I infrastrukturer kan det finnas många noder, vilket innebär att det potentiellt finns många sårbarheter som rapporterna måste analyseras manuellt för vid varje iteration.
5. Dålig täckning. Kvaliteten på skanningen av infrastrukturen beror direkt på mängden kunskapsbas om sårbarheter och programvaruversioner. Men, Det visar sig vara, även för marknadsledare är kunskapsbasen inte heltäckande, och i databaserna för gratislösningar finns det mycket information som saknas hos ledarna.
6. Problem med patchning. Oftast innebär patchning av sårbarheter i infrastrukturen att uppdatera ett paket eller ändra en konfigurationsfil. Ett stort problem här är att systemet, särskilt legacy-system, kan bete sig oförutsägbart som en följd av uppdateringen. I praktiken måste integrations tester genomföras på den levande infrastrukturen i produktion.

Metoder.

Vad ska man då göra?
Mer om exempel och hur man kan hantera många av de nämnda problemen kommer jag att berätta om i följande delar, men för nu kommer jag att ange de huvudsakliga områdena som kan arbetas med:

1. Aggering av olika skanningverktyg. Genom att använda flera skannrar korrekt kan man uppnå en betydande ökning av kunskapsbasen och kvaliteten på upptäckten. Man kan hitta fler sårbarheter än de sammanlagda resultaten av alla skannrar som körs var för sig, samtidigt som man kan bedöma risknivån mer exakt och ge fler rekommendationer.
2. Integration av SAST och DAST. Man kan öka täckningen för DAST och noggrannheten för SAST genom informationsutbyte mellan dem. Från källkoderna kan information om befintliga rutter hämtas, och med hjälp av DAST kan man kontrollera om sårbarheten är synlig utifrån.
3. Maskininlärning™. År 2015 om (och ännu) pratade jag om tillämpningen av statistik för att ge skannrarna hackerintuitiv och påskynda dem. Detta är definitvt materia för framtida utveckling av automatisk säkerhetsanalys.
4. Integrering av IAST med autotester och OpenAPI. Inom CI/CD-pipeline är det möjligt att skapa en skanningsprocess baserad på verktyg som fungerar som HTTP-proxy och funktionella tester som körs över HTTP. Tester och OpenAPI/Swagger-kontrakt kommer att ge skannern den information som saknas om dataflöden, vilket gör det möjligt att skanna applikationen i olika tillstånd.
5. Korrekt konfiguration. För varje applikation och infrastruktur behöver en lämplig skanningsprofil skapas, som tar hänsyn till antalet och typen av gränssnitt samt använda teknologier.
6. Anpassning av skannrar. Ofta kan applikationen inte skannas utan att skannern anpassas. Ett exempel är en betalgateway där varje förfrågan måste signeras. Utan att skriva en koppling till gatewayens protokoll kommer skannrar att utan eftertanke försöka göra förfrågningar med felaktig signatur. Det är också nödvändigt att skriva specialiserade skannrar för specifika typer av sårbarheter, såsom Insecure Direct Object Reference
7. Riskhantering. Genom att använda olika skannrar och integrera med externa system som Asset Management och Threat Management kan en mängd olika parametrar användas för att bedöma risknivåer, så att ledningen kan få en adekvat bild av det aktuella säkerhetstillståndet för utvecklingen eller infrastrukturen.

Håll dig uppdaterad och låt oss störa sårbarhetsskanningen!

Källa: habr.com