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

1 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