Blog

If you have ever stayed at a Hampton Inn, you are probably very familiar with the Internet intercept website they use to ask for the Internet access code.  That intercept page also includes a checkbox asking if you are an advanced VPN user.  I have alternated between checking and not checking this box without any noticeable effects on the performance of the CoNetrix VPNs.  Without doing much research into it, I made the assumption that it was probably opening VPN-related ports.  However, on my last audit, I was working with a virtual system on my laptop that we use often at banks, but I had never needed to turn on at a hotel.  I had some IP address problems with the virtual machine and, during the troubleshooting process, discovered my laptop had been given a public IP address by the hotel’s wireless Internet connection. 

After some tests, I verified that it was a real public IP address that was directly accessible by anyone on the Internet.  A coworker was on the audit with me, so we checked his IP config, but he had a private IP address.  Checking the “advanced VPN user” option on the hotel’s website had assigned me a public IP address, presumably to avoid any NAT issues that might foul up a VPN connection. [more]

The experience was a good reminder to me to make sure my laptop security is up to date whenever I use a public network.  We don’t always know how public connections are configured or who else is connected.  At any hotel, our laptops and network traffic are exposed to any system connected to the hotel’s local LAN.  However, at least in this one case, my laptop was also directly exposed to the entire Internet.  In either case, a strong firewall policy (block all inbound connections, make sure the network connection is designated as “Public” and not “Private” or “Domain”) and a fully patched system are very important.


 

Upon rebooting a Terminal Server that had resource issues, we could not log back into the server through RDP.  We could log in through iLO, and it was apparent that the logins were working but they were very slow.  Upon examining the services, we could see that the IPSEC service was not started. 

Trying to manually start the service gave the following popup: "Could not start the IPSEC Services service on Local Computer.  Error 2: The system cannot find the file specified."  The event logs also showed that TCP/IP was in blocking mode. 

Disabling the service and rebooting restored all network communication, but trying to start the service would drop all connectivity again and slow down the server.  I found another article that said that IPSEC may need to be rebuilt.  When I looked for the registry keys for IPSEC, they were not there.  After I ran the following commands, the registry keys were populated, and IPSEC was able to run properly.

To rebuild IPSEC, follow these steps: [more]

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\IPsec\Policy\Local.  (In my case, the server’s registry ended before IPsec.  If this is the case, skip to step 6.)
  3. On the Edit menu, click Delete.
  4. Click Yes to confirm that you want to delete the subkey
  5. Quit Registry Editor
  6. Click Start, click Run, type regsvr32 polstore.dll, and then click OK.

 

A Windows 7 user was unable to connect to or display network documents and was notified the system could not load the user profile. The problem appeared to be caused by a corrupt profile. I logged the user off and then logged in as the administrator and removed her profile. Then tried logging in as the user to reload the profile. It still could not load the user’s profile. I decided to rebuild the profile but when I attempted to it failed again.  I placed the backed up profile back and tried another system and the profile worked. 

After some research I found this issue may occur if the user profile was manually deleted by using the command prompt or by using Windows Explorer. A profile that is manually deleted does not remove the security identifier (SID) from the profile list in the registry. If the SID is present, Windows will try to load the profile by using the “ProfileImagePath” that points to a nonexistent path. Therefore, the profile cannot be loaded. The profile had not been manually deleted but I decided to check anyway. I opened the registry editor and navigated to ”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList” and found a SID for the user. I deleted it from the registry and then logged in as the user and the profile loaded fine.


 

When we audit a bank, we talk with them about their smartphone controls - including asking about the use of remote wipe.  Recently, I was thinking about the problem of when to decide that your phone is really lost or stolen and take the remote wipe plunge.   You always think you might find the phone any minute now...

I've looked at Apple's Mobile Me service that offers a "Find My iPhone" service.  Their service works well and offers a nice feature of being able to have the phone ring loudly even if you have the ringer turned off.  However, since I didn't need the Mobile Me e-mail, contact, calendar syncing, the $99/year subscription fee seemed awfully steep for a location service.

I found a FoneHome app on the Apple app store that is an alternative to the $99/year subscription to Mobile Me if all you want is a way to track your lost phone. [more]

It's $1.99 on the store and allows you to track the phone (or phones) as long as it's online and GPS is turned on.  It'll run in the background on a 3GS or 4 with iOS 4.

The app sends an update to the FoneHome website (via SSL) periodically, more frequently when you're on the move.  You can log onto the website and see the last location it received as well as a history of locations reported.  I suppose this could act as a poor man's teenager tracker as long as the kids don't uninstall the app or turn off their GPS…

The website is www.myfonehome.com.  Once you setup an account (free), you can tie it to multiple iPhones.


 

Recently a user at a customers site was having trouble sending email.  I ran a script that connected to each mail server and specified the sender and recipient to see if any would get errors.  One refused to accept the email because the reverse DNS lookup on the source IP failed.  So the lesson to learn here is this.  If something does not work, try to figure out where it is broken and try to see exactly what is going on in that part that is broken.  But wait - that's not the end of the story because the user was sending email to 27 recipients and none of the messages were being delivered.

Mr. Peabody, set the WABAC machine to February 2004.  Microsoft has just published a paper "The Coordinated Spam Reduction Initiative". [more]

http://old.openspf.org/caller-id/csri.pdf

Section 11 is about Computational Puzzles For Spam Deterrence.  The idea is to have the computer sending email solve a puzzle that require a lot of resources, usually CPU time, but verifying that solution is fast.  The idea was to make it expensive for spammers to send out spam.  I know this sounds silly now with botnets having 1000s of machines sending spam.  But did you know Microsoft actually implemented this in Outlook 2003?  And did you know it is still in Outlook 2007?  And did you know it is still in Outlook 2010?  It's called postmarking now, but it is still the same computational puzzle.  This is only used when it thinks your email might look like spam.

Ok, so the way this works is that Outlook or your Exchange server generates the puzzle solution and adds it to the email headers.  It uses the header "x-cr-hashedpuzzle".  RFC 2821 (Simple Mail Transfer Protocol) states "The maximum total length of a text line including the <CRLF> is 1000 characters".  This x-cr-hashedpuzzle is quite long, so it is broken up into several lines.  The first line is 1000 characters, but the continuation lines have a <tab> inserted at the front, causing them to be 1001 characters long.  If this happens to be going through an ASA with ESMTP inspection enabled, it will send out resets to close the connection because it violates the RFC.

This is why the user I was working with could not send email to a list of 27 recipients. I removed the SMTP inspection on our ASA (which I have been wanting to do anyway) to work around this.


 

I have been looking for a multi-purpose network monitoring tool for use at several network customer location and came across a light-weight app called SpiceWorks. Its open source and has a number of nice features. Here is a list of some of the most useful ones

  • Schedulable network scans based on domain name or subnet
  • Asset classification based on collected data
  • Software inventory (including MS patches)
  • Basic service/system alerts & monitoring
  • User knowledge base portal w/integrated ticketing system
  • Warranty lookup for monitored assets
  • Antivirus tracking (no AV, outdated defs, versions, etc) for a number of popular packages

 

After converting a site to a new MPLS provider I began to experience about 20% packet loss to that site.  There were a lot of things that changed during the migration:

  • Added GRE Tunnels
  • Implemented EIGRP to handle routing all of the LAN subnets
  • Restricted BGP to only handle the WAN, or MPLS, interfaces

These are the troubleshooting steps I took to narrow down the problem:

  1. Ping from the tunnel interface at the main site to the tunnel interface at the branch site.  0% Packet Loss
  2. Ping from the LAN port on router at the main site to the tunnel interface at the branch site. 0% Packet Loss
  3. Ping from the LAN port on router at the main site to the LAN port at the branch site. 0% Packet Loss
  4. Ping from a client at the main site to the tunnel interface at the branch site. 0% Packet Loss
  5. Ping from a client at the main site to a client at the branch site. ~20% Packet Loss
  6. Ping from the LAN port on router at the main site to a client at the branch site. ~20% Packet Loss
  7. Ping from the tunnel interface at the main site to a client at the branch site. ~20% Packet Loss

This process seemingly narrowed it down to the problem originating at the branch site.  I checked for negotiation errors in the logs of the switch and the routers.  BGP appeared to be working fine because the peer was up and I was receiving all the routes that I expected.  The ping loss seemed to be very random.  I then decided to enable debugging on the router and start a continuous ping from a client at the main site to a client at the branch site.  I quickly noticed that every time I saw packet loss, I also so a BGP error message being logged.  There were a few different error messages that were being populated and each caused different amounts of ping loss. 

Apparently, the ping loss wasn’t as random as I thought!  After speaking with a coworker about the BGP turn up he was currently doing with another customer, he suggested that I needed to add a static route to the branch router for the BGP peer.  Everything began working!  So, to make a long story short, it is best to have a specific static route added for a BGP peer if that peer isn’t directly connected. Even if that static route has the same next-hop as the default route.


 

If you have any programs that use Outlook to script objects in Exchange, you need to  be aware that the folder name for root public folder changed with Outlook 2010.  In previous versions of Outlook the root public folder is named “\Public Folders”.  Starting with Outlook 2010 the root public folder is named “\Public Folders – [email protected]” where [email protected] is the connected user’s primary email address.  Fortunately you can use the GetDefaultFolder() method on the Outlook NameSpace object to get common folders without hard coding the name of it.  For example you could call GetDefaultFolder(olPublicFoldersAllPublicFolders) to get the "All Public Folders" folder in the Exchange Public Folders store if you're using Exchange.


 

I was attempting to install SEP on a server that was local to me, but remote to the SEP manager. The problem here is that the SEP manager generates a 90 MB package before pushing it out to the machine and starting the install. This would’ve taken a good bit of time to copy over the VPN to the server here so I decided to take a different approach. I had the installation media for an unmanaged copy of SEP that I installed on the server. From there, I opened the SEP manager, went to clients, and exported the communications settings into a file I named “sylink.xml”. Then I copied the sylink.xml file to the server here and opened the SEP client. Inside Help & Support, click Troubleshooting, and then import communication settings. This tells the client where to look for management. After waiting for a minute or two, I went back into Troubleshooting and saw that the client was looking in the correct location for the server policies.


 

Windows 2008 and IIS 7.0 installs with Secure Sockets Layer (SSL) version 2 and “weak” cryptography ciphers turned on by default.  Having that turned on will likely turn up some problems in a penetration test.  Here are some common vulnerabilities names that might be identified in your penetration test results:

  • SSL Server Supports Weak Encryption
  • SSL Server Allows Cleartext Encryption
  • SSL Server May Be Forced to Use Weak Encryption
  • SSL Server Allows Anonymous Authentication [more]

Disabling 

Unfortunately, there is not currently an intuitive way to enable/disable the protocols and ciphers built into the Windows GUI.  You must edit your systems registry to get the job done.  Some of the registry keys and DWORDs will likely not be in the registry, so you will need to add them. It’s always a good idea to back up your registry before making changes just in case something goes wrong.  Click Start, click Run, Type regedit32 or type regedit, click OK, and then add/modify the keys listed below.

Here are the registry keys to turn off PCT 1.0 and SSL 2.0 and leave SSL 3.0 and TLS 1.0 turned on:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server
    • DWORD = 1
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
    • DWORD = 1

Here are the keys to turn off “weak” SSL ciphers:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128
    • DWORD = 0
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128
    • DWORD = 0

Testing

The easiest way I’ve found to verify the protocols and ciphers are turned off is to use the free OpenSSL toolkit.  Here are some instructions for installing Cygwin with OpenSSL on Windows 7: https://www.conetrix.com/Blog/post/How-to-Install-OpenSSL-on-Windows-7.aspx.  Here are some instructions for installing OpenSSL on Ubuntu: https://help.ubuntu.com/community/OpenSSL#Practical OpenSSL Usage.  If you are using a Mac OpenSSL should already be installed.  Once you get it installed you can verify your registry changes worked.

Once you get it installed here is the commands you can use to verify that SSLv2 is turned off:

# openssl s_client –ssl2 –connect YOURSERVERNAME:443

If server does not support SSLv2 then you should see an error like the following two examples:

CONNECTED<00000003>
Write:errno=113

Or

CONNECTED<00000003>
1324:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

Here is the command to test for weak ciphers:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers then an error will be displayed similar to the error examples given above.