04.20.07

What I learned this week…

Posted in IT at 12:03 am by Tyler Reguly

I always base the quality of my week on what I've learned... It's not the only criteria obviously but it is one of them... If I've learned nothing then the week seems like a total waste... yet if I learn just one or two things... even if they are common knowledge to everyone else... as long as they are new to me... I'm excited. There's something about learning these little tidbits... Random information that was out there for the taking that you'd just never looked into before.

So what did I learn this week?

I learned how to devise a link-local address in IPv6. I had originally thought it was only Microsoft's method due to some misinformation on a website, however I was pointed to the RFC that shows it is the method for creating it. So I guess I learned two things... kinda.

Method:

1. Take the MAC address. - 00-0C-F1-EB-F0-43
2. Insert FF-FE between the third and fourth bytes. - 00-0C-F1-FF-FE-EB-F0-43
3. Complement the second low order bit of the first byte. - 02-0C-F1-FF-FE-EB-F0-43 (known at this point as the Interface Identifier)
4. Combine the prefix (FE80::/64) with the interface identifier. - FE80::20C:F1FF:FEEB:F043

The IPv6 link-local address is FE80::20C:F1FF:FEEB:F043

The other interesting tidbit I picked up was that egrep on older systems didn't support curly braces {}.  Since most of my regex experience has come from Python, I actually use curly braces a fair amount. I decided to test this and sure enough on Solaris 6 (for example), curly braces don't work.

# echo 'AAAAA' | egrep 'A{4}'
#

Yet on a fairly up-to-date FreeBSD system:

$ echo 'AAAAA' | egrep 'A{4}'
AAAAA

Anyways, just thought I'd share those.... Now maybe you've learned something new this week... Enjoy!

Permalink 1 Comment      Digg this post      

04.16.07

RPC DNS Worm

Posted in IT, Security at 9:50 pm by Tyler Reguly

Yesterday I questioned if we'd see a worm related to the RPC DNS Vuln...

Both McAfee (additional info) and ISC are reporting that we are.

According to the ISC the worm is only scanning port 1025... I question whether this was the displayed behavior or the worm is actually hard coded only to look at this port... It seems like poor design if it's only looking at port 1025.

If anyone has a sample of the worm, please let me know because I'd love to get ahold of it.

Permalink      Digg this post      

04.15.07

The DNS Vuln

Posted in Exploits, IT, Security, Vulnerabilities at 4:49 pm by Tyler Reguly

It's amazing how quickly the community can respond... In the past 24 hours I've seen exploits from three sources for this vulnerability. We've got an exploit for metasploit, an exploit written in python and one written in C. (I considered whether or not I'd link to these but since they're all publicly available... I might as well). Here are a couple images of the exploit.

Exploit executed in Metasploit:

Looking at the process on the vulnerable box:

So here's the information we've got from all the various sources:

• The vulnerable function is: extractQuotedChar()
• This function is reached via:
  • Interface: 50abc2a4-574d-40b3-9d66-ee4fd5fba076 v5.0
  • Operation: DnssrvQuery
  • OpCode: 0x01
• The attack can be performed anonymously against the listening RPC Interface (a TCP port between 1024 and 5000).
• The attack can also be performed with credentials against port 445.
• Original Attacks: April 4th and 5th against two US Universities
• Original Attack Details (Source):
  • Shellcode binds to TCP port 1100.
  • Attacker uploads a VBscript on this port and then runs it.
  • VBscript downloads an executable DUP.EXE (MD5: a5ae220fec052a1f2cd22b4eb89a442e) from 203.66.151.92/images/.
  • Executable is self-extracting and contains PWDUMP v5 and an associated DLL.
• Microsoft Advisory (Including mitigation information)
• Mitigation: How to script the mitigation technique across an entire domain.

Now I guess the question remains, "Will we see an Out-of-Band Update to fix this issue?"

It's an interesting question because the views are so varied on the seriousness of this issue. An example of this debate is this thread on the dns-operations mailing list.

So it's fair to assume that this won't be a HUGE issue... as others have said this won't be Slammer or Code Red. That doesn't mean this isn't a serious issue. I also question the flawed logic I've seen, on various discussion boards, mailing lists and even in conversations with friends, on who this will affect and why this would "only affect idiots".

I think the people making these assumptions are from corporate environments and the actual IS industry... They're forgetting about small and medium businesses. I think this has much more serious consequences in the SMB environment. Let's think about the number of SMBs out there... how many of these businesses have purchased SBS Server and popped it into their network. SBS is a security nightmare... all of your services on your domain controller, including Exchange, and them telling the user to place it live on the internet. I've walked into environments where the SBS is plugged into a Linksys router and that router is plugged into the internet connection. One might think, "Well the router will filter the affected ports"... right and wrong. The environments I've seen have been too lazy (or lacked the knowledge) to properly configure the router and setup forwarded ports for things like Exchange. Instead they've simply put the SBS on the DMZ, opening it up to the world... and to vulnerabilities such as this one.

So I am concerned by this... should someone decide to create a worm, that's a large number of zombied computers that they could have... A growing botnet based on insecure SMBs. It may not be an extraordinary number of computers but it would be substantial. I'd wager a guess that given a) the number of businesses that have slapped a setup together and b) the number of businesses that have relied on "on-site computer service professionals" that there are a large number of vulnerable computers sitting and waiting to be exploited.

Do I think this will ever be turned into a worm? Nope. Do I think this is serious and dangerous? You bet. I guess only time will tell.

Permalink 2 Comments      Digg this post      

04.13.07

Remote Code Execution in RPC on Windows DNS Server

Posted in IT, Security, Vulnerabilities at 12:05 am by Tyler Reguly

Microsoft has published an advisory on remote code executing via a vulnerability in RPC for Windows DNS Server. There are no details, however Microsoft is saying that it is a limited attack.  This vulnerability has been assigned CVE-2007-1748. Successful exploitation would allow code to be executed under the context LOCAL SYSTEM and anonymous exploitation is possible against Windows 2000 Server and Windows 2003 Server.

Permalink      Digg this post      

04.12.07

Limited Whois Results

Posted in IT, Phishing / Scams at 11:29 am by Tyler Reguly

RSnake has an interesting post on the Whois Daemon that is running for the .to TLD. It seems as though their modified daemon returns minimal results... masking all contact and registration information.

root:# whois tonic.to
Tonic whoisd V1.0
tonic
root:# whois task.to
Tonic whoisd V1.0
task    ns1.perpetualconnections.com    64.90.96.130    ns2.perpetualconnections.com    64.90.96.230

As RSnake points out this is a spammers dream.  I would add that the same is true for phishers.

Permalink      Digg this post      

Not Everything Can Be Improved With Technology.

Posted in IT, Security at 10:12 am by Tyler Reguly

I know that's a hard statement for a lot of people to believe, but it's the truth. RFID is a prime example of this. The list of things that RFID has been used for just keeps growing.

• Replacement of Keys
• Embedded in Keys
• Product Tracking (Warehouse)
• Product Tracking (Livestock)
• Payment Methods (Credit Cards)
• Passports
• Cookware
• Ink (for RFID Tattoos)
• Library Books
• and the list goes on...

The latest offering in the RFID embedded products are E-Plates. That's right, a license plate with active RFID embedded inside it. These are being investigated and rolled out for testing in the UK, or I probably never would have heard of them (link found via Thoughts of a Technocrat).

Given the demonstrations we've seen lately of the ease of which RFID can be cloned and replayed. I find this to be a dangerous place to put RFID.  Hell, instructions on building an RFID cloner can be easily obtained. RFID is also susceptible to viruses.

I contacted the manufacture of E-Plates with a series of questions covering concerns I had on the subject.

These questions included:

• How susceptible to wear and tear are the E-Plates?

• If you watch the marketing video provided by E-Plates you'll notice a scene where they discuss how secure the E-Plates are physically. Any attempt to to remove the E-Plate results in the outside separating from the inside. To demonstrate this a person in the video grabs the E-Plate, and with apparent ease, separates the two pieces. You also have to factor in that this is active RFID, meaning that a battery is required to power it... a battery that, as advertised, is designed to last a maximum of 10 years.
• Possible Sources of "wear and tear"

• Pulling/backing into a parking space and bumping a curb
• Minor accidents that would leave a traditional license plate with only a dent
• Vandals, who can easily render your license plate useless by pulling it apart
• The battery dies, meaning guaranteed license plate replacement every 10 years.

• How do these devices communicate with the Internet? Are they wifi capable? Will these devices that don't require messy installs need a CAT-5 cable run up every pole they are mounted on? What happens in remote locations?
• How secure is their communication across the internet? Can they be the subject of data interception, manipulation and theft? Could criminals intercept the data and replay altered data to hide the location of a stolen car? Is this protection to ensure that malicious individuals cannot use the information to perform their own tracking.

To ensure that I don't miss anything, I'd like to provide the companies complete response here:

Thank you for your enquiry. We have no comment to make.

That's all, and that's a direct copy and paste from the email.

This concept scares me. With the introduction of this, several things can happen:

• The government can track me. (More efficiently, easily and at a larger scale than they currently could.)
• Thieves can clone my license plate and make it appear as though I took part in a crime. (After all the manufacturer claims that these are completely secure and "uncloneable" (Like we haven't heard that before.))
• Thieves could use misdirection after committing a crime. Masking their RFID and having a clone of it appear across town, or perhaps swapping their RFID with another car.

I really think we need to sit back and think before we use technology in every little thing. At this point I'm waiting for the day when I sign a lease on an apartment and instead of handing me a set of keys, they pull out a needle and say, "Bend Over."

Permalink      Digg this post      

04.11.07

It Never Fails…

Posted in Exploits, IT, Security, Vulnerabilities at 5:58 pm by Tyler Reguly

Yet again we see it happening... Patch Tuesday rolls around and suddenly we're hit by more "0-days" for Microsoft products. This time it's primarily Office, but a heap-overflow in .HLP files was also released. McAfee AVERT Labs have been doing some research into the vulnerabilities, however they haven't had much to say yet. Initially they only addressed the Office flaws but came back later to include the .HLP heap-overflow. These 4 PoCs (2 DoS and  2 overflows) were released to the Full Disclosure mailing list by muts (of BackTrack fame). This was also discussed over at heise Security. They have mentioned that there's no proof yet that these are new vulnerabilities, they may actually be related to the vulnerabilities announced by eEye.

I guess only time will tell but this could mean an increase to the number of items on the 'Missing Microsoft Patches' list.

Permalink      Digg this post      

04.10.07

Grisoft Releases Free Anti-Rootkit Software

Posted in IT, Tools at 11:34 pm by Tyler Reguly

I, for one, have always been impressed with Grisoft's products. Their free AVG Anti-Virus is on par with any paid offerings from their competitors and, in many cases, it's better. It's also much less of a resource hog. So I was actually quite excited when I saw a press release today (yesterday now I suppose) from Grisoft stating that they were offering Anti-Rootkit software. While I haven't tried the software myself, I'd encourage everyone to give it a try and see how it works. Feel free to share your feedback as well.

Press Release Snip:

"Rootkits are computer code that attempt to hide their actions and processes, making the job of detecting the code and the harmful processes very difficult," explains Larry Bridwell, Global Security Strategist of GRISOFT. "AVG Anti-Rootkit is developed to detect and destroy rootkits effectively, without bothering users with false alarms."

Note: I said "yesterday now" because I typed this at 12:35 on the 11th, but apparently the server time is off because this showed up as 11:35 on the 10th.

Permalink      Digg this post      

Information Security Conferences, Workshops, and Training Calendar

Posted in IT, Security at 10:36 pm by Tyler Reguly

Short and sweet...

Dustin from TippingPoint provided this Google Calendar link on DailyDave earlier today. It's a Calendar that tracks IS conferences, workshops and training. It is rather indepth and impressive. Kudos and Thanks to Dustin as this is very handy to have access to.

Permalink      Digg this post      

“Hex Dump Port Forwarding Network Proxy Server”

Posted in IT, Tools at 9:14 am by Tyler Reguly

I know, it's a mouthful and a little repetitive  but I didn't name it. One of the RSS feeds that I subscribe to is the ASPN Python Cookbook. The recipe (source as text here) that was listed today was quite cool and useful. It's a small proxy server that dumps the hex output of the traffic that passes through it. It relies on the twisted network libraries and may be a little rough around the edges but it's looks quite interesting. It's like combining simpleproxy and tcpdump, without the ability to generate nice pcap files to load into Wireshark.

Sample Output:

you@oslo $ hexproxy.py 8080:www.google.com:80

2007-02-18 17:47:11,217 INFO listening on 8080 -> www.google.com:80
2007-02-18 17:47:11,217 INFO ready (Ctrl+C to stop)
2007-02-18 17:47:18,265 INFO client 11389528 opened connection -> server www.google.com:80
2007-02-18 17:47:18,312 INFO client 11389528 -> server www.google.com:80 (401 bytes)
-> 0000   47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A    GET / HTTP/1.1..
-> 0010   48 6F 73 74 3A 20 6F 73 6C 6F 3A 38 30 38 30 0D    Host: oslo:8080.
-> 0020   0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A    .User-Agent: Moz
-> 0030   69 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77    illa/5.0 (Window
-> 0040   73 3B 20 55 3B 20 57 69 6E 64 6F 77 73 20 4E 54    s; U; Windows NT
-> 0050   20 35 2E 30 3B 20 65 6E 2D 55 53 3B 20 72 76 3A     5.0; en-US; rv:
-> 0060   31 2E 38 2E 31 2E 31 29 20 47 65 63 6B 6F 2F 32    1.8.1.1) Gecko/2
-> 0070   30 30 36 31 32 30 34 20 46 69 72 65 66 6F 78 2F    0061204 Firefox/
-> 0080   32 2E 30 2E 30 2E 31 0D 0A 41 63 63 65 70 74 3A    2.0.0.1..Accept:
-> 0090   20 74 65 78 74 2F 78 6D 6C 2C 61 70 70 6C 69 63     text/xml,applic
-> 00A0   61 74 69 6F 6E 2F 78 6D 6C 2C 61 70 70 6C 69 63    ation/xml,applic
-> 00B0   61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C    ation/xhtml+xml,
-> 00C0   74 65 78 74 2F 68 74 6D 6C 3B 71 3D 30 2E 39 2C    text/html;q=0.9,
-> 00D0   74 65 78 74 2F 70 6C 61 69 6E 3B 71 3D 30 2E 38    text/plain;q=0.8
-> 00E0   2C 69 6D 61 67 65 2F 70 6E 67 2C 2A 2F 2A 3B 71    ,image/png,*/*;q
-> 00F0   3D 30 2E 35 0D 0A 41 63 63 65 70 74 2D 4C 61 6E    =0.5..Accept-Lan
-> 0100   67 75 61 67 65 3A 20 65 6E 2D 75 73 2C 65 6E 3B    guage: en-us,en;
-> 0110   71 3D 30 2E 35 0D 0A 41 63 63 65 70 74 2D 45 6E    q=0.5..Accept-En
-> 0120   63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 64 65 66    coding: gzip,def
-> 0130   6C 61 74 65 0D 0A 41 63 63 65 70 74 2D 43 68 61    late..Accept-Cha
-> 0140   72 73 65 74 3A 20 49 53 4F 2D 38 38 35 39 2D 31    rset: ISO-8859-1
-> 0150   2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A 3B 71    ,utf-8;q=0.7,*;q
-> 0160   3D 30 2E 37 0D 0A 4B 65 65 70 2D 41 6C 69 76 65    =0.7..Keep-Alive
-> 0170   3A 20 33 30 30 0D 0A 43 6F 6E 6E 65 63 74 69 6F    : 300..Connectio
-> 0180   6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A 0D    n: keep-alive...
-> 0190   0A                                                 .

2007-02-18 17:47:18,453 INFO client 192.168.1.12:1722 < - server www.google.com:80 (1357 bytes)
<- 0000   48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D    HTTP/1.1 200 OK.
<- 0010   0A 43 61 63 68 65 2D 43 6F 6E 74 72 6F 6C 3A 20    .Cache-Control:
<- 0020   70 72 69 76 61 74 65 0D 0A 43 6F 6E 74 65 6E 74    private..Content
<- 0030   2D 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C    -Type: text/html
<- 0040   0D 0A 53 65 74 2D 43 6F 6F 6B 69 65 3A 20 50 52    ..Set-Cookie: PR
...

Permalink      Digg this post