Safari users click here: Windows 7 & 2008 x64 Safari iframe vulnerability

A zero day vulnerability with the way Safari handles extremely large IFRAMES running on a Windows 7 & 2008 64-bit platform has been found to cause a kernel level blue screen. Windows 7 and 2008 (non R2) 32-bit systems are immune to this flaw.

The very simple Proof-of-concept code (shown below) has now been leaked into the public domain: the simple HTML script, when opened in Apple's Safari web browser, quickly leads to the kernel triggering a page fault in an unmapped area of memory, which halts the machine at a BSOD blue screen of death.

<iframe height='18082563'></iframe>

You can view the iframe exploit (in Sfari, of course) from defendingthenetwork.com here

Worst part is that we can now social engineer users to either open the attachment via e-mail or get them to download the file. Since the exploit is simple HTML code, no IDS/IPS or AV solutions will trigger an alert. Though we can look for the above string signature using Snort or manually create a trigger rule on our security solutions.

Worrying problem is that hackers are now looking for the underlying code execution path to discover how we can further use this exploit to perform remote code execution to either install malware rootkits or gain access to privileged parts of kernel memory.

To be honest, usermode applications should not be able to bring down a machine.

According to ThreatPost, Microsoft hasn’t confirmed the weakness, but the issue is being looked into.

“We are currently examining the issue and will take appropriate action to help ensure the customers are protected,” said Jerry Bryant, group manager of response communications in Microsoft's Trustworthy Computing Group.

So far, the attack method seems to work only on Safari, but it may later turn out that other web browsers can be utilised to launch a successful malicious operation. 

Time to remove Safari off your network? (why was it there in the first place?)

Dan

Food for thought VDI: Good move, new security risks?

Cloud based Virtual desktop infrastructures or VDI, is now common place in the enterprise sector. Improved security is consistently the key business driver for VDI for most companies, followed by ease of overall management, strategic application or cloud SaaS\PaaS deployments, and enhance remote access - especially via non-Windows or consumer devices such as tablets and smartphones. Furthermore, desktop virtualisation has removed physical assets from the network by moving isolated workstations and applications that were once separated by hardware and network levels onto a single server; in theory.

So, rising to meet this shifting environment are newer, alternative solutions, including the classic virtual desktop infrastructure and, more recently,  desktop or user virtualisation. Though these alternatives are not viable replacements for traditional desktop security management. The changes advocated by these approaches are not accompanied by adequately broad or maintainable gains. 

Instead, we now have Intel who proposes an evolutionary framework called Intelligent Desktop Virtualization, or IDV, whereby the overall system of managing user computing is made significantly more intelligent. IDV embodies an approach to desktop management that ensures the user experience is always maximised while also giving security engineers all the control it requires within an economically viable framework.

By migrating to a VDI service, we security folk can fundamentally deliver a more secure working environment to our users by streamlining desktop management for patching, improving the security strategy for incidents, migrate data risks on typical physical endpoints and ensure operational user continuity.  For example, from SearchSecuirty @ Techtarget, we can clearly see the befits in terms of security for an VDI envrioment;

Centralised provisioning allows security engineers to create virtual desktops from authorised images. Instead of chasing and assessing distributed endpoints, security operations in a  VDI approach only have to patch, upgrade, and check vulnerabilities of desktop applications on the centralized farm. This has the potential to significantly improve security performance metrics, including those for patch coverage and time to remove critical desktop vulnerabilities.

Once a compliant desktop image has bee created, terminating idle virtual desktops during off hours and re-provisioning automates the delivery of compliant desktops to the user, effectively reducing the possibility of desktops drifting out of compliance. This not only allows IT to easily deploy new software agents, replace software that is not easily patched such as obsolete versions of Adobe, Java, or custom built applications, but it also means that malware is less likely to persist on the desktop because the malware disappears when the virtual desktop is terminated.

Security software can be shifted from individual desktops to become a shared resource on the virtual server host. For example: Antivirus that is designed for VDI shares signature pattern files and coordinates system scans across all virtual desktops resident on the server; transparent disk encryption can be enabled for sensitive data; virtual patching allows security to plug a critical vulnerability at low levels in the server without disrupting users’ desktops; and high performance application whitelisting is being utilised to ensure the integrity of the virtual desktop. This approach reduces the complexity and costs of managing desktop security – and antivirus will always be active with the most up-to-date patterns. Hypervisor aware AV is now the de facto for virtual farms.

User virtualisation technology removes user preferences from the desktop allowing users to move freely between virtual desktops, remote desktops, and mobile devices and tablets. As organisations evolve from physical to virtual desktop infrastructures, user virtualisation can provide the consistent look and feel across devices to increase user satisfaction and increase the chances of a successful VDI roll-out.

Simplify data leakage prevention, DLP,  strategies by restricting sensitive data to the data center with virtual desktops. Since the data never leaves the data center, not only is there less risk of costly disclosure incidents due to data loss, there is also less demand to purchase and administer device control and DLP software on desktops.

Sensitive data can be transparently encrypted, and data center resources can be used for automatic backup and recovery of desktop data. The separation of data from the physical constructs of the PC also allows security executives to evaluate the cost savings of cloud-based storage.

Reduce the costs of a disaster recovery plan by shifting virtual desktops to remote data centers. Rather than purchasing extra hardware in stand-by data centers, business continuity services maintain copies of the provisioning server to be able to recreate virtual desktops and reconnect users to the business.

 

All sounds great, but like all things nice and shiny, we have some concerns. VDI has its own set of associated risks which unfortunately not most people know of.

Before virtual machines, compromised systems gave attackers access to the internal network. With virtual machines, not only do they get access to the network, but also any attached virtualisation infrastructure, putting all virtualised systems  and the data they contain at risk.

With various virtualisation platforms, the attack surface (the area that systems are prone from attack)increases from multiple physical machines to standalone hosts containing numerous virtual machines. So why can an attack area widen despite your efforts at server consolidation? To prevent this problem, you need to treat each VM as a standalone host and consider the physical servers on which they reside.

For example, all a Virtual machine is at the basic level is a set of configuration file and a virtual disk file. An attacker can easily gain access to the storage network, SAN or intercept storage traffic and grab the virtual files, resulting in the actual machines and any data being stolen. I have seen proof of concept rouge deployments, in which the attacker can replace the virtual machine files with a modified compromised versions, again resulting in an internal breach; we can protect against this to a certain degree but VDI opens up security risk that previously would not be feasible within physical desktop constraints.

For instance, malware scanning tools will need to look specifically for emerging malware that targets virtual platforms and will need to be created with a virtual platform in mind.

Look at storage; NFS, iSCSI, and SAN storage pass data in clear text, which implies disk data can be read by others. If a VM has mounted an iSCSI target from the same storage network as used to hold virtual disks, then this is a possible attack point. Take HP left-hand network boxes, have you change the default SNMP string as we can exploit a known vulnerabilities to gain root access to the storage array.

Finally, I have also seen poorly configured hypervisors with default SSH access credentials, console NIC’s inside DMZ networks, unencrypted replication traffic sent over WAN…

Food for thought?

Dan

This post is brought to you in partnership with Intel(R) as part of the “Technology in tomorrow’s cloud & virtual desktop” series.

Thanks to Intel, VMware & TechTarget for some of the material above

Is malware on the network the equivalent of being hacked? or are you just a target?

I think the best way to clarify the difference between a hack and malware is if the attack in general has a specific target victim or target.

Firstly, it is important to note that as a security professional and trained ethical hacker, we are seeing an alarming increase of malware taking advantage of what we call Zero Day exploits; to which the software vendor has no fix for the vulnerability and is actively being exploited in the wild.

Nearly all of 2011 most publicised breaches, for example RSA\EMC, Sony, Lockheed Martin can be traced back to exploiting this type of attack. For example, both Iran and the USA are currently engaged in resolving two particular nasty but extremely clever state sponsored cyber weapons, Duqu and Stuxnet - again exploiting Zero day vulnerabilities on not only software but at a hardware microcontroller level. Sadly, the only way to isolate from this type of attack vector is use what we call Heuristic signature based or pattern analysis on the wire. This is why a secure perimeter network design will include IDS & IPS (some next generation firewalls will offer this service to some degree) to detect the exploit on the fly. Vendors such as Stone soft and HP Tipping point are currently the best in the industry at the moment, and I have implemented many of their solutions into network designs.

Though even with this solution, the human risk factor still plays an important role as a part of overall security of the system life cycle. You need to train users on the correct way to handle security incidents and what to look out for - ultimately, when everything bypasses your security defences, they do open that carefully crafted PDF attachment and launch the exploit, as to some degree you can only immunise your network to what you see on the threat landscape today. No matter what your end point is, fat client, mobile client or VDI, the principle is the same.

Take Duqu for example; due to the construction of the exploit and the payload carrier mechanism, nearly all IDS/IPS devices on the market apart from the predator engine found in Stonesoft deployments will not trigger suspicious activity alerts. Why? Quite simply the malware was designed to float right past even the most elaborate security perimeter by using methods such steganography to make the payload look like an .jpg, and using proxy based transversal to jump straight through common service ports such as HTTP and SMTP - who would class jepgs flowing through port 80 a issue?

That fine balance of security vs usability is sometimes an art. Networks should be designed from the ground up with security in mind, but near enough most complex infrastructures will have at some-point a weakness due to human configuration or at worst 'applied' lack of the correct knowledge. Hell, I've seen some companies configure their firewalls to plain any/any rule bases just because an lazy engineer couldn't get a service to map correctly; scary thought but true.

Social engineering is the de facto method in gaining access to any resource. Remember, hackers most of the time do not hack for the 'luz' , but for serious cold hard cash. It is a multi billion pound industry where a simple set of customer records or PDI can sell for on average on the black market £103 ago - how many records do you hold on your customers, trade secrets, R&D ect?

Target the Finance director who has ordered the IT department to have full access to everything and you have an easy way of crippling his company, hell you could even target the IT department themselves - no one should have full administrator rights on any network period - rights and delegation access should be enforced, in an AD environment this is simple. But when the smelly brown stuff hits the silver twirly thing typically the IT guys will get it in the neck.

 Just comes down to correct way of delivering a non technical but informative security training session to the end user. If they understand the risks, respect what is in place then it makes information security a lot easier to enforce and audit. 

A very open rant, but malware on any network could be a part of a bigger plan.

Dan

Son of Stuxnet - Duqu Iran's response ?

A few months back I engaged in debate with various peers and discussed how I felt that the first true nation-state supported cyber weapon was intentionally deployed to the world. The aftermath followed, resulting in widespread speculation that the USA and Iran were engaged in cyber warfare.

The consequence of this attack opened Pandora’s Box for security professionals. We discovered a specialised computer worm that was the first exposed malware designed from the ground up to target industrial Siemens SCADA microcontroller systems, the first to include a PLC (programmable logic controller) rootkit and take advantage of no less than four Windows zero-day exploits (including CPLINK). This was the birth of Stuxnet and a kick start for governments across the world to start taking cyber warfare seriously.

Stuxnet was very different to most promiscuous  worms we have come across, unlike Conficker, Stuxnet was designed with a designated target in mind and was coded to prevent wide spread infections, thus keeping the area of infection very localised - 60% of all infections were reported in Iran. On 24 Junes 2012, the worm was designed to erase itself, leaving no trace.

Built in the payload was code for a man in the middle attack, which was crafted to disrupt PCS 7 control sensors readings causing an ‘abnormal behaviour’ signal with in the Siemens STEP7 controller logic. The exact same systems are deployed in various hardware regulating Iran’s uranium enrichment facilities - IUEF.  Writing the code would have taken many man-months, if not years and the complexity of the code indicates that only a nation state would have the capabilities to produce it. It was also theorised that a carbon copy of IUEF was built to test the payload.

Furthermore, the Stuxnet sample was unusually hefty at 0.4MB which is again dissimilar to many worm designs in the wild today. Packed inside the payload was a windows kernel rootkit that contained ‘digitally signed’ low level device drivers which allowed under the radar intrusion and long term privileged access without detection. The conspiracy theories start to gain weight when we look at the digital certificates used to authenticate the drivers. Both private keys were stolen from JMicron and Realtek , located on the same science park, acquired through elaborate social engineering and espionage .

On 29 November 2010, Iranian president Mahmoud Ahmadinejad stated for the first time that a computer worm had caused problems with the PCS 7 controller handling the centrifuges at its Natanz facilities. On the same day two Iranian nuclear scientists were targeted in a separate, but nearly simultaneous car bomb attacks, furthermore emphasising the crossover between cyberwarfare and real world covert sabotage.

Iran’s Response – An electronic war has begun

In response to the infection, Iran assembled a team to combat Stuxnet. With more than 30,000 IP addresses affected in Iran, an official had said that the infection is fast spreading and the problem has been compounded by the ability of Stuxnet to mutate – a new variant was discovered Q2 2011.  Iran had set up its own systems to clean up infections and has advised against using the Siemens SCADA since it is suspected that the built in antivirus is actually embedded with codes which update Stuxnet instead of eradicating it; a feature we have seen  before with Conficker.

Duqu;

On 1 September 2011, a new worm was discovered with remote access tools (RAT).

At first it was thought it was another variant of Stuxnet as the sample contained some identical code. The kernel driver JMINET7.SYS was similar to Stuxnet's MRXCLS.SYS, and the same rootkit injected using similar forged signed drivers (the original certificates were revoked by VeriSign). The only missing part was the schema PCL to target Siemens controllers. The researchers named the threat Duqu because it creates files with the file name prefix “~DQ”.

Like stuxnet, Duqu exploits another Windows zero day vulnerability (Security Advisory 2639658) in the Windows TrueType font parsing engine T2EMBED.DLL. By exploiting this vulnerability the worm could inject arbitrary code in the Windows kernel permitting a RAT to be installed as a low-level rootkit, and like its older sibling remove itself after 36 days.

Duqu’s payload is embedded into .doc files and typically sent to the target via email, bypassing a well configured secure zone and filters. By opening the document the exploit is performed without the user being alerted. Social engineering plays apart though, as the user must interact with the embedded file, but this is as simple as pretending to be from the I.T helpdesk and instructing the user to open the file.

The same attack vector resulted in the breach at RSA/EMC.

Should I stress how important user training is again? Even basic security training can prevent this.

As a workaround, users can deny access to T2EMBED.DLL. Instructions on how to do that are contained in the advisory, linked to here. When the workaround is applied, applications relying on embedded font technology will not display properly.

So, Duqu was born from Stuxnet’s source code – though similar, it was designed with a completely different purpose. The primary intention of Duqu is to deploy tools that can capture as much intelligence from the targeted machine as possible such as secure documents, keystrokes, system information and digital certificates. Duqu then transmits the captured data back using Steganography methods by masking data in an encrypted jpg; by using standing HTTP and HTTPS tunnels, most IDS and firewalls will just let this outbound traffic through.

A digital spy, gathering information that could be used for future attacks? A worm on a mission? What is next?

What is most interesting is that Duqu was highly targeted towards a limited number of organisations for their specific assets. For example a number of UK chemical and defence companies were also targeted. We also do not know the complete target base of Duqu mainly because that most researchers are under NDA and conforming ‘correctly’ to responsible disclosure terms.

Researchers are still analysing the precise behaviour of Duqu, but so far, they have detected nothing that causes it to disrupt the operations of its target. Instead, it appears to be on a stealthy reconnaissance mission that sends intelligence data and assets to a server using encrypted and plain-text web protocols. The data being gathered appears to be designed to allow the operators to more easily conduct a future attack against a third-party target.

For now, we could speculate that maybe this is Iran’s retaliation to Stuxnet – or at least another state sponsored cyber weapon.

Watch this space.

Dan

Company cuts entire backup window from five days to 12 hours - Oh, it's a virtual infrastructure running on Intel kit

Looks like one of my latest virtual infrastructure migration and disaster recovery projects is getting some decent press attention, along with being nominated for a best of VMware VMworld 2011 award this year.  

Saying that I am a euphoric fan of vSphere and ESXi is an understatement. The power, flexibility and resilience of implementing a private cloud solution can benefit any company of any size. Whether you are looking to reduce power draw, consolidate rack space, migrate platforms or just looking to provide your users with a redundant and streamlined environment, VMware's portfolio of products enables you to design some impressive topologies. 

I have lead many P2V and V2V migration projects, with this latest one being the most challenging yet most rewarding. Migrating from a heterogeneous environment consisting of UNIX, Wintel and Citrix Xen hypervisors to a resilient data farm protected by VMware DRS and some Tinsley dark fibre routing magic. 

Of course, you still need to protect your VM's (server application and state data) and in some sense, still treat them as physical machines when designing your back up strategy; or do you? 

Traditional backup solutions/strategies relied on porting data from each individual server by either push/pull or pull/push methods using agents to transport data to a backup medium (Tape, D2D, San ect) or cluster. The problem is that on a virtual infrastructure, each VM that runs a traditional backup agent will hamper the I/O of the hypervisor and SAN environment it coexists on. The same principle goes for Anti-virus or endpoint protection products that are not hypervisor aware - I will be blogging about Sophos SAV version 10 beta in the next few weeks. 

So, how do remove the performance impact that traditional backup products place on your well designed virtual environment? Simple, use a backup and recovery solution that is designed from the ground up for a virtual environment! 

I have long been a fan of Acronis products and have been implementing their software since early 2005. My current 'weapon of choice' for providing a complete backup, recovery and DR solution for a VMware environment is Acronis Backup & Recovery 11 Virtual Edition (link), along with their new product (still being tested in my lab) Acronis vmProtect. 

No agents are required on virtual machines being backed up or recovered, thus freeing resources on the hypervisor and simplifying management. Instead a special Agent for ESXi may manage backup and recovery of as many virtual machines as required, even on multiple hosts. One agent may backup up to 10 virtual machines at the same time – increasing overall backup speed and reducing backup time. 

During backup Agent for ESXi automatically attaches snapshots of virtual disks and reads data directly, reducing load on host’s TCP/IP stack and gaining superior performance. Combined with ability to use ESXi storage as backup destination, this allows to route data traffic though a dedicated storage network instead of the storage LAN. 

The agent and all virtual machines are managed from the same centralized console as other agents and virtual machines. This makes Acronis Backup & recovery 11 a unique solution for holistic backup and recovery of both physical and virtual environments.  

Simply put, you can worry less about your DR plan knowing that with VMware vSphere DRS and Acronis you’ve got it covered - tried and tested by my good self.

Financial services company The Funding Corporation has cut its backup window from five days to 12 hours following a move from Symantec tape-based backup to Acronis Backup & Recovery with disk-based backup.

The backup upgrade formed part of an ongoing server virtualisation project at the 240-employee company, which has three UK data centres. It currently runs 102 physical servers, of which the majority will be virtualised by the end of 2012. Most are Windows-based but the company also runs Oracle, Sun, Microsoft Exchange, SQL and key financial business applications.

The migration from a physical to a virtualised environment as well as massive data growth meant the time taken to complete network backups was becoming a concern, with each full backup taking five days to complete using its existing Symantec tape-based backup solution. Data recovery was also a problem, typically taking a few days to restore a server from bare metal.

After evaluating and testing products including Symantec Backup Exec, Symantec NetBackup and solutions from CA Technologies, The Funding Corporation decided on Acronis Backup & Recovery 10, which backs up to an Overland N2000 SnapServer. The upgrade has cut backup times from five days to 12 hours and the Acronis product is also being used to migrate data to the new virtualised environment.

Dan Tinsley, principal systems engineer at The Funding Corporation, said, “Acronis offered a smooth integration with VMware, which is key as we move into a virtualised environment. The speed of a bare metal recovery was also impressive as was the functionality that Acronis offered as standard.”

Link to press release

If you require any help designing, implementing or securing your virtual cloud infrastructure, get in touch on the contact/consultancy page.

Dan

Oh forgot to mention my cool way of designing a decent backup solution 3-2-1

3 – Three copies of all data in use or data in motion

2 – Stored to at least two different mediums of different technology 

1 – One must be off site or to the cloud

 This post is brought to you in partnership with Intel(R) as part of the “Technology in tomorrow’s cloud & virtual desktop” series.