SkipFish: nuovo WebApp Scanner da Google

Che google sia attiva anche nel campo della Security è quasi una tautologia. Con tutti i soldi che macinano, una falla nei loro sistemi, o un'informazione mal gestita, potrebbe creare seri problemi al gigante di Mountain View.

Ecco quindi che oltre a tutte le misure per sicurizzare la vostra casella di posta elettronica con l'impostazione di SSL per default, la comoda interception di siti malevoli con la Google Toolbar (solo per citarne alcune), adesso arriva anche uno strumento di Sicurezza "preventiva".

SkipFish è un Web Application Scanner, ovvero un prodotto che, analizzando con approccio Black Box un sito Web, cerca di enumerare le diverse vulnerabilità presenti in esso. E' open source e abbastanza efficiente. Scaricabile su Linux, Mac OSX e Cygwin per Windows, garantisce in tempi ragionevoli di generare un comodo report in HTML da studiare.

SkipFish usa dei dizionari precostruiti ed è su questi che basa le proprie euristiche di analisi. Ovviamente viene fornito con dei dizionari già belli e pronti e modificare a mano questi ultimi può risultare un'operazione difficile che alla fine rischia di "rompere il giocattolo".

Questo il "manifesto" del progetto:

  • High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint - easily achieving 2000 requests per second with responsive targets.
  • Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.
  • Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors.

The tool is believed to support Linux, FreeBSD 7.0+, MacOS X, and Windows (Cygwin) environments.

Queste sono invece le "promesse" del tool:

A rough list of the security checks offered by the tool is outlined below.

  • High risk flaws (potentially leading to system compromise):

    • Server-side SQL injection (including blind vectors, numerical parameters).
    • Explicit SQL-like syntax in GET or POST parameters.
    • Server-side shell command injection (including blind vectors).
    • Server-side XML / XPath injection (including blind vectors).
    • Format string vulnerabilities.
    • Integer overflow vulnerabilities.
    • Locations accepting HTTP PUT.
  • Medium risk flaws (potentially leading to data compromise):

    • Stored and reflected XSS vectors in document body (minimal JS XSS support present).
    • Stored and reflected XSS vectors via HTTP redirects.
    • Stored and reflected XSS vectors via HTTP header splitting.
    • Directory traversal (including constrained vectors).
    • Assorted file POIs (server-side sources, configs, etc).
    • Attacker-supplied script and CSS inclusion vectors (stored and reflected).
    • External untrusted script and CSS inclusion vectors.
    • Mixed content problems on script and CSS resources (optional).
    • Incorrect or missing MIME types on renderables.
    • Generic MIME types on renderables.
    • Incorrect or missing charsets on renderables.
    • Conflicting MIME / charset info on renderables.
    • Bad caching directives on cookie setting responses.
  • Low risk issues (limited impact or low specificity):

    • Directory listing bypass vectors.
    • Redirection to attacker-supplied URLs (stored and reflected).
    • Attacker-supplied embedded content (stored and reflected).
    • External untrusted embedded content.
    • Mixed content on non-scriptable subresources (optional).
    • HTTP credentials in URLs.
    • Expired or not-yet-valid SSL certificates.
    • HTML forms with no XSRF protection.
    • Self-signed SSL certificates.
    • SSL certificate host name mismatches.
    • Bad caching directives on less sensitive content.
  • Internal warnings:

    • Failed resource fetch attempts.
    • Exceeded crawl limits.
    • Failed 404 behavior checks.
    • IPS filtering detected.
    • Unexpected response variations.
    • Seemingly misclassified crawl nodes.
  • Non-specific informational entries:

    • General SSL certificate information.
    • Significantly changing HTTP cookies.
    • Changing Server, Via, or X-... headers.
    • New 404 signatures.
    • Resources that cannot be accessed.
    • Resources requiring HTTP authentication.
    • Broken links.
    • Server errors.
    • All external links not classified otherwise (optional).
    • All external e-mails (optional).
    • All external URL redirectors (optional).
    • Links to unknown protocols.
    • Form fields that could not be autocompleted.
    • Password entry forms (for external brute-force).
    • File upload forms.
    • Other HTML forms (not classified otherwise).
    • Numerical file names (for external brute-force).
    • User-supplied links otherwise rendered on a page.
    • Incorrect or missing MIME type on less significant content.
    • Generic MIME type on less significant content.
    • Incorrect or missing charset on less significant content.
    • Conflicting MIME / charset information on less significant content.
    • OGNL-like parameter passing conventions.
Mi raccomando, fate i test con Skipfish in locale nella vostra rete e non provatelo su server esterni. Tool come questi, sebbene non siano intrusivi da un punto di vista dei sistemi attaccati, possono generare dei DoS anche importanti. Insomma se fate un NMAP su un sito esterno non succede nulla, ma è illegale. Se usate tool di Web App Scanning è legale (se lavorano solo sull'HTML/HTTP), ma rischiate di provocare un danno non indifferente.

Scegliete voi cosa conviene!

E non pensiate che tutti i server girano con risorse limitate, spesso li tengono su con i cerotti e i carichi elevati attivati da questi tool di scansione li possono mandare in palla. Quindi okkio!

Commenti

  1. "Se usate tool di Web App Scanning è legale (se lavorano solo sull'HTML/HTTP)"

    Sei sicuro di ciò?
    Hai riferimenti a riguardo?

    Sarebbero per me molto interessanti.

    Grazie,
    Ciao

    RispondiElimina
  2. Il fatto è che secondo me, parlando per esempio di Skipfish, quando vengono effettuati questo tipo di check:

    * Server-side SQL injection (including blind vectors, numerical parameters).
    * Explicit SQL-like syntax in GET or POST parameters.
    * Server-side shell command injection (including blind vectors).
    * Server-side XML / XPath injection (including blind vectors).
    * Integer overflow vulnerabilities.
    * Locations accepting HTTP PUT.

    l'applicazione non sta in realtà solamente osservando il funzionamento dell'applicazione, ma sta inviando query appositamente forgiate in maniera maliziosa e quindi illegale.

    Certo è che in realtà non credo possa essere consderato illegale il fatto di inserire un apice per la semplice ricerca di un errore di comunicazione con il DB (e quindi una possibile SQL Injection), mentre credo che aggiungere comandi SQL per cercare di exploitare la vulnerabilità possa essere considerato illegale.

    Per tutto questo in realtà anche io non ho riferimenti ed è quindi solamente il mio parere e proprio per questo chiedevo se avessi riferimenti a riguardo.

    (Anche io trovo interessante l'argomento ma forse qui stiamo entrando in una diatriba legale più che tecnica)

    Grazie comunque per la risposta.
    Ciao.

    RispondiElimina

Posta un commento

Post popolari in questo blog

Exploit: icsploit o espluà?

Rappresentazione 3D di Worm, spam, ...

Code review e HTTPS