Clique aqui para voltar à página inicial
Última modificação em (mês/dia/ano/horário): 07/19/01 18:12:52
Código Vermelho deixa "Globo On" off

Descoberto apenas no dia anterior, um verme (worm) conhecido como Code Red (Código Vermelho) foi o responsável pela suspensão das atividades do site O Globo On no dia 19/7/2001, impedindo o acesso dos internautas à página principal desse portal brasileiro e desconfigurando outras páginas ligadas ao sistema.

Página principal do Globo On às 16 horas do dia 19/7/2001, vista pelo Internet Explorer
Segundo explicou o estudioso Roberto Cury Jr. na lista de debates sobre negócios Widebiz, o verme "afeta todas as versões do IIS (Internet Information Server), incluindo o Outlook Web Access (Microsoft Exchange). O curioso é que este verme utiliza um buffer overflow descoberto em junho. Após infectar um sistema desatualizado, procura por outras máquinas vulneráveis na Internet e realiza o famoso defacement (N.E.: adulteração da página Web). A página alterada contém uma mensagem simples. Quem usa isso deve atualizar a máquina (ou mudar de plataforma)."
Página principal do servidor Globo On, vista em Netscape, em 19/7/2001
No caso da Globo On, a mensagem colocada na página, disponível na Web no meio da tarde, era "Welcome to ! Hacked By Chinese!" (não é aconselhável visitar esse site).

Roberto informou ainda as páginas onde podem ser obtidos maiores detalhes sobre o problema e o patch (arquivo de correção):

Secure Internet Information Services Checklist:

Segundo a equipe técnica da Microsoft, no Microsoft Security Bulletin MS01-033, o bug afeta o Microsoft Index Server 2.0 e o Indexing Service no Windows 2000. A empresa também reconhece a vulnerabilidade do novo Indexing Service no Windows XP beta (versão de teste, pois o produto será lançado no mercado dentro de alguns meses). A informação é também dada pelo site eEye Digital Security, que classifica o problema como de alta gravidade. A Microsoft promete ainda que durante o dia 19/7/2001 divulgará o "Microsoft Knowledge Base article Q300972", com mais detalhes, disponível no seu suporte via Internet.

A razão é que atacantes podem ganhar, de um computador remoto, total controle sobre o sistema afetado que esteja rodando uma instalação padrão daqueles ambientes operacionais e usando o programa de servidor Web MS IIS (quem tiver o ambiente operacional mas não usar esse programa de servidor não corre o risco, segundo a Microsoft). Por conseguir acesso ao nível de sistema, o atacante pode realizar inúmeras ações, como a instalação e ativação de programas, manipulação de bancos de dados do servidor Web, adicionar, mudar ou apagar arquivos e páginas etc. 

Este é o trecho principal do relatório do eEye Digital Security:

The Discovery:
Riley Hassell was at it again one day working to further advance eEye's CHAM (Common Hacking Attack Methods) technology so that Retina could better search for unknown vulnerabilities in software and so that SecureIIS could better protect from unknown IIS vulnerabilities.

After a few hours of running some custom CHAM auditing code one of our Web servers in our lab eventually came to a halt as the IIS Web server process had suddenly died.

We investigated the vulnerability further and found that the .ida ISAPI filter was susceptible to a typical buffer overflow attack.

                  GET /NULL.ida?[buffer]=X HTTP/1.1
                  Host: werd

                  Where [buffer] is aprox. 240 bytes.

The Exploit, as taught by Ryan "Overflow Ninja" Permeh:

This buffer overflows in a wide character transformation operation. It takes the ASCII (1 byte per char) input buffer and turns it into a wide char/unicode string (2 bytes per char) byte string. For instance, a string like AAAA gets transformed into \0A\0A\0A\0A. In this transformation, buffer lengths are not checked and this can be used to cause EIP to be overwritten.

This sounds like any normal overflow to date, however there are a few sticking points in doing anything useful with this. First, you transform 2 bytes into 4, 2 of which you have no control over. This would be a bad situation, but not impossible to exploit. However, the 2 bytes that you do not have control over happen to be nulls. Basically, we need to take this 2 byte string and somehow get it to point to our code.
Traditionally, we use our overwritten EIP to jump to a call esp, or jmp esp, jumping back to code we have positioned on the stack to implement whatever it is our shellcode would like to do. In this case, however, there is a problem.

                  GET /a.ida?[Ax240]=x HTTP/1.0

The above example overwrites EIP with 0x00410041. Again, traditionally, we insert our shellcode in the same buffer we overflow, however we run into the problem that then our code would also face the same expansion that our EIP bytes face. This makes writing shellcode a horrible pain. There are two methods of doing this:

1. custom shellcode: It might be possible to write shellcode that works fine with NULL byes every other byte. It would probably have to be very simple, but this could be possible.

2. encode: You could probably write a decoder that takes a string of 0x0041 and rewrites it on the stack into actual single byte code. This would have to be written completely in 0x00bb opcodes, most likely a challenge in itself (similar to the above custom shellcode, but only a decoder would need to be written).

This would, of course only be possible if we could find a point in memory that we could reach using only 0x00aa00bb. This gives us only about 65k spots in memory to look for jump bytes, a pretty dismal situation.

Exploiting Wide Char Strings In Practice
We got lucky using this method. We were basically limited to a very very small range of memory in which to find jump bytes. We thought we were losing the battle until we realized that IIS/ISAPI uses 0x00aabbcc as its memory range for allocated heap. We developed a spray technique in an attempt to push enough data into the heap so that the bytes we require will be there when we need to jump to them.

For instance, in Windows 2000 Service Pack 1, we noticed that we had request bytes at around 0x0042deaa. Since the closest we could get to this was 0x00430001 (by overflowing with C%01 at the end of our overflow string. This offered us an intriguing possibility -- perhaps we could push more stuff into a request, causing more heap memory to be used, pushing our request closer to where we want to be.

                  GET /a.ida?[Cx240]=x HTTP/1.1
                  eEye: [Cx10,000][shellcode]

Now, we overflow the EIP with 0x00430043. With our new much larger request, 0x00430043 happens to be inside the large C buffer we setup. This acts as a slide in our code, executing down to our shellcode.

The Warning
Now for the warning. With this technique of forceful heap violation, everything is relative to what is there to begin with. We noticed that in any situation, we found 4-5 different copies of our requests in the 0x00aabbcc memory range. This means that perhaps 0x430043 is not the best spot in memory, however it is the one we chose in our forthcoming sample exploit (the exploit we will provide only executes file writing; we provided Microsoft with shell-binding code but will not publicly release this code). The other potential problem with this attack is that different systems may have different heap usages. In our internal tests, we noticed that heap usage differed depending on which ISAPI extensions were enabled at any time. Also, requests that cause faults handled by exception handlers that do not free their heaps may cause certain parts of the heap to become unusable, causing those spots to not be reused. This is not a problem for Windows 2000 because it is nice enough to restart itself (giving us a nice clean heap to work with). Windows XP appears to act similarly, however we did not focus our research with this beta OS. This is, however, potentially a problem with NT 4, which will crash if exploited incorrectly. Again, like all other IIS overflows, this attack is not logged, causing only a fault in IIS and crashing it.

All of the technical talk aside, we do have working exploits for Windows NT 4.0 and Windows 2000 systems.

Proof-Of-Concept Exploit
We will be posting a proof-of-concept (file writing) exploit to our Web site within the next few days.

The Fallout
According to Netcraft (, there are roughly 5.9 Million Web servers running IIS; however, the true number of IIS Web servers is much larger when you count internal network servers. Any of these Web servers that have the default .ida ISAPI filter installed are most likely vulnerable.

Página do eEye Digital Security sobre o problema que afetou o Globo On