O padrão que normalmente observamos quando lidamos com kits de exploits, inicia-se quando um site legítimo fica comprometido e passa a redireccionar os visitantes para conteúdo malicioso. Técnicas como injecção de iFrames ou redireccionamentos por HTTP são normalmente observadas.
Porém, esta semana, demos conta de uma variante interessante enquanto explorávamos estas formas de cibercrime. Mais especificamente, reparámos que um site comprometido, na realidade continha código que interagia com o utilizador ao apresentar uma mensagem falsa acerca de um script que se encontra a atrasar o browser.
O código responsável por esta interacção consiste num formulário HTML injectado que apenas é mostrado quando o browser do visitante é o Internet Explorer. É possível observarmos também que alguns dados são enviados aquando do pedido por POST, algo a que voltaremos mais à frente.
Claro que dar um clique em Cancelar ou OK tem exactamente o mesmo resultado, redireccionando o visitante para o kit de exploits Angler ao retornar um pequeno conjunto de código HTML e Javascript.
Vamos voltar agora aos dados enviados com o pedido POST. Podemos ver que está com encriptação Base64, sendo que a desencriptação pouco revela.
>>> ua_base64 =
‘tlP7Vt89hmr1vjdAW8YqmDT/sGFiyxROsPBX45R6HxinEeZC+YGrgEA0mmA3 NDEJUYzgWm29EKShU2QPqxBXzVNMJvpfJN3QcVGGehPCNNXOlxo0JE 9 4z0RTBgCq0VubolrWHmAexV14+cqx6qILC6z1EZDl4JFYd32wrM ZrhNinl47lzpnvXwPluNsmh0CA’
>>> base64.b64decode(ua_base64)
‘\xb6S\xfbV\xdf=\x86j\xf5\xbe7@[\xc6*\x984\xff\xb0ab\xcb\x14N\xb0\xf0W \xe3\x94z\x1f\x18\xa7\x11\xe6B\xf9\x81\xab\x80@4\x9a`741\tQ\x8c\xe0Zm \xbd\x10\xa4\xa1Sd\x0f\xab\x10W\xcdSL&\xfa_$\xdd\xd0qQ\x 86z\x13\xc24 \xd5\xce\x97\x1a4$Ox\xcfDS\x06\x00\xaa\xd1[\x9b\xa2Z\xd6\x1e` \x1e\xc5]x \xf9\xca\xb1\xea\xa2\x0b\x0b\xac\xf5\x11\x90 \xe5\xe0\x91Xw}\ xb0\xac\xc6k\x84\xd8\xa7\x97\x8e\xe5\xce\x 99\xef_\x03\xe5\xb8 \xdb&\x87@\x80′
Podemos adivinhar que o parâmetro com o nome ua contém o User-Agent do browser.
“Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET4.0C; .NET4.0E; BOIE8;ENUSMSCOM)”.
E se os parâmetros estivessem todos XOR com o mesmo conjunto de dados? Vamos utilizar este ponto de partida para obtermos a chave necessária para a desencriptação. Se a nossa teoria estiver correcta seremos capazes de visualizar o URL da página que contém o agente malicioso.
import base64
def xor(message, key):
decrypted = “”
for i in range(0, len(message)):
decrypted += chr(ord(message[i]) ^ ord(key[i%len(key)]))
return(decrypted)
ua = “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET4.0C; .NET4.0E; BOIE8;ENUSMSCOM)”
ua_plaintext = ua.lower()
ua_base64 = “tlP7Vt89hmr1vjdAW8YqmDT/sGFiyxROsPBX45R6Hxi nEeZC+YGrgEA0mmA3NDEJUYzgWm29EKShU2QPqxBX zVNMJvpfJN3QcVGGehPCNNXOlxo0JE94z0RTBgCq0VubolrWH mAexV14+cqx6qILC6z1EZDl4JFYd32wrMZrhNinl47lzpnvXwPluNsmh0CA”
furl_base64 = “s0j1T4l+yCai5DANXd 0gmz38sX5pwRVb/vhQpcU9Qlj8G6tQ5Nc=”
keystream = xor(base64.b64decode(ua_base64), ua_plaintext)
print “Decrypted furl:”
print(xor(base64.b64decode(furl_base64), keystream))
$ python angler-dexor.py
Decrypted furl:
hxxp://cct7m.xenybuvifd.net/4genk1met8
Confirma-se. Tipicamente os visitantes são direccionados automaticamente para o kit de exploits quando visitam um site comprometido, então porque mostrar uma mensagem primeiro? Pode ser para prevenir que sistemas automáticos (ferramentas de análises de malware, bots, entre outros) cheguem ao kit de exploits, tornando mais difícil a detecção da ameaça.
