Buscando vulnerabilidades en PHP con (un simple) grep

Ya sabemos que usar grep para encontrar vulnerabilidades en el código PHP de una aplicación web puede parecer tosco pero a veces es sumamente efectivo. Digamos que probablemente es la forma más rápida de encontrar patrones de vulnerabilidades conocidas. Por ejemplo, se puede usar grep para buscar llamadas a la función system:

$ grep -R 'system \ (\ $ _' *

Si bien este enfoque tiene muchas limitaciones:

- No se obtiene mucha cobertura/garantía sobre la calidad (y, por lo tanto, la seguridad) del código fuente. Solo se sabe que, según una lista de patrones, no se pudo encontrar ningún problema.
- Se debe conocer todas las funciones/patrones peligrosos.
- Terminas usando expresiones regulares muy complejas.

Sin embargo y como decimos, esto funciona bastante bien para las revisiones donde no tenemos suficiente tiempo. Así que si este es tu caso, en este post recopilamos un pequeño cheatsheet para probar a mano:

CHEATSHEET - ANÁLISIS MANUAL

XSS:

grep -Ri "echo" .
grep -Ri "\$_" . | grep "echo"
grep -Ri "\$_GET" . | grep "echo"
grep -Ri "\$_POST" . | grep "echo"
grep -Ri "\$_REQUEST" . | grep "echo"

Command execution:

grep -Ri "shell_exec(" .
grep -Ri "system(" .
grep -Ri "exec(" .
grep -Ri "popen(" .
grep -Ri "passthru(" .
grep -Ri "proc_open(" .
grep -Ri "pcntl_exec(" .

Code execution:

grep -Ri "eval(" .
grep -Ri "assert(" .
grep -Ri "preg_replace" . | grep "/e"
grep -Ri "create_function(" .

SQL Injection:

grep -Ri "\$sql" .
grep -Ri "\$sql" . | grep "\$_"

SQLMAP Cheatsheet for WordPress:

sqlmap -u "http://target.tld/?paramater=1" -p "parameter" --technique=B --dbms=mysql --suffix=")--" --string="Test" --sql-query="select user_login,user_pass from wp_users"

Information leak via phpinfo:

grep -Ri "phpinfo" .

Find dev and debug modes:

grep -Ri "debug" .
grep -Ri "\$_GET['debug']" .
grep -Ri "\$_GET['test']" .

RFI/LFI:

grep -Ri "file_include" .
grep -Ri "include(" .
grep -Ri "require(" .
grep -Ri "require(\$file)" .
grep -Ri "include_once(" .
grep -Ri "require_once(" .
grep -Ri "require_once(" . | grep "\$_"

Misc:

grep -Ri "header(" . | grep "\$_"
grep -Ri '$_SERVER["HTTP_USER_AGENT"]' .

Path Traversal:

grep -Ri file_get_contents .

GRAUDIT - ANÁLISIS AUTOMÁTICO

También, si quieres automatizar todos estos "greps" te recomendamos usar graudit, un conjunto de scripts y firmas que permiten encontrar posibles fallos de seguridad en el código fuente utilizando la utilidad grep de GNU. Es comparable a otras aplicaciones de análisis estático como RATS, SWAAT y flaw-finder, al tiempo que mantiene los requisitos técnicos al mínimo y es muy flexible.

Instalación

git clone https://github.com/wireghoul/graudit

Opcionalmente podemos crear un enlace simbólico en el path:

ln -s ~/graudit/graudit ~/bin/graudit

Uso
graudit [opts] /path/to/scan

OPTIONS
  -d <dbname> database to use or /path/to/file.db (uses default if not specified)
  -A scan ALL files
  -x exclude these files (comma separated list: -x *.js,*.sql)
  -i case in-sensitive scan
  -c <num> number of lines of context to display, default is 2

  -B supress banner
  -L vim friendly lines
  -b colour blind friendly template
  -z supress colors
  -Z high contrast colors
  
  -l lists databases available
  -v prints version number
  -h prints this help screen

Bases de datos

graudit usa expresiones regulares extendidas (POSIX) para sus firmas y viene con varias bases de datos listas para usar. Se pueden ampliar las bases de datos existentes o crear las propias si necesitamos firmas adicionales.

Las bases de datos se pueden cargar desde múltiples ubicaciones, el orden de precedencia es el siguiente:
  • Ubicación personalizada especificada a través de la variable de entorno GRDIR
  • /usr/share/graudit/
  • $HOME/.graudit/
  • Una firma/directorio relativo desde la ubicación graudit
  • Cualquier archivo que se especifique con una ruta completa, es decir: /home/user/my.db
  • Las reglas se pueden leer desde stdin proporcionando - o /dev/stdin  como la base de datos
Se incluyen las siguientes bases de datos:
  •     actionscript
  •     android
  •     asp
  •     c
  •     default (used if -d argument is omitted)
  •     dotnet
  •     exec
  •     fruit
  •     ios
  •     java
  •     js
  •     perl
  •     php
  •     python
  •     rough
  •     ruby
  •     secrets
  •     spsqli
  •     sql
  •     strings
  •     xss

Github: https://github.com/wireghoul/graudit

Comentarios

  1. "require", "include", etc son construcciones del lenguaje, como "echo", por lo que no necesitan paréntesis como las funciones. Tus "grep" solo encontrarán coincidencias de usos innecesarios de los paréntesis, aunque a grandes rasgos es un buen listado de patrones rápidos. Buen trabajo :)

    ResponderEliminar

Publicar un comentario