Posts Tagged ‘data breach’

limecrime

You may have heard of some of the big name hacks that happened this past year, SingleHop has posted a great blog article highlighting some of the industries and companies that were affected [1]. But you may not have heard about some of the smaller companies that were breached, because let’s not forget that no company is too small to be a target for a black hat. In fact – smaller companies with weaker security policies, and potentially no security process, may even be a better target for hackers who are looking for a quick and easy target.

A great example of this is popular independent makeup company Lime Crime [2]. This month they announced their website had been compromised, however the breach took place as early as October 2014. This has resulted in their customers not only having their usernames and passwords compromised, but those who opted to pay for their purchases directly through Lime Crime’s website, and not Pay Pal, also had their card details stolen. They are now the victims of credit card fraud.

Thanks to sites like Reddit [3], you can easily see the effect that this breach has had on the company and the backlash they’ve received from the indie, and even the mainstream, makeup community. People who loved their products no longer feel secure purchasing from the company and those people who would be clients are now advising other potential buyers of “dupes” (duplicates) for beloved Lime Crime products.

Despite the tragedy that the hack was, there is a lesson that can be learnt here. Never forget that no company is too small or insignificant to be the target of cyber crime.

Small business owners: Are you keeping your customers data safe?
[1] https://www.singlehop.com/blog/5-industries-devastated-by-data-breaches-in-2014/
[2] http://limecrime.com/security
[3] http://www.reddit.com/r/MakeupAddiction/comments/2w0g44/lime_crime_deletes_ig_photo_after_being/


Written by
Panda-frame

Amanda McKinney
Project Coordinator
Corsaire

Moonpig-dead

Happy New Year everyone, we’re only seven days in, and once again the news is filled with tales of woe that has security researchers cackling round our collective fire pits.

Moonpig, a London based company that is the UK’s largest personalised greeting cards specialist, have been caught out with an absolute shocker. The android application distributed by Moonpig used a RESTful Application Program Interface (API) to communicate with the endpoints and allow users to place and view orders and modify their accounts.

Security researcher Paul Price[1] identified a flaw in this API. The authorisation header sent by the application was a static username and password sent by every request within the application (which was latterly identified as not being needed at all). Further testing showed that modification of the ‘customer ID’ parameter of the request (a sequential value) allowed access to any users details including the ability to; easily place orders on other customers’ accounts, add/retrieve card information, view saved addresses and view orders.

The target site was configured to return a 404 error page that contained a link to help pages regarding the Moonpig API and other potentially sensitive details including internal DNS setup. This presented further API calls to test, such as the ‘getCreditCardDetails’ call, which returned; card type, customer ID, expiry date, last four digits and the card owners name.

Further chilling news comes within the disclosure timeline for this vulnerability. Turns out it was initially reported to Moonpig on the 18th August 2013 and blamed on legacy code within the environment. Moonpig stated that they would ‘get right on’ fixing the issue, however further notification was sent in September 2014 when the issue had yet to be resolved.

Moonpig finally took the API servers offline on the 6th January 2015, over a year after the initial report of the vulnerability, and sent out a less than assuring tweet, stating that ‘all password and payment information was and always had been safe’.

moonpig tweetWhich has been less than happily received by members of the public, several variations of ‘not quite true’ were uttered in reply.

This once again displays the criticality of ensuring that security is at the forefront of your development practices, both within the development life cycle and as a stage in and of itself. This particular vulnerability is clearly a breach of the Data Protection Act in the UK, which may levy a harsh fine on Moonpig that could be avoided with proper penetration testing, and probably cost decidedly less than the possible fine.

Security processes should be in place within any environment so that any detail of security vulnerabilities are addressed, as detailed above the initial report was submitted 18 months ago, only yesterday was action taken to mitigate the risk present.

The final message of this is simple: if a vulnerability is brought to your attention, do not simply ignore it, it could come back to bite you.

[1] http://www.ifc0nfig.com/moonpig-vulnerability/


Written by
Emma McCall
Security Consultant
Corsaire

strategy-114-passwords-pop_757At the beginning of October, Adobe reported a data breach that affected around 3 million customers [1]. In the following weeks, the number rose significantly, but this was just the tip of the iceberg. At the beginning of November a huge dump of the data was published online, containing an eye watering 150 million entries.

Various organizations, individuals and companies have analysed this data and have reached the same conclusions: firstly, Adobe’s choice of encryption was extremely poor and secondly, the passwords used by the users were shocking. See the original research by Jeremi Gosney[2], and an excellent article by Paul Ducklin for more information[3].

While most researchers were focusing on cracking the encryption key or criticising Adobe for the poor encryption selection, Corsaire initially did further analysis, focusing on extracting information to help our clients understand the implications of the leak and the lessons that can be learnt from this leak.. We have now decided to publish this advice more widely in the infosec community.

1.1     Weak Password Choice

Looking at Jeremi Gosney’s top 100 list, it is obvious that users are using very weak and simple passwords. While this is no real surprise, the worrying aspect is that many of these weak passwords are associated with corporate email addresses. For example, one global security company is using the generic password ‘123456’ for the account with the email address format of company@company.com

72358235-|–|-company@company.com-|-EQ7fIpT7i/Q=-|-|–

1.2     Password Reuse

Examination of the data reveals users are reusing the same password across multiple accounts, both corporate and personal. For example:

67436532-|–|-jbloggs@company.co.uk-|-VdcYhakfnPioxG6CatHBw==-|-your wife|–

a2342312-|–|-purchasing@company.co.uk-|- VdcYhakfnPioxG6CatHBw==-|-wife|–

72349517-|–|-jbloggs@hotmail.co.uk-|- VdcYhakfnPioxG6CatHBw==-|-wife|–

1.3     Related Accounts

Another piece of information that can be obtained from the reuse of passwords is the ability to link related accounts. In the example below you can track the employment history of J. Bloggs based on his password reuse.

63745506-|–|-jbloggs@acmebank.com-|-nSFKSJFaKERjfsxG6CatHBw==-|-|–

32581259-|–|-joe.bloggs@newcompany.co.uk-|-nSFKSJFaKERjfsxG6CatHBw==-|-|–

23552666-|–|-j.bloggs@getfit.com -|-nSFKSJFaKERjfsxG6CatHBw==-|-|–

19457125-|–|-jbloggs@oldbank.com-|-nSFKSJFaKERjfsxG6CatHBw==-|-|–

Of course, this will be difficult to achieve if the user has chosen a common password.

1.4     Password Hints

As the encryption key is still not publically known, the encrypted passwords cannot be reversed to yield the plaintext password. Unfortunately, the presence of unencrypted password hints supplied by the users allows us to make a very confident guess of the password. A single hint is often not enough information to allow a confident guess, but 10 or more hints for the same password makes the process considerably easier.

In the example below, the encrypted password is:

rI2iugf8+lPioxG6CatHBw==

This is used in 25 different accounts. The associated password hints are:

Favourite element

tl201

Cardiac

Tl u/c

The usual metal

Tl

The rock

201

Seeing all these hints together allows us to make an educated guess that the password is probably ‘Thallium’.

1.5     Recommendations

The main points to take on board from this data leak, (after you have reset all your Adobe account passwords), is that users are the weakest security link in your company. While it is easy to implement and enforce a password policy within the internal corporate environment (via group policies, for example), it’s a very different situation online. You have no control over any particular individuals’ password strength if the online service/site does not enforce it.

This is where user education is vital. Educating your employees in password management best practices is a must and this should be done on a regular basis. Companies must ensure all users not only know and understand the current password policy, but the implications of using weak passwords or reusing passwords between corporate and personal accounts, especially online. In addition to education, providing your users with the ability to generate suitable passwords and store them securely will help (for example, unique password generators and password safe software).

If this has made you nervous and you would like us to examine the leaked data for any accounts related to your company, just get in touch!

Artwork by Michael Gillette

Written by
Sam FrameSamantha Fielden
Head of Client Management
Corsaire