So while struggling to write my latest paper on mobile communication technology and the associated vulnerabilities found at the various layers of the network stack, I found this odd little graphic and thought: gee, this really sums up how I feel right now…

Of course it doesn’t make writing about 3G network implementation mistakes (Man-in-the-middle attacks on UMTS) any easier, but it did waste some time.

2009/06/05: Update: Ok, so the paper has been submitted. Now I’m a bit humbled, as I thought 3G mobile network connections were somehow sacred .. and somewhat ’safe’ from hacking efforts. Alas, what a foolish concept. 3G (or UMTS) is no more immune to hacking than any other network technology that we currently use. UMTS is apparently vulnerable to (trivial?) man-in-the-middle attacks due to the carrier implementation of our shiny new 3G networks. Of course pure UMTS (3G) data networks would be best, however there is this entire encompassing 2G GSM network that includes base stations and controller infrastructure. Our friends K. Kotapati and associates outline some serious issues in A Taxonomy of Cyber Attacks on 3G Networks.  Unfortunately telecom carriers are not going to replace all the 2G infrastructure until absolutely necessary - this opens the vulnerability of 3G equipment (like our new iPhone 3G’s) as they roam onto 2G GSM networks until it has been replaced by all 3G UMTS (or various CDMA varients). Basically 2G base stations are not expected to protect the integrity of signaling messages and are subject to spoofing and manipulation by malicious parties. So someone can impersonate a 2G base station and force your shiny new 3G handset to operate in clear-text .. enabling subscriber information theft and eavesdropping on any non-SSL protected transactions. Hmm. Holy cr@p. Considering a friend of mine has demonstrated this in Calgary in January 2009, this is a bit too close to home for comfort. So if your phone indicates it’s on the EDGE network (E) vs (3G) .. I’d think about turning the power off or at least enclosing your precious iPhone (or Storm) in tin foil .. until you can get back on a 3G network segment.
Wow. So much for the new mcommerce, eh?

One can now inexpensively build a fault tolerant firewall cluster that removes any single point of failure in the security policy enforcement points at your security zone boundaries. Synchronous firewall state table updates and an open source version of virtual router redundancy protocol (CARP) gives the ability to seamlessly insert or remove firewalls from a cluster. No more patching firewalls at 2am hoping for the best (or not patching because it’s too hard).

PDF

So setting up my shiny new iPhone 3G for IMAPS email was not entirely straight forward.  (-:  There are two complicating factors that I ran into.  For IMAP over SSL (IMAPS) connections to a mail server that is using a digital certificate that is signed by a well known certificate authority AND running on the default TCP port 993, no problems.  You may have a be a bit patient as the mail app on the iPhone accepts the certificate.  For less standard mail server implementations, read on …

I am using a server certificate that is in essence a self-signed certificate - it is signed by CAcert.org, however very few (if any) browsers and mobile devices trust or even know of CAcert.org.  In this case, you will need to be patient while the iPhone mail app finally rejects the server certificate as untrusted.  The dialogue box will acknowledge the mail server certificate is invalid and will ask if you want to continue.  Accept the continue option and eventually (took about 5 minutes for my iPhone) the iPhone will accept the ‘invalid’ certificate.

Now, if you are using a mail server that has IMAPS running on a non-standard port (anything other than TCP 993), you must first establish the connection and have the iPhone accept the certificate over port 993.  Once the mail account is setup initially, then you can go change the port to something non-standard.

Once I get a chance I’ll post some screen shots.

Running day-to-day with a Windows account that has Administrator privileges is a recipe for disaster.  Casual browsing of a website that is infected or inadvertent opening of infected attachments can result in an infection through the user’s Administrator privileges.  Something like 92% of Microsoft critical vulnerabilities announced in 2008 could have been mitigated by operating day-to-day as a normal user.  Splitting your accounts into a normal account and admin account is a good idea, but it can lead to some headaches when the normal user needs to run temporarily as Administrator.

Fortunately there are some work arounds that can be used to temporarily elevate the user’s privileges to Administrator.  Most of these involve the RUNAS command:

File explorer
If you’re running IE7 under WinXP, in order to run Windows Explorer with the runas command, it must be run as a separate process. A quick way to do this, without having to change your Folder Options settings, would be to run an instance of Explorer with the undocumented parameter /separate, like this:

runas /user:domain\username "explorer /separate"

Command Line Prompt
You can add a shortcut on the task bar with the following syntax to get an Administrator cmd prompt:

%windir%\system32\runas.exe /user:yourdomain\a-someuser cmd

yourdomain is the name of your AD domain if you have one, if not, leave it out.  a-someuser is a suggested naming convention for the Administrator account associated with the user named someuser.

Well, been working way too hard, so here’s a bit of a humour break.  The graph below shows the results of a user poll “What super-power do you wish you had”…

Thanks to Adam B for the tip!