I Can Like to Hack

Posted: 13 August 2014 in Uncategorized

Hi DanHi Dan!
In the last few days a new article was posted to Ars Technica [1], allegedly detailing the approach taken by the hacker behind the Gamma Group International data leak. Now, before I go any further, I need to point out that all the normal disclaimers apply: things you read on the Internet may be closer than they appear.

The article itself is interesting, but what is more so is the link it provides to the hacker’s methodology [2]. Anyone reading the hacker’s document, who has any vague knowledge of the Internet and security, should be impressed with the meticulous approach taken by the attacker.  But more than this, it is painfully clear that there is No Magic Sauce ™. The methodology uses off-the-shelf tools, simple scripts, and a manual analysis approach to match them against the target environment.

This simply underlines the fact that acceptable security, for the most part, is all about getting the basics right consistently.

How could Gamma Group International have avoided ending up in this situation?

  • Understand the threat surface well
  • Remove any unused functionality
  • Configure the remaining functionality conservatively
  • Patch any flaws promptly


Now, being truly honest, how many of you can put your hand on your heart and say that you do this thoroughly and consistently?

[1] http://ars.to/1q1CxIA
[2] http://pastebin.com/raw.php?i=cRYvK4jb


Written by
Martin-frameMartin O’Neal
Managing Director

Android Wildwest

Posted: 5 August 2014 in Uncategorized

Trojan software has been around for a long time but its effectiveness in targeting individuals and businesses has increased in parallel with the ever-improving usability of Internet connected devices. The smartphone and tablet era has brought millions of new users onto the Internet.Android_robot

Unfortunately, Internet use does not require a “driving license” and at the moment we are looking at an increasingly diverse horde of unlicensed, sometimes drunk, drivers who are being conned into lemming-like self-destruction.

It shouldn’t come as a big surprise that Norton last week reported a “Fake ID” vulnerability, distributed by Trojan apps, which could allow malicious apps to access legitimate applications and steal sensitive data such as passwords or financial information by falsifying built-in security certificates. The vulnerability could reportedly affect millions of users as the threat spans across Android version 2.1 up to 4.4.

The potential reach of the vulnerability is indeed a prospect but one which astute businesses and security teams should be well prepared for. If, however, you are feeling a little lost, here are a few tips to tackle the threat:

For the lemmings: Buy an iPhone and/or never install anything on your Android. Anti-virus would be a classic recommendation but even some of those are Trojanned, so you are best staying away unless you know what you are doing or can call upon someone who does.

For the businesses: Approach “Bring Your Own Device” schemes with great care. Consider introducing Mobile Device Management software to lockdown BYOD and internal devices. The details of what to lockdown are beyond the scope of this ranty little blog but at the very minimum look to: restrict installation of software; control carefully what data is accessible from Mobile devices; ensure you have corporate level anti-virus software installed; and use a principle of least privilege wherever possible.


Written by
Jan-FrameJan Fry
Security Consultant


Au revoir to Piracy?

Posted: 31 July 2014 in Uncategorized

NIGHT OF THE LIVING DEAD, 1968 Earlier this year the City of London Police and the Intellectual Property Office (IPO) established the Police Intellectual Property Crime Unit (PIPCU), which is a cool-sounding acronym, right?

The PIPCU will be working with HMRC, UK Border Agencies, Trading Standards, Europol and NCA to develop strategies to help prevent IP crime (both counterfeits and piracy) affecting physical and digital goods (with the exception of pharmaceutical).  As well as this, they will be informing and educating businesses and users about criminal activity on counterfeit and piracy sites.

Currently PIPCU have funding of £2.56 million pounds, and with this, they plan to police the Internet and respond to threats of online intellectual property crime.

One focus will be on copyright infringement by illegal sites, such as Pirate Bay. When someone visits a site that a complaint has been registered against, the PIPCU will dynamically replace any banner adverts on the site with the PIPCU’s very own anti-piracy equivalents.  As the revenue from this kind of advertising is one of the main reasons the pirate sites exist at all, this should hit the criminals right where it hurts the most: in their wallet.

So what does this mean for the public and for businesses? Well for businesses, it’s good both for advertisers that don’t want to be associated with pirate sites and also for companies who want to stop their IP being used illegally. However, for the public it may end up being a different story. The reality is that in the short-term, things are not going to change all that much; the pirate sites and their content will still be available, just with no advertising. However, in the long-term, if the pirates can no longer make any money from these sites, then the chances are that they will close them down and move on to easier pickings  – which may mark the beginning of the end of the illegal free-stuff Internet movement…

Written by
Gary Frame Gary Carvey
Business Consultant


Zombies_NightoftheLivingDeadSecurity consultants can tend to live a bit like nomads: wandering from office to office, plying their trade along the way. We get to see lots of different organisations, and a surprising variety of datacentres. Mostly these are full of shiny racks of new equipment, but every now-and-then we’ll see something out of the ordinary. Some form of legacy system: mysterious, ancient boxes, left to their own affairs in the darkest corner of the room.

Of course, whilst these systems are simply interesting museum-pieces to us, to the poor soul who is tasked with owning the risk, they are something much more ominous. Legacy systems that dramatically outlive their intended lifespan tend to do so for one glaring reason: they are important to the organisation, and both difficult and expensive to replace.

To add to this growing pile of legacy, this week Oracle announced the end of Java support for the Windows XP platform [1]. This isn’t that much of a surprise, considering that Microsoft had already dropped support for XP in recent months [2]. However, what is notable about this though is the dramatically different threat landscape. Almost no-one is interested in your old PDP-11 or Cray supercomputer, but Windows XP is quite a different kettle of fish.

Windows XP is the doyenne of the exploit writers. Not only does it lack the remote code execution protection that later version of Windows have built-in (making it easier to get an exploit working reliably) but it still has a large enough install-base to warrant the effort of writing one. On top of this, in recent months Java has been found to be riddled with flaws: the April patch bundle [3] contained no less than 37 discrete flaws, 4 of which were rated with the highest severity possible under the CVSS scheme.

So here you have a perfect storm: a critical system, relatively easy to exploit, with no patches available. Given that you can no longer patch these servers, our recommendation to you is to first have a nice cup of tea, then secondly apply some common sense:

  1. We know you would have already replaced these systems if you could have done so, but if there is any possibility of you rethinking this stance, now is a good time. The situation will not get better with time.
  2. Segregate all your legacy systems behind an internal firewall if possible. Keep them away from the general-use LAN segments and especially from desktops.
  3. Restrict remote access methods to essential users and enforce strong cryptography.
  4. Implement file-system fingerprinting to detect any unauthorised changes to the host.
  5. Make sure anti-malware and anti-virus applications are up-to-date.


Oh, and one last happy thought before you go: you are prepared for when Windows 2003 Server goes end-of-life next year, aren’t you?

  1. http://java.com/en/download/help/sysreq.xml
  2. http://windows.microsoft.com/en-gb/windows/end-support-help
  3. https://blogs.oracle.com/security/entry/april_2014_critical_patch_update
  4. http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Windows+Server+2003+R2

written by
Martin-frameMartin O’Neal
Managing Director


Call Me, Maybe?

Posted: 27 June 2014 in Uncategorized

800px-FeTAp613-1 copy

There’s one thing to be said for the world of Information Security, and it’s that it rarely stands still for a moment. New products and technologies are released with relentless regularity, each with its own particular set of security challenges to first understand, then protect. Never a quiet moment.

But as new technologies are introduced, old ones are often superseded; relegated to the “legacy” bucket. But just because they are no longer the latest hot topic, it doesn’t mean that they don’t still pose a significant risk to the organisation.

One such technology is the traditional telephone, or as it likes to be formally addressed, the Public Switched Telephone Network (PSTN). Back in the day, the media was awash with stories of hacking attacks that were launched over the telephone network. In fact, the high-profile hack that led to the drafting of the UK Computer Misuse Act (CMA) was itself delivered over the telephone, using a modem.

The Internet has changed all of this, though. As the greatest exposure to external threats for many organisations, in most cases it rightly takes the majority of the focus when it comes to security. But in this shift, a lot of organisations seem to have forgotten about the PSTN. This is a bit of a problem, as unfortunately the attackers haven’t!

The fact is that the legacy telephone system remains a rich target for an attacker. Dozens of critical devices are still installed with a remote administrative interface connected to an old-school telephone line; systems like the burglar alarm, door entry systems, the PBX itself, video conferencing, SANs, heavy machinery such as lifts, etc. Any of these could be available, and all that is often required is for an attacker to connect to the right telephone number, then enter the default credentials for the device.

There was a time when most organisations would regularly get their external telephone connectivity security tested as part of a “war dialling” exercise, but this seems to be a rarity these days. Maybe it’s time for you to get a bit more old-school?

Written by
Martin-frameMartin O’Neal
Managing Director

The Wrath of Zeus

Posted: 3 June 2014 in Uncategorized

ZeusAt the moment there is a lot of fluster in the media about the GameOver Zeus malware, and how there are only two weeks to the impending destruction of mankind as we know it. Cue melodramatic music and peal of thunder.

Firstly, we don’t think that this is a panic-stations situation. This particular malware has been tracked in the wild for several years already, so it isn’t a new threat. Though obviously the way that it is packaged and deployed are updated regularly, so it may not be immediately detected by your antivirus systems.

Secondly, the malware itself is typically delivered through a leading email, which will encourage the recipient to either open an attachment, or visit a phishing site. The important part is that it requires human intervention to activate and install it.

The recommendations for coping with this are the normal advice that users and administrators should follow on a daily basis anyway:

  • For a corporate, block dangerous attachments (executables etc.) before they reach the desktop.
  • Ensure that your antivirus is installed, correctly configured and the signatures are up-to-date.
  • Do not open emails, attachments or click on links that look in any way suspicious.
  • If you think you have inadvertently installed any malware, don’t use your computer for anything sensitive, like online banking, until you can get it checked thoroughly and if necessary cleaned

Additional information about GameOver Zeus is available here: http://www.us-cert.gov/ncas/alerts/TA14-150A

Written by
Martin-frameMartin O’Neal
Managing Director

When our clients approach us with a new application or a technology refresh project, we often see an initial reluctance for an external infrastructure vulnerability assessment to be performed along-side. This is often because the client feels safe that their infrastructure is protected by network level devices such as firewalls or intrusion detection systems, or that modern software and servers are secure out of the box. Well that’s not always the case…

Acme Corp CMS Assessment

Acme Corp approached Corsaire to conduct an application assessment on their new content management system and an external infrastructure assessment on 1 IP address. The application server would be located in the client’s DMZ and protected by a firewall only allowing HTTP and HTTPS. Corsaire was provided with the following URL which would be in scope for this project:

https:/ /cms.acmecorp.com/application/cms

Apart from some low hanging fruit the CMS application was found to be secure. Everyone is happy! Go team!

Is Infrastructure always Boring?

So I get given the infrastructure component of the assessment and my worst fears are soon realised; only 80 and 443 are exposed to the Internet. I quietly work through our external infrastructure methodology and only find low risk SSL issues and some default Apache pages. Default pages are always a good indicator of a lack of server hardening, so I decide to have a further poke around. I manage to find a default configuration file which has some information disclosure, but still nothing to shout home about. As always with any assessment, an understanding of the environment is essential. This involves reading any documentation you can find including installation, configuration and development guides from the supplier. The documentation included a typical configuration scenario which when compared with the findings from the application, was probably the configuration of this CMS system.


In this typical scenario the CMS application and API are hosted on the same server. This is never a good idea. Separation of services people! Anyway, this got me thinking about how the API is configured and how the CMS application interacts with it. Could I connect to this? Oh this is getting interesting!

Pew! Pew! Pew!

Trawling through the documentation, it was determined that the API could be configured as another virtual host served by the same Apache instance as the CMS application! Oh goody, if they have done this then all that is required is the correct domain name to send with the request to potentially start interacting with the API! The default setup from the documentation didn’t work, but by using the information revealed in the default configuration file I managed to get a hit! Bingo! I have direct access to the API using https:/ /cms-api.acmecorp.com bypassing any security provided by the CMS application. Oh dear, they are still using default credentials. Pew, Pew, Pew! I now have full control of the CMS and content.


While the application in scope was secure, the infrastructure and server configuration was still in a default state and had not been hardened. The API was assumed to be internally accessible only, so the default credentials were not changed. Without the infrastructure component of this assessment, access to the API would have potentially not been found.

Lessons to be learnt?

  • Never underestimate the importance of infrastructure assessments when deploying a new application
  • Always harden all servers irrespective of their network location
  • Always restrict access to any service unless explicitly required
  • Ensure separation of services to reduce exposure and risk
  • Understand the environment and RTFM!


Written by
Ant-frameAnthony Dickinson
Sercurity Consultant

ICO Report

Posted: 16 May 2014 in Uncategorized


The recent Information Commissioners Office (ICO) report makes for interesting reading. Although it is relatively high-level, and targeted more towards managers, the report and supporting guidance provide some clarity for InfoSec professionals too.

Firstly, by targeting the management audience, they are re-emphasising that the responsibility for ensuring that personal data is appropriately protected is company-wide; not just the domain of a few industry specialists.

Secondly, the announcement sets out its stall by making immediate reference to punitive fines. In recent years the ICO have increasingly chosen to make an example of high-profile failures, and the fines have been significant. They are making it clear that there is no change to this tack.

Thirdly, the small number of issues listed by the ICO are all basic security measures. Other than their relative simplicity, they do share a common thread, in that all of them could allow the gathering of DPA data en masse. For example, the report specifically singles out per-user style flaws like Cross Site Scripting (XSS) as something they are less interested in.

So in summary, the report is not really saying anything new, but it does spell out very clearly the current ICO approach to policy:

  • DPA resources must be protected as appropriate
  • Responsibility lies with management
  • Breaches will result in fines


  1. http://ico.org.uk/news/latest_news/2014/top-it-data-security-threats-revealed-and-what-organisations-must-do-to-stop-them-12052014
  1. http://ico.org.uk/news/latest_news/2014/~/media/documents/library/Data_Protection/Research_and_reports/protecting-personal-data-in-online-services-learning-from-the-mistakes-of-others.pdf

Written by
Martin-frameMartin O’Neal
Managing Director


The main threats that organisations and their customers are facing today are the same ones that have always been around: ignorance, apathy and poverty. And the best thing that any organisation can do to reduce the impact of these, is to simply get the basics right. But you won’t be able to do anything if you don’t know your threats, don’t have the appetite to address them, or don’t have the budget to pay for the solutions.

Security for the business itself, or for its customers, is all about gaining a good understanding of the risks, and then building appropriate processes to ensure that they are balanced against the effort and cost of addressing them. Everything else is really just window dressing. For example, that shiny new security appliance that you were looking at last week (available in suitably bold primary colours) will not make your organisation secure. There are no magic bullets, only good sense and hard work.

And now we get to the nub of the problem, the typical board of corporateville. These busy people can, quite literally, talk for days about the colour of the latest product packaging (mauve or taupe, darling?), but when it comes to where those pesky credit card numbers get stored after you have taken your clients money, then they tend to be far less talkative. Until things go wrong.

Increasingly, the legislation and regulation that cover security are being given real teeth, to punish those who flout them. Punitive fines, suspension of trading facilities, and ultimately, members of the board can go to prison. And what would any busy person (upon finding themselves staring down the barrel of a punitive deadline), be looking for in their hour of need? You’ve got it; their gut instinct will be to bite the hand off the first magic-bullet solution that comes along. If you are the person responsible for security, the trick is to make sure that the particular bullet is one of your choosing (magic or otherwise).

The real problem with all this, I would say, is that the attention span of the typical board is about three weeks, starting from the last high-profile security event (be it a failed audit, a rogue employee, or a successful hack etc). And the biggest challenge is seizing this slim window of opportunity, and using it to your maximum advantage. If you don’t get your plans in front of the board, and budgets signed-off in these three weeks, then you might as well keep your pipe and slippers to hand, because you won’t be doing anything more interesting in the near future.

So to summarise, if you are apathetic, simply go back to your mochaccino now (this next bit isn’t for you). For everyone else, start your preparation today; profile your organisation and understand the real risks. Then pull together some sensible solutions and ballpark budgets to address them.

And finally, the next time that your organisation is struck by a compelling event, you can simply set out your stall. You’ll be thinking comprehensive solution, they’ll be thinking magic-bullet, and everyone should end up living happily ever after. Well, everyone except the VP of hospitality who (after reading an article in an in-flight magazine about security) was hankering after a puce-coloured security appliance for the datacentre…

Written by
Martin-frameMartin O’Neal
Managing Director

heartbleedTo give you some context, I’m writing this blog in the days immediately following the Heartbleed event. I’m not going to comment on the event itself, as it has been done to death elsewhere, but I am going to focus on the reaction of the affected organisations.

Events like this, whilst rare, cannot be avoided entirely by any organisation that uses computers attached to the Internet. Software has flaws. Some flaws will be catastrophic. It’s a given. However, knowing this, you can prepare for the worst.

Firstly, many organisations had no idea what their attack surface was. Sure, it’s fairly trivial to point at the corporate web site. But many simply weren’t aware that there was a vulnerable SSL component in their other internet-facing applications, like their email servers. Understanding your attack surface simply has to be the first-step of protecting it. Otherwise, how can you protect that which you are not aware of?

Secondly, whatever incident response process they had just seemed to crumble. The flaw itself, whilst devastating, was thankfully easy to patch or otherwise mitigate. Then after that, there was simply a requirement to regenerate the certificates and finally force any authentication credentials to be expired and changed. It was clear that many high-profile organisations had taken no action long after the vulnerability was being actively exploited in the wild. Being objective, at this point, any services that were deemed to hold confidential data should have been simply taken offline to protect the brand. Decisions like this need to be pre-made by executives, and solid processes need to be established in advance, so that they can be carried out swiftly by the staff that administer the systems.

The reality is that this isn’t going to be a unique event. There will inevitably be others to come.

If your organisation does not understand your attack-surface and does not have a comprehensive incident response process already in place, then now is the time to act. You may be shutting the door behind this particular horse, but rest assured that there are plenty of other horses that you can still protect.

Written by
Martin-frameMartin O’Neal
Managing Director