Read Drazen’s post now.

Lets start with analysts/engineers/first-line-responders, the guys in the trenches who turn the gears and make sure our security technology is working and monitored. Depending on the business environment this is perhaps one of those roles that can’t easily be sliced down to 4 days. The conflict here is if your business requires 24/7 monitoring, or at least 24/7 on-call, either way you can’t easily make people redundant (how will you cover all your hours?) or ask people to work 4 days (to cover your time you will require more staff - which negates the 4 day working day). The risks here are if your monitoring area misses incidents or make mistakes managing your security infrastructure because of time constraints.

What if you employ security auditors or security testers? These types of roles, similar to security architects & designers, will often see their workload ebb and flow depending on the number of projects. If the current GFC hasn’t impacted upon your project portfolio then your testers would probably still be required full-time, but whether or not they’re required for a full 5 days would entirely depend on how many projects there are, and the degree of detail that is required for each project. The issue here is that with your testers only working 4 days, then either the time dedicated to testing or the time they can focus on keeping abreast of testing techniques, may be impacted. This is of course taking into account that you employ these resources, as opposed to using consultants. These types of roles could probably pull back to four days without too much detriment, and knowing the types of people who perform these roles it’s not like they would simply fill their 5th day with veging out, they’d still be monitoring their feed readers and working on tools or other security related projects. The risk with your testers either not keeping on top of trends in the industry, or not focusing enough time on testing your systems is that vulnerabilities may make their way into production.

Employees involved with security architecture and design fall into the same area as your security testers. Depending on the project load, these roles could potentially work only 4 days, but would have to monitor their time spent on enhancing their knowledge and not falling behind the game. Similar with the testers, the risk of not having enough time for your designers is that perhaps systems are designed to a lesser degree of quality, or perhaps they will take longer to complete.

Your information risk specialists or analysts, perhaps not technical resources but sitting within a consulting or shared-service type of area, will potentially have a difficult time pulling back to four days. Core responsibilities here are advising the business of business and technical risks in the context of business-as-usual activities or changes and projects. Whilst the potentially dwindling number of projects may indicate that these roles can easily go to four days, with business trying to do the same amount of work as before, but with less time, they may have a tendency to look at riskier solutions. If this is the case, now is possibly the time for your risk specialists to refocus their efforts to ensure that risks are being considered and reviewed appropriately. The risk here of course is that activities get performed without the appropriate rigour being applied and “slip past the keeper” into production.

If your environment is fortunate to have dedicated security policy roles it would be fairly safe to say that the impact to the organisation wouldn’t be too great if they were asked to work 4 days. This is taking into consideration that the primary responsibilities include the maintenance and reviewing of policies and standard documentation. Depending on the size of your policy/standard set, the risk in reducing time in this area may lead to some of your documentation falling behind.

Security managers fall into a 50/50 bucket, depending entirely on the amount of people management they are currently doing, and how much time they work looking at the strategy of the security organisation (or if they leave that to the architects?). If your security managers’ core responsibilities include just these two activities, then perhaps shifting to a four day week wouldn’t be too difficult. I’ve seen in a number of situations consultants acting as security managers at multiple locations. One of the key risks I see here is the impact of security management decisions not happening as fast as they should. Of course there are ways to deal with this situation.

Are any of you security professionals currently working four days? I would like to hear your feedback!

• The guest Windows XP machine must be able to resolve DNS names
• The guest Windows XP machine must NOT be able to access the local network (except for accessing the local DNS server)
• The guest Windows XP machine must be able to access the Internet using HTTP or HTTPS
• The guest Windows XP machine must be able to SSH to the host Ubuntu machine (to copy files if required)

As mentioned by Lonnie, the best way to do this is to configure the VM to use “Host Only” networking, then utilise the masquerading and other firewalling options of iptables on the Host Ubuntu system. This allows the Ubuntu system to limit, at the network layer, what the VM can access. My setup has the Ubuntu machine connecting to the network via wireless networking, the guest configured for “Host Only”, which uses the virtual interface vmnet1, and visually looks like this:

First up is configuring iptables. I’ve created a file called firewall and placed it in my /etc/init.d/ folder. The file has the following in it:

#!/bin/bash -e

The script is a bash script, not much to explain here.

echo 1 > /proc/sys/net/ipv4/ip_forward

Enable IP forwarding in the linux kernel - otherwise the IP traffic wouldn’t be routed through the Host Ubuntu system.

iptables -t nat -F POSTROUTING
iptables -F FORWARD

Flush the tables before we set them up.

iptables -t nat -A POSTROUTING -s 172.16.72.0/24 -o wlan0 -j MASQUERADE

Enable routing out the wireless interface where the traffic comes from the “Host Only” virtual nat interface’s subnet.

Next we start the firewalling:

iptables -A FORWARD -i vmnet1 -p UDP –dport 53 -j ACCEPT

1. Allow DNS from the virtual nat interface. (requirement #1)

iptables -A FORWARD -i vmnet1 -d 192.168.0.0/24 -j DROP

2. Disallow traffic to enter the wireless network. (requirement #2)

iptables -A FORWARD -i vmnet1 -p TCP –dport 80 -j ACCEPT

3. Allow HTTP traffic out. (requirement #3)

iptables -A FORWARD -i vmnet1 -p TCP –dport 443 -j ACCEPT

4. Allow HTTPS traffic out. (requirement #3)

itpables -A FORWARD -i vmnet1 -j DROP

5. Drop everything else.

And that’s it (download the file from here). Don’t forget to add a symlink to this file in your boot up scripts, because the Linux iptables rules do not return to their previous state after you reboot:

$ sudo ln -sf /etc/init.d/firewall /etc/rc2.d/S89firewall

This puts the bash script into your default runlevel (2) and runs it after all the interfaces should be up.

Due to the way in which the forwarding works, the above rules will not prevent the Windows XP VM from SSHing to the Host Ubuntu box (requirement #4). But before we start up the VM, we have to configure the DHCP daemon settings for that “Host Only” virtual nat interface, vmnet1. The file we want to modify is /etc/vmware/vmnet1/dhcpd/dhcpd.conf, which I believe by default is read only, so the first thing I had to do was make it writeable with a:

$ sudo chmod o+w /etc/vmware/vmnet1/dhcpd/dhcpd.conf

The only changes I made to this file were the addition or modification of the following lines in the subnet 172.16.72.0 netmask 255.255.255.0 block:

option domain-name-servers 192.168.0.254
option routers 172.16.72.1

This explicitly sets the DNS settings to the ADSL Router/DNS Server - as my Host Ubuntu server does not provide DNS resolution, and the second option sets up the gateway setting so the Windows XP VM will route traffic towards the Host Ubuntu server.

Next we adjust the Windows XP VM so it’s using “Host Only” networking and boot it up and voila. Your Windows XP VM should boot up and acquire its network settings from the vmnet1 DHCP daemon settings, it should be able to resolve internet hostnames and should be able to access Internet sites over HTTP and HTTPS but that’s it. If it tries to connect to any of the PCs on your wireless network it shouldn’t be able to.

(In the nature of always wanting to find better ways to do things, if anyone has any suggestions for how this could be done better, because I’m sure it could be, please leave me a comment!)

Opera Mini is a compact web browser released by Opera Software that is designed for mobile devices, in particular, mobile phones. One of the primary features of the browser is its incredible speed. Opera boast more than 30% speed improvements for users in the US. But how exactly is a web browser able to boast such an incredible speed enhancement? Flux capacitor? FTL drive? No. Opera Mini is able to improve the speed of accessing websites by pulling them to their servers first, that then compress the content, before sending the content onto your phone (see press release). This provides a few benefits:

1. Your browsing is faster over your traditionally slow mobile phone Internet connection
2. Your browsing is potentially cheaper, because instead of having to download a page that is 200KB in size, perhaps it’s only 100KB

Another “feature” of Opera Mini, in the never-ending quest to provide an awesome browsing experience on a mobile phone, is that their servers will keep track of your cookies set by websites. This is so that if you visit a site that uses cookies, the Opera Mini server will submit it again for you (see Privacy under the faq).

So does using this browser introduce any security or privacy risks to the user? I believe the simple answer is “yes”. Trying to expand on this to understand the potential impacts and likelihoods of these impacts is a little more complicated, and whilst I was going to take a FAIR approach to this, I don’t know enough of the internal controls to do it justice.

First of all what am I worried about, what assets are at risk? We all understand that your cookies, either in their short active lifetime or perhaps even beyond, hold some value to us users and generally we don’t want to share them with other people - so for this exercise I’m going to focus on cookies as the primary asset. Why is this? Primarily because cookies are often used as the mechanism to help provide state on an otherwise stateless protocol (thanks a lot HTTP). What this means is that, when you’re visiting facebook.com or yourbank.com, when you keep on hitting new pages the only way those web servers know who you are is because your requests often include a “session” identifier. Some web apps put that in the URL, but most will track your state through your cookies. I’m not going to put an actual dollar figure on what it would cost a user if those cookies are disclosed to a malicious, unauthorised third party, but let’s say it’s somewhere between all the personal information you store in your facebook profile and perhaps 10% of the money you have in your bank account. (this of course is entirely subjective - you may only ever use your Opera Mini browser to visit youtube.com?)

There are a handful of scenarios that may occur in which your cookies may be disclosed. Someone could compromise one of the multiple Opera Mini servers and milk them of their juicy, cookie information. Perhaps there’s a fault with the software running on those servers and Opera Mini users accidentally start seeing cookies from other users. Or perhaps an administrator of one of those servers has a bad day and decides to have a peek in their systems. To my knowledge (which I’m going to admit isn’t all that deep) none of these have occurred.

So what are Opera doing to prevent these sorts of issues? Well publicly they talk about encryption, and lots of it. According to the faq the current version of the software will always encrypt data sent between their servers and your browser. This is actually a step above normal browsing, which would only encrypt traffic if the website is configured to use SSL/TLS (HTTPS). Of course, they also put in their faq:
Can Opera Software see my passwords and credit card numbers in clear text? What is the encryption good for then?
The encryption is introduced to protect the communication from any third party between the client (the browser on your handset) and the Opera Mini transcoder server. If you do not trust Opera Software, make sure you do not use our application to enter any kind of sensitive information.
The last statement certainly got me worried. They aren’t making any assurances on ensuring that your data is protected, even whilst being processed or stored on their infrastructure.

So what can you do? Well, I believe there is a balance between the benefits and potential negative impacting risks of this kind of service. Sure, if you’re only using Opera Mini to search Google and look up the weather then perhaps the browser is fine and doesn’t pose any risk to you. If on the other hand you want to ensure that no third party has access to cookies which are used to maintain your state with yourbank.com then maybe you use a different browser for those situations. The decision is mostly personal. For example, regardless of how much I enjoy browsing with Chrome, I still find myself only ever performing online banking with Firefox+NoScript, and often clearing out all settings after I’m done.

This week is National Zombie Awareness Week. Spread the word!

www.zombieweek.com

(Thanks @security4all)

Christian and I were recently asked to perform an application security assessment on a .NET smart-client / web services application (What is a smart-client you ask? -c). This required a bit of hackery with certificates to get the traffic flowing through Burp. We figured this would be worth sharing, if only to save others a bit of time in future. So, I get to be guest blogger for the day.

The smart client was hardcoded with the address of the web services providers. Initially it seemed that this might require the intercepting proxy to run as a reverse (or transparent) proxy but it turned out that the app honoured IE proxy settings, so this was not necessary.

Next, we found that the client was failing to validate the SSL certificate provided by Burp, and there was no option to ignore the cert error and continue. To get around this, we generated a self-signed certificate for the correct server name, then this cert was loaded into Burp and imported into the certificate store on the client.

The Short Way

To generate the self-signed cert…

openssl genrsa 4096 > server.key
openssl req -new -x509 -nodes -sha1 -days 1000 -key server.key > server.crt
(Common Name = FQDN for the SSL server)
openssl pkcs12 -export -out server.p12 -in server.crt -inkey server.key

To load the cert into Burp…

Choose "Proxy" tab.
Choose "Options" tab.
Select the active listener.
Click "edit" button.
Tick "use a custom server SSL certificate".
Specify path to server.p12 and password.
Click "update" button.

To load the cert into the client’s trusted store…

Copy either server.crt or server.p12 to the client machine.
Right-click, “Install Certificate”.
“Place all certificates in the following store” / “Trusted Root Certificate Authorities”

Restarting the smart client, it connected through Burp to the web services provider with no further problems.

A Slightly Longer Way

The above was sufficient for our purposes, but what if the smart client was using web services from a number of providers, all requiring SSL? So long as all the WS providers could be wildcarded to the same domain name, the above methodology can still be used with a couple of tweaks.

Or, what if you frequently needed to change the cert presented by Burp, but didn’t want the hassle of having to load a new certificate into the client machine each time.

First, generate a self-signed CA certificate…

openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 1000 -key ca.key -out ca.crt
(Make the CN whatever you like… ‘App Testing CA’)

Import the CA cert into the client machine as before. You shouldn’t need to repeat this step ever again; any certs subsequently signed by your CA cert will validate.

Then, generate the wildcard server cert, signed by your (self-signed) CA cert…

openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
(Make the CN something like… ‘*.yourdomain.com’)
openssl x509 -req -days 1000 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
openssl pkcs12 -export -out server.p12 -in server.crt -inkey server.key

Finally, load the server.p12 file into Burp like before.

Notes, restrictions, the potential for mischief…

This all got me thinking that it might be nice to build a wildcard cert for something like “CN = *” that would be valid for any SSL site I might visit through Burp. This would save some time wading through pages of validation errors when testing browser-based apps. It would also present some interesting possibilities if one could, say, surreptitiously load a cert into the trusted store on a client then transparently proxy their web traffic…

Unfortunately (or fortunately), it turns out that this is not possible. Wildcard certs are only good for one level of wildcard. *.yourdomain.com is good for aaa.yourdomain.com and bbb.yourdomain.com, but not for some.thing.yourdomain.com. In the same way, a cert for “*” would presumably be good for “com” or “au”, but not mail.google.com or www.ebay.com. Foiled by the ITU-T. :-)

Which is roughly how this new mechanism works to provide a second factor of authentication using an out of band mechanism. After submitting a payment, a “Cronto Visual Cryptogram” (a picture) is displayed which has to be decrypted by your mobile phone (or other device) providing you with a code you then have to enter into your payment page.

Similar to SMS 2FA (or at least well implemented SMS 2FA), the “cryptogram” can include other textual information such as payment details. This should hopefully prevent fraudulent transactions from being “authorised” via the channel, such as those generated by a “man-in-the-browser” trojan.

Whilst I haven’t really had time to process the benefits and disadvantages (mobile phone compatibility?) of this mechanism I’m quite happy to hear that innovate research is still being done in this space. Interesting…

(Thank you SBN feed for bringing this article to my attention!)

Alan has more information here.

A couple of the tell tale signs I’ve noticed over the past year or so is things like their inability to recreate a HTML button which uses CSS to use a custom image. For example, where the HTML is similar to:

<input type="image" class="loginbutton" src="blank.gif" style="height:30px;width:80px;" />

And the CSS is similar to:

.loginbutton {background-image: url(actualbutton.jpg); background-repeat:no-repeat;}

Because this prevents the user from right clicking the button and choosing “Save Image As..”, you’ll find that instead of going through the CSS to find where the ACTUAL button image is (actualbutton.jpg) they’ll take a screenshot of the page and recreate the image from there.

Another sign is the “Mark of the Web” (MotW). The MotW was created back in the days of IE 4.0 as a mechanism for a HTML page to run in a different security zone then what it actually is. For example, if you want to test a HTML page locally, but make sure it runs in the Internet zone you can set the MotW within the HTML page to “about:internet“. An example MotW is:

<!-- saved from url=(0022)http://www.google.com/ -->

The #### between the brackets indicates the length of the following URL.

Now you might be wondering whether or not this allows a page out there on the Internet to run in the “Local” security zone in IE, the MotW is configured such that it will only run the HTML in the prescribed MotW zone if it is more restrictive than the “Local” security zone.

So what’s this got to do with phishing? Well, when you save a page in IE, it inserts the MotW into the saved HTML as the URL of the site. So for example, if the login page the phishers want to impersonate is http://www.twitter.com, then the saved HTML would include

<!-- saved from url=(0023)http://www.twitter.com/ -->

Of course, when they setup their phishing site the URL won’t be that, it’ll be something like http://i.hacked.some.joomla.server.com/images/twitterphish/index.html. Naturally this URL does not match what is specified in the MotW within phished content at index.html.

Surely you’d think that the guys setting up these phishing kits would look at the HTML and remove these sorts of things? Sometimes yes, but sometimes no. Often the only thing they have to change is where the login form POSTs to. So instead of POSTing to itself, they’ll then change their phishing content to post to some mailer script at “mailer.php” or whatever.

As far as I know, none of the browsers look at the MotW for anything, except IE which looks at it for security zones. I’m unsure if any of the Google or Yahoo bars review the MotW for any discrepancies. Whilst not entirely accurate, and likely to lead to some false positives I thought it was worthwhile to look at anyway. This is where “Mark of the Phish” (MotP) was born from.

MotP is a Greasemonkey script (that means Firefox only folks!) that looks at the MotW tag within HTML documents, and if it does NOT match the current URL pops up an alert asking if you want to continue. This is primarily a proof of concept to determine if this type of early detection would work at all in the real world. It’s difficult for me (or even perhaps anyone who reads this?) to tell, because as professional security folks we’re tuned to detect a dodgy site, regardless of what’s included within the HTML, MotW or not.

In an ideal world this functionality could be built into anti-phishing toolbars, or perhaps into the browser itself. I’m also aware that this is only a temporary detection, you would assume that Darwin’s theory of natural selection would eventually weed out all the phishers creating useless phishing kits, and slowly but surely the guys making the effective kits would get better at reviewing their HTML before rolling it out. Until that point though, perhaps every little bit helps. Tell me what you think.

The other thing that I’ve been finding myself use more and more each day is Twitter. I’ve been using the service since April last year and I still find myself using it. I’m limited in my use of the service during working hours, but I still find it a valuable tool to get a quick “feel” of the security industry and also it’s great at asking short questions to a very wide audience. You can twit me at @xntrik.

What’s coming up for Christian?
I’m organising a presentation for Perth’s AISA slash OWASP on security in the SDLC focusing on threat modelling. I’m hoping to provide an overview of a few methodologies being advertised by the industry for securing the SDLC, including MS’ SDL and OWASP’s own CLASP. The threat modelling section will probably focus on a more interactive session with the audience walking through a simple threat model scenario. The target audience I’m hoping for is developers, of course the room will probably be majority security folks. Ah well, hopefully they’ll be able to take the message back to their developers.

..hopefully.