⚡ Não perca: notícia importante no ar! ⚡
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Os invasores estão explorando uma nova vulnerabilidade não corrigida no Magento Open Source e no Adobe Commerce que permite executar códigos maliciosos no servidor de uma loja on-line sem fazer login, disse a empresa holandesa de segurança de comércio eletrônico Sansec em um comunicado publicado em 5 de setembro.
A Sansec, que descobriu a falha e a chamou de StyleSmuggler, disse que os ataques começaram em 4 de setembro. “A Sansec está publicando antecipadamente porque as lojas estão sendo comprometidas no momento”, disse a empresa.
Até 6 de setembro, a Adobe não publicou um comunicado, um identificador CVE, um patch ou uma solução alternativa, e seu índice de boletins de segurança do Adobe Commerce não lista nada após a atualização de 11 de agosto.
Um ataque bem-sucedido dá ao invasor a execução do código no servidor da loja e instala um backdoor persistente. Sansec disse que todas as versões atuais foram afetadas, incluindo 2.4.9, e que reproduziu toda a cadeia não autenticada em instalações limpas de código aberto do Magento 2.4.7, 2.4.8 e 2.4.9.
Sua primeira vítima executou 2.4.6-p15 com as atualizações de segurança de julho e agosto de 2026 da Adobe aplicadas, que é o nível de patch mais recente que a Adobe oferece para essa linha de lançamento e aquele que o boletim de agosto da Adobe rotula como 2.4.6-2026-ago.
A Sansec não publicou uma reprodução no Adobe Commerce ou no Adobe Commerce on Cloud, e a Adobe não confirmou quais versões foram afetadas. A Sansec não informou quantas lojas foram comprometidas.
O conselho provisório dos pesquisadores para lojas que não executam seu produto Shield é desativar temporariamente o GraphQL até que a Adobe libere uma correção.
O Disrex Group, uma empresa de hospedagem e desenvolvimento Magento que hospeda e responde a duas das lojas comprometidas, observa que as vitrines de aplicativos da web progressivas e sem cabeça exigem GraphQL, enquanto a maioria das vitrines clássicas e Hyvä não.
O próximo lançamento de segurança agendado da Adobe será em 8 de setembro, disse Sansec, e ainda não se sabe se esse lançamento cobrirá esse bug.
As descobertas da Disrex são evidências independentes de exploração externa à Sansec. Em um repositório de respostas a incidentes publicado em 5 de setembro, a empresa disse que administrou duas lojas comprometidas e uma terceira que foi atacada, mas não violada, e que suas regras de servidor web são baseadas no tráfego de ataque capturado em uma das lojas comprometidas. Em respostas às perguntas do The Hacker News, a Disrex disse que ambas as lojas executam Magento Open Source em vez de Adobe Commerce, e que ela mesma as hospeda por meio de sua marca de hospedagem RexHosting.
A loja Disrex rotula Store A rodava Magento Open Source 2.4.8 e era cliente Sansec Shield, com o módulo instalado, habilitado e licenciado. Ele foi atingido às 23h10 UTC de 4 de setembro, horas antes das primeiras regras de bloqueio da Sansec para essa falha entrarem em vigor, e Disrex disse que o Shield estava ativo e bloqueando outro tráfego malicioso contra a loja no momento. A Loja B, que não era cliente do Shield, executou o Magento 2.4.7-p2, um nível de patch de segurança que o histórico de versões da Adobe data de agosto de 2024, oito níveis atrás do atual 2.4.7-p10. Ele foi atingido pela primeira vez às 00h55 UTC de 5 de setembro, disse Disrex, e é a loja de onde foram retiradas as regras do servidor web da empresa e a leitura do código vulnerável.
Ambas as lojas foram violadas dentro do intervalo de aproximadamente oito horas entre a primeira exploração observada pela Sansec e o momento em que existia qualquer defesa, disse Disrex. “O status do patch era irrelevante aqui, que é a parte que os comerciantes mais precisam ouvir”, disse a empresa ao The Hacker News.
O repositório carrega seu próprio aviso. “Este repositório foi escrito com assistência de IA, durante um incidente ao vivo, em poucas horas”, diz seu README, acrescentando que não foi revisado, que suas regras Apache nunca foram executadas em um servidor Apache ativo e que a maioria de seus comandos de limpeza foram escritos em vez de executados.
Os indicadores da Sansec descrevem o implante como um processo em segundo plano disfarçado em [kworker/u:8:0], um nome que pertence a um thread do kernel Linux, com um binário instalado em ~/.local/share/.gvfsd/gvfsd-user no diretório inicial do usuário do site, em vez da raiz da web, e uma entrada cron que o reinicia a cada cinco minutos.
Disrex descreveu o binário como um programa Rust despojado e vinculado estaticamente de aproximadamente 1,9 MB construído para x86-64 e arm64, e disse que a entrada do cron é gravada diretamente no arquivo de spool em /var/spool/cron/crontabs/, portanto, o log do sistema não mostra nenhuma substituição do crontab.
Uma loja carregou a mesma linha 1.728 vezes, e o implante a adicionou novamente um segundo após a remoção.
Em uma das duas lojas, o implante não fez nenhuma conexão de saída. Ele mantinha 28 conexões com a própria instância Redis da loja na porta 6379 e lia o armazenamento de sessão do Magento a partir dela, disse Disrex, e nenhuma de suas duas capturas de pacotes, cada uma com mais de 200 MB e tiradas enquanto o implante estava ativo, continha um único pacote para o host de download ou o endereço de comando e controle
A Sansec, que descobriu a falha e a chamou de StyleSmuggler, disse que os ataques começaram em 4 de setembro. “A Sansec está publicando antecipadamente porque as lojas estão sendo comprometidas no momento”, disse a empresa.
Até 6 de setembro, a Adobe não publicou um comunicado, um identificador CVE, um patch ou uma solução alternativa, e seu índice de boletins de segurança do Adobe Commerce não lista nada após a atualização de 11 de agosto.
Um ataque bem-sucedido dá ao invasor a execução do código no servidor da loja e instala um backdoor persistente. Sansec disse que todas as versões atuais foram afetadas, incluindo 2.4.9, e que reproduziu toda a cadeia não autenticada em instalações limpas de código aberto do Magento 2.4.7, 2.4.8 e 2.4.9.
Sua primeira vítima executou 2.4.6-p15 com as atualizações de segurança de julho e agosto de 2026 da Adobe aplicadas, que é o nível de patch mais recente que a Adobe oferece para essa linha de lançamento e aquele que o boletim de agosto da Adobe rotula como 2.4.6-2026-ago.
A Sansec não publicou uma reprodução no Adobe Commerce ou no Adobe Commerce on Cloud, e a Adobe não confirmou quais versões foram afetadas. A Sansec não informou quantas lojas foram comprometidas.
O conselho provisório dos pesquisadores para lojas que não executam seu produto Shield é desativar temporariamente o GraphQL até que a Adobe libere uma correção.
O Disrex Group, uma empresa de hospedagem e desenvolvimento Magento que hospeda e responde a duas das lojas comprometidas, observa que as vitrines de aplicativos da web progressivas e sem cabeça exigem GraphQL, enquanto a maioria das vitrines clássicas e Hyvä não.
O próximo lançamento de segurança agendado da Adobe será em 8 de setembro, disse Sansec, e ainda não se sabe se esse lançamento cobrirá esse bug.
As descobertas da Disrex são evidências independentes de exploração externa à Sansec. Em um repositório de respostas a incidentes publicado em 5 de setembro, a empresa disse que administrou duas lojas comprometidas e uma terceira que foi atacada, mas não violada, e que suas regras de servidor web são baseadas no tráfego de ataque capturado em uma das lojas comprometidas. Em respostas às perguntas do The Hacker News, a Disrex disse que ambas as lojas executam Magento Open Source em vez de Adobe Commerce, e que ela mesma as hospeda por meio de sua marca de hospedagem RexHosting.
A loja Disrex rotula Store A rodava Magento Open Source 2.4.8 e era cliente Sansec Shield, com o módulo instalado, habilitado e licenciado. Ele foi atingido às 23h10 UTC de 4 de setembro, horas antes das primeiras regras de bloqueio da Sansec para essa falha entrarem em vigor, e Disrex disse que o Shield estava ativo e bloqueando outro tráfego malicioso contra a loja no momento. A Loja B, que não era cliente do Shield, executou o Magento 2.4.7-p2, um nível de patch de segurança que o histórico de versões da Adobe data de agosto de 2024, oito níveis atrás do atual 2.4.7-p10. Ele foi atingido pela primeira vez às 00h55 UTC de 5 de setembro, disse Disrex, e é a loja de onde foram retiradas as regras do servidor web da empresa e a leitura do código vulnerável.
Ambas as lojas foram violadas dentro do intervalo de aproximadamente oito horas entre a primeira exploração observada pela Sansec e o momento em que existia qualquer defesa, disse Disrex. “O status do patch era irrelevante aqui, que é a parte que os comerciantes mais precisam ouvir”, disse a empresa ao The Hacker News.
O repositório carrega seu próprio aviso. “Este repositório foi escrito com assistência de IA, durante um incidente ao vivo, em poucas horas”, diz seu README, acrescentando que não foi revisado, que suas regras Apache nunca foram executadas em um servidor Apache ativo e que a maioria de seus comandos de limpeza foram escritos em vez de executados.
Os indicadores da Sansec descrevem o implante como um processo em segundo plano disfarçado em [kworker/u:8:0], um nome que pertence a um thread do kernel Linux, com um binário instalado em ~/.local/share/.gvfsd/gvfsd-user no diretório inicial do usuário do site, em vez da raiz da web, e uma entrada cron que o reinicia a cada cinco minutos.
Disrex descreveu o binário como um programa Rust despojado e vinculado estaticamente de aproximadamente 1,9 MB construído para x86-64 e arm64, e disse que a entrada do cron é gravada diretamente no arquivo de spool em /var/spool/cron/crontabs/, portanto, o log do sistema não mostra nenhuma substituição do crontab.
Uma loja carregou a mesma linha 1.728 vezes, e o implante a adicionou novamente um segundo após a remoção.
Em uma das duas lojas, o implante não fez nenhuma conexão de saída. Ele mantinha 28 conexões com a própria instância Redis da loja na porta 6379 e lia o armazenamento de sessão do Magento a partir dela, disse Disrex, e nenhuma de suas duas capturas de pacotes, cada uma com mais de 200 MB e tiradas enquanto o implante estava ativo, continha um único pacote para o host de download ou o endereço de comando e controle
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #magento #e #adobe #commerce #zeroday #sem #patch #explorados #em #lojas #online #backdoor
🔔 Siga-nos para não perder nenhuma atualização!
Postar um comentário