Advanced Search, Applied through dorks ("set of search operators."), Capture sensitive information, failures in servers. Group aimed at advanced filters to search engines & Digital Security Research.
Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts,we should keep in mind that it is also common in other technologies such as JSP, ASP and others.
In successful cases If the above mentioned conditions are met, an attacker would see something like the following:
Jameh, who actually writes and reads 'Jame' which is the Tupi Guarani means hidden, mysterious, aims to conduct a brute-force hashed passwords contained in the /etc /shadow, passing the salt and hash of the encrypted password he tries to break through the dictionary password.
Exploring the server password file... LOCAL FILE INCLUSION Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion $validation['LOCAL-FILE-INCLUSION-01'] = '/root:/'; $validation['LOCAL-FILE-INCLUSION-02'] = 'root:x:0:0:'; $validation['LOCAL-FILE-INCLUSION-03'] = 'mysql:x:'; Finding any of these values the script alert as vulnerable. Exploring the server wp-config.php file... CMS WORDPRESS As the name suggests, if the web application doesn’t check the file name required by the user, any malicious user can exploit this vulnerability to download sensitive files from the server. Arbitrary File Download vulnerability file wp-config.php http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271 http://www.acunetix.com/vulnerabilities/web/wordpress-plugin-slider-revolution-arbitrary-file-disclosure $validation['CMS-WORDPRESS-01'] = "define('DB_NAME'"; $validation['CMS-WORDPRESS-02'] = "define('DB_USER'"; $validation['CMS-WORDPRESS-03'] = "define('DB_PASSWORD'"; $validation['CMS-WORDPRESS-04'] = "define('DB_HOST'"; Finding any of these values the script alert as vulnerable.
O Nmap Scripting Engine (NSE) é um dos recursos mais poderosos e flexíveis do Nmap. Ele permite aos usuários escrever (e partilhar) scripts simples para automatizar uma ampla variedade de tarefas de rede. Esses scripts são executados em paralelo com a velocidade e eficiência que se espera do Nmap. Os usuários podem contar com a crescente e diversificada base de dados de scripts distribuídos com o Nmap, ou escrever o seu próprio para atender às necessidades personalizadas, os scripts Nmap Scripting Engine são implementados usando linguagem de programação Lua, Nmap API e um número de realmente poderosas Bibliotecas NSE. LUA: Lua Tutorials - www.dev-hq.net NMAP API: Nmap API NSEDOC: nsedoc (nse)
Os scripts NSE são (pack) em diferentes categorias:
auth, broadcast, brute, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe,vuln
configuando o nosso script NSE dentro de uma destas categorias permite-nos chama-lo a ele e todos
os scripts dentro dessa mesma categoria usando a 'flag' (--script <categoria> <target>). o seguinte
exemplo "irá correr o nosso script e todos que se encontrarem dentro da categoria 'discovery'" exemplo: nmap -sS -Pn -p 80 --script discovery <target>
Os scripts NSE são divididos em 4 secções:
O 'HEAD' contém meta-dados que descreve a funcionalidade do modulo, autor, impacto, categoria e outros dados descritivos.
As 'DEPENDENCIES' (bibliotecas lua necessarias) ao uso da API de programação do nmap
A 'RULE SECTION' define as condições necessárias para o script executar. Esta secção deve conter pelo menos uma função desta lista: portrule, hostrule, prerule, postrule. Para os fins deste tutorial (e a maioria dos scripts), vou concentrar-se no portrule que pode executar verificações sobre ambas as propriedades de host e porta antes de correr o script. No script abaixo, portrule se aproveita da API do nmap para verificar se há alguma porta http aberta para executar os commands da secção 'the action section'.
A 'ACTION SECTION' define a lógica do script, Na tradição de K&R (kernighan & ritchie) eu vou simplesmente dar a saída "Olá, mundo!" para qualquer porta aberta http usando a API 'return' para fazer o output.
hello.nse
Vamos começar com um script que simplesmente irá imprimir "hello world" para todas as portas HTTP encontradas abertas.
Abra um editor de texto e escreva o seguinte trecho em 'hello.nse' em seu diretório home.
------------------------------ The Head Section ------------------------------
description =[[
Author: r00t-3xp10it
INURLBR AULA - escrevendo o meu primeiro script NSE para o nmap
------------------------------ The Rule Section ------------------------------
portrule = shortport.http
------------------------------ The Action Section ------------------------------
action =function(host, port)
return"Hello world!"
end
Descrição: na secção 'head' definimos a categoria como 'discovery and safe', para correr este script e todos contidos na categoria 'discovery' basta executarmos 'nmap -sV -p 80,8080 --script discovery <target>', na secção 'Dependencies' chamamos as bibliotecas 'http & shortport', na secção 'the rule section' vamos nos servir da biblioteca 'shortport' para verificar se o <target> está a correr alguma porta com o protocol 'http' abertas, para podermos executar a secção 'the action section' a 'funtion(host, port)' vai executar o command "hello world!" (display no terminal), P.S. a portrule 'shortport.http' verifica todos os protocolos http based, like:http, https, ipp, http-alt, https-alt, vnc-http, oem-agent, soap, http-proxy, (descrição da biblioteca 'shortport.lua')...
Vamos construir um Script NSE rápido para verificar se o /path/arquivo/pasta selecionado existe no alvo webserver verificando os codigos de retorno da API do google. "o comportamento padrão será procurar o arquivo robots.txt se não for introduzido um argumento (@args) para procurar um file/path diferente", os '@argumentos' são lançados pela 'flag' --script-args <nome do argumento>= neste caso vai servir para pedir ao utilizador para entrar um nome diferente do valor default (/robots.txt) a procurar no target, vamos construir o proximo script em 4 secções 'head, dependencies, the rules section, the action section' para mais facil compreenção:
---'THE HEAD SECTION'---
description =[[
Author: r00t-3xp10it
Quick NSE script to check if the selected file/path/folder exists
on target webserver by checking google API return codes.
'default behavior its to search for robots.txt file'
-- Seach for string stored in variable @args.file or use default
local file = stdnse.get_script_args(SCRIPT_NAME..".file")or"/robots.txt"
Descrição: a biblioteca 'shortport' vai se servir da função 'port_or_service' para só executar a secção 'the action section' se todos os valores retornarem correctos (port 80 tcp http open), a biblioteca 'stdnse.get_script_args' vai ler o que foi inserido no @argumento (e procurar por essa string) ou então vai procurar pelo valor default (/robots.txt) se não for utilizada a 'flag' '--script-args file='
-- Check google API return codes to determine if file exists
if(response.status ==200)then
return file.."\n : STRING FOUND...\n : returned 200 OK\n"
elseif(response.status ==400)then
return file.."\n : BadRequest...\n : returned 400 BadRequest\n"
elseif(response.status ==302)then
return file.."\n : Redirected...\n : returned 302 Redirected\n"
elseif(response.status ==401)then
return file.."\n : Unauthorized...\n : returned 401 Unauthorized\n"
elseif(response.status ==404)then
return file.."\n : STRING NOT FOUND...\n : returned 404 NOT FOUND\n"
elseif(response.status ==403)then
return file.."\n : Forbidden...\n : returned 403 Forbidden\n"
elseif(response.status ==503)then
return file.."\n : Service_unavailable...\n : returned 503 Service_unavailable\n"
else
return file.."\n : UNDEFINED ERROR...\n : returned "..response.status.."\n"
end
end
Descrição: a função 'action = function(host, port)' vai executar os commands no <target>, na função seguinte a biblioteca 'http.get' retorna um recurso com um pedido GET, a API NSE 'response.status' vai verificar o codigo de retorno da API do google para determinar se o file existe, e vamos nos servir da API 'return' vai fazer o display do output...
Detecta a vulnerabilidade MS15-034 (HTTP.sys) em servidores Microsoft IIS. e explora a condição denial-of-service usando argumentos de script (--script-args D0S=exploit) ou podemos verificar (escanear) ainda mais usando outro argumento (--script-args uri =/wellcome.png), o comportamento padrão 'default' será verificar pela existencia da vulnerabilidade, e só se for introduzido o @argumento D0S (--script-args D0S=exploit) é que será explorado o denial-of-service.
versões afetadas são o Windows 7,8,8.1, Windows Server 2008 R2, 2012 e 2012R2. An analysis of ms15-034:an-analysis-of-ms15-034
