Researchers at the University of California’s College of Engineering and the University of Michigan have identified a weakness in Gmail’s mobile application that could allow malicious third party apps to obtain personal information from users’ email accounts. Researchers found that 92 percent of Gmail accounts, and around 82 per cent of the several apps they tested, can be cracked using the memory interrogation technique.
While this is an alarmingly high success rate the important fact is that this predominantly results from social engineering attacks or downloads of infected applications rather than a direct flaw in the Gmail application. This can probably be linked to the fact that both businesses and individuals are increasingly using a range of mobile applications from a variety of developers and sources. While these applications can have a lot to offer it is important that users consider the access they may be inadvertently offering to third parties by using such services.
With applications often requiring a variety of access permissions, people need to be aware of the other functionality and systems running on their device that they might be making accessible to external parties and hackers. Individuals and businesses alike should carefully consider and research what applications they are downloading to their mobile devices to ensure they don’t inadvertently leave themselves open to attacks from hackers. Simple steps like only downloading apps from trusted stores and developers can massively reduce the risks of cyber-attacks that people are exposed to.
In the case of businesses this should fall under a clearly defined data loss prevention strategy that covers all aspects of their IT operations. This includes both managing the applications used on corporate devices and ensuring staff receive the required training to reduce the risk of an infected app making its way onto the corporate network.
Irish bookmaker Paddy Power has admitted that personal details of more than 600,000 customers were stolen in a cyber-attack that occurred in 2010. The company revealed that it was aware of an attack on its system four years ago but failed to inform customers of the security breach.
Data including names, usernames, postal addresses, email addresses, phone numbers, dates of birth as well as security questions and answers were stolen, although it’s not thought that financial information was accessed or that any customer accounts were violated. The company was informed in May this year that a man in Canada had a large database of customer information, but it remains unclear how long Paddy Power has known about this security breach, or whether they knew the full extent of it.
Failing to inform people of a data leak in good time leaves customers exposed to the danger of identity theft. Any security breach, no matter how big or small, should be taken seriously by organisations and communicated to customers to enable them to take necessary steps to minimise the damage caused to them personally. It’s also essential that an organisation properly investigates how the data was stolen and closes off any vulnerability that may have enabled the theft.
In this instance the information stolen placed affected account holders at severe risk of further social engineering attacks and identity theft. While a security breach will always draw negative attention it is always better to communicate quickly and openly to restore customer trust and ensure that customers are better protected against further attacks.
Before naming your vulnerabilities became cool (Heartbleed anyone?) I discovered an issue on the EMC Documentum software and internally called it “injeception”. Now that naming your vulnerability is so mainstream I will just call it ESA-2014-046 (that, surprisingly, matches with the name used by the vendor!)
But why that name? Well, it’s 2014 and they have released other 45 vulner…. Oh, you mean the injeception? Well, because if you do an injection inside an injection; let me explain to you how it works:
- The EMC Documentum software uses an abstraction layer to allow the software to use any backend database server, such as Oracle or MSSQL. This layer uses their own query language (DQL, from Documentum Query Language) and this the first part for the injeception to work.
- I found an issue (CVE-2014-2508) that allows me to inject DQL at the end of a query. Descriptive error messages also helped to understand what was happening on the backend.
- We are now at the DQL level (moving from the app level that we were before) and we are still confined to the ORM system that EMC has in place to prevent users from one unit/department accessing files from other departments.
- Reviewing the DQL Reference Manual I found references to two interesting keywords: ENABLE and ORACLE. The use of both can be seen in the page 323 (Passthrough hits) of the manual. It essentially allows insertion of custom Oracle (and presumably MSSQL, but didn’t have the chance to try that) SQL into the final query that is generated by the Documentum software. We have our third jump! (And I think this one is CVE-2014-2507 but I haven’t been credited for this one, so I am not sure if I am right assuming this…)
- Now we find ourselves in an interesting position. We are inside an Oracle hint. For those who don’t know (I didn’t at the time) hints are a special set of keywords that you can write between the SELECT and the first parameter of the query to improve the performance. Like this:
SELECT /* HINT */ 1 from dual;
- So… can we escape from the hint syntax and execute code? Sure thing! If we write ‘*/’ Documentum passed it unescaped to the SQL query and we are able to inject any SQL query from our original DQL injection. Let’s go up a level again on this injection to construct the final valid query.
- First we need to make our Oracle query:
*/ user FROM dual--
- Now we need to add it into a valid DQL query:
ENABLE(ORACLE('*/user FROM DUAL--'))
- Finally, we have to add that string at the end of our DQL Injection:
table_field from valid_table ENABLE(ORACLE('*/user FROM DUAL--'));--
- As you can see we need a valid table and a valid field but I got those from the debug messages, documentation might also help.
This way we have moved from a DQL Injection (CVE-2014-2508) to a shell injection (CVE-2014-2507?) and execute Oracle queries. But what about CVE-2014-2506? Well, the user running those Oracle queries does not have any privilege limitations so it can access any information, no matter what department or OU the user executing the DQL is member of, they will access even configuration details from the server.
A new report released by Damballa this week revealed that the average enterprise will have 18.5% of machines infected with malware, with the figure unchanged across larger and smaller organisations.
While the report focussed on enterprise sized businesses it is safe to say malware has no concept of business size, it merely seeks out vulnerabilities and exploits them, meaning any organisation that stores data is a potential target. This means that anyone from a small local run business to a large multi-national corporation is exposed to the same threat level with their risk level depending on how robust their cyber-security defences are.
A common trap to fall into, particularly for smaller businesses, is that they believe that they have nothing worth having for cyber-criminals to target and don’t need to worry about cyber-security. Equally some organisations hold the misconception that by purchasing and implementing a security product, then their business is inoculated against internet-borne threats.
This latest report, however, highlights that business of all sizes need to be aware that security is an ongoing process and that threat avoidance goes far beyond just having products in place. This includes ensuring that staff are made aware of best practice and receive training on common threats such as social engineering and phishing attacks.
Protecting a business and its customers against cyber-attack and data loss is a multi-faceted, relentless task that requires careful consideration and robust systems and policies. Some elements of this are more complex than others but ultimately those challenges can, and must, be overcome.
What there is no excuse for, however, is a business knowing about, and failing to rectify, a simple, easily fixable flaw in its cyber-security as seen with PayPal this week. Having been alerted by an Australian hacker that a flaw existed in some aspects of its two-factor authentication system, making it possible for it to be by-passed, in June, the hacker went public with the flaw this week as it had still not been resolved.
A fundamental flaw, such as this, in how the authentication is handled, is easy to avoid and shouldn’t have been allowed to occur in the first place and what’s more it is simple to fix. Two-factor authentication, when properly executed, can add invaluable layers of security, providing the user chooses a strong password.
It is critical that any flaw, whether it be simple or complex, large or small, is addressed quickly and efficiently to provide businesses and their customers with maximum security at all times. In this instance it would appear PayPal has been lucky that it has not suffered a major breach as it works to fix the issue. However businesses can’t, and shouldn’t, rely on good fortune as a method of cyber-security.
Hackers have once again been targeting LinkedIn using new phishing emails targeting users, which aim to trick recipients into clicking on a link by claiming that their LinkedIn accounts have been blocked due to inactivity. While on the face of things this may seem like an issue for individuals with no cause for concern for businesses, nothing could be further from the truth.
While LinkedIn provides a rich source of personal information for attackers it is how this information is used, once it is obtained, that should be a concern for businesses. Armed with personal data, including where an individual works, job role and contact details, hackers will look to further exploit this in social engineering attacks, which could prove costly both to the individuals and the organizations they work for.
Phishing emails continue to be the most common source of information for social engineering attacks and this further highlights why educating employees about the risks posed is of vital importance. By providing extensive education of data loss prevention organisations will significantly reduce the chance of an attack or their employees unwittingly handing ammunition to hackers to use to mount attacks against an organisations data.
New research published by IS Decisions this week suggests that more than a third of former employees still have access to company data and/or systems after they have left an organisation with nearly 10% of employees polled admitting they had used their access/data rights after they had left an employer.
The finding of the report suggest that to many businesses have a culture of “out of sight, out of mind” where employee data access is concerned – a worrying trend given such attitudes can drastically increase the scope for data loss.
The report makes five main recommendations, including better education on security among management; restricting concurrent access to systems; considering harsh penalties for transgressions; restricting network access to departments at certain times; and making the process of securely delegating work (and access to systems) a lot easier.
While these recommendations will certainly help tackle the issue we believe that it should also include an effective DLP strategy that covers not only types of data and where it is stored, but also which employees have permission to access it, from new joiners to contractors and those leaving the company. Organisations should be conducting regular audits to maintain best practice, and where applicable, revoke employee access. The potential risks that organisations expose themselves to by not considering employee permissions and access points can’t be understated – and neglecting to deploy vigilant post-termination processes can leave companies wide open.