Saturday, 24 May 2014

eBay's Weak Security Architecture

Well eBay are in the news due to their breach of 145 million users' account details. There are a few worrying things about this breach, beyond the breach itself, that point to architectural issues in eBay's security.

The first issue is that a spokeswoman (according to Reuters) claimed "that it used 'sophisticated', proprietary hashing and salting technology to protect the passwords." This sounds very much like security through obscurity, which doesn't work. So, either they are using a proprietary implementation of a publicly known algorithm, or they have created their own. Both of these situations are doomed. As always, no one person can think of all the attacks on an algorithm, which is why we have public scrutiny. Even the best cryptographers in the world can't create new algorithms with acceptable levels of security every time. Do eBay have the best cryptographers in the world working for them? I don't believe so, but I could be wrong.

Also, if their argument is that hackers don't know the algorithm so can't attack it, then I'm fairly sure they're wrong there too. Even if the algorithm was secure enough to stand up to analysis of the hashes only, as hackers have eBay staff passwords perhaps they also have access to the code! If, on the other hand, they have their own implementation of a public algorithm I have to question why? Many examples are available of implementations that have gone wrong and introduced vulnerabilities, e.g. Heartbleed in OpenSSL. Do they think they know better?

The second issue is that they don't seem to encrypt Personally Identifiable Information (PII). This is obviously an issue if a breach should occur, but, admittedly, doesn't solve all problems as vulnerabilities in the web application could still expose the data. However, it is likely to have helped in this situation.

Finally, and most importantly, how did gaining access to eBay staff accounts give attackers access to the data? Database administrators shouldn't have access to read the data in the databases they manage. Why would they need it? Also, I would hope that there are VPNs between the corporate and production systems with 2-factor authentication. So how did they get in? Well, either eBay don't use this standard simple layer of protection, they leave their machines logged into the VPN for extended periods or they protect the VPN with the same password as their account.

Even if eBay do implement VPNs properly with 2-factor authentication, the production servers shouldn't have accounts on them that map to user accounts on the corporate network. Administrative accounts on production servers should have proper audited account control with single use passwords. Administrators should have to 'sign out' an account and be issued with a one-time password for it by the security group responsible for Identity and Access Management (IAM).

All this leads me to think that eBay have implemented a weak security architecture. 

Monday, 10 June 2013

Denial of Service (DoS) and Brute-Force Protection

Recently it has become clear to me that, although the terms Denial of Service (DoS), Distributed Denial of Service (DDoS) and Brute-Force are used by many, people don't really understand them. This has caused confusion and problems on more than one project, so I thought I would write my thoughts on their similarities, differences and protection mechanisms.

A Denial of Service is anything that happens (usually on purpose, but not necessarily) that takes a service off line or makes it unavailable to legitimate users. This could range from a hacker exploiting a vulnerability and taking the service off line, to someone digging up a cable in the road. However, a Denial of Service could also be triggered by legitimate use of a service without any 'vulnerabilities'. Consider a service that performs operations on large sets of data that take a few seconds to complete. If I put in multiple requests for this service then I could tie it up and make it unresponsive for several minutes. Similarly, consider a website that has a page with a large video or flash animation on it. Again, relatively few requests for this resource could make the server slow and unresponsive. DoS is not just about hackers finding vulnerabilities.

Distributed Denial of Service, on the other hand, is a deliberate attempt by someone to deny service by performing large numbers of requests from a large number of hosts at once. Whilst it is relatively easy to spot a single host attempting a large number of requests and block them, it can be hard to pick up on many hosts making few requests and harder to block them. There are many solutions to combat DDoS by caching content and providing high bandwidth to large numbers of nodes, such as those available from the likes of Akamai. However, logic flaws or lengthy processing in the application can only really be fixed by the application developers.

Brute-Force, on the other hand, has nothing to do with DoS or making a service slow or unavailable. I was amazed that people didn't know this! Brute-Force is all about submitting a, usually, large number of requests to a service to obtain information that was not intended by the developer. An example would be having no account lockout after several incorrect login attempts. It would then be possible to try a whole dictionary or even every character combination to eventually find the password for a user. This is an example of Brute-Force, but there are many others, such as finding database versions, telephone numbers, transactions, parcel delivery addresses, etc. This can only really be stopped with application logic.

Monday, 29 April 2013

The Disconnect between Security and Senior Management

There is often a fundamental disconnect between security professionals and senior management. As I have stated in a previous post about slips, mistakes and violations, if senior management don't 'buy in' to security then nor will the rest of the organisation and ultimately it will fail. Middle management want to be senior management and will model themselves on them, often seeing the breaking of rules as a mark of status. So, it is vital that senior management lead by example.

Unfortunately, it is often very hard to get senior management to 'buy in' to this concept and not have a 'them-and-us' attitude of there being those rules that apply to the rest of the organisation and those that apply to them. This is as much the fault of the security professionals as senior management though. Security professionals have spent so long saying "no" to everyone and stalwartly refusing to budge or see someone else's point of view that people have stopped listening and taking note. To be honest, rightly so.

If you want someone to change their point of view or come round to your way of thinking, by far the easiest way is to sell it to them as a positive thing that will be beneficial to them and 'bring them with you' rather than dictate. Saying "no" all the time is not positive and will ultimately fail as people will stop listening. Make it personal to them and put it in terms they understand. Relating security to risk and money will usually be more successful.

Wednesday, 19 December 2012

Pentests Don't Make You Secure

I was asked to provide details of the 'Penetration Testing Phase' for a particular project by someone who was putting together a Test Approach Document today. The categories I was asked to fill in were:
  • Objective of the phase
  • Responsibility & Authority
  • Dependencies, risks & assumptions
  • Entry & Exit criteria
When discussing what they really wanted it became clear that they didn't know what a penetration test was or why we do them. The questions and document were set up expecting a deliverable from the pentest itself. The report was being treated as the deliverable without any thought of why a report was being produced or how it will be used. It was a tick in the box - "We require a pentest to be able to go live, so if we've had the report we can tick that box and move on."

Pentesting is not an end in itself. Pentesting is a standard, finite snapshot of the security of a system, which, if taken in isolation as a goal, is fairly useless. Pentests don't make you secure. Performing a pentest and having a report with lots of pretty colours and charts saying that high and critical vulnerabilities exist is only any good if you then remediate or mitigate those vulnerabilities. You could pentest your system every month, but if you never change anything in the system, every report will be the same and you will be as much at risk as you were before you had the pentest done. Indeed, you are likely to get progressively worse results as new vulnerabilities are discovered all the time.

The test and report themselves don't do anything for security. A pentest is used by security professionals to inform and shape a project and decisions. The actions taken based on the findings from a pentest are what improve your security and help you identify the best use of finite resources or, at the very least, enable you to understand the risk. Do you need to perform a pentest? Absolutely you do in order to understand the threat landscape properly and identify vulnerabilities, but it's what you then do with that knowledge that is important and will make you more secure (or not).

Friday, 16 November 2012

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here.

Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts.

But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform to many of my recommendations, but I have yet to find one that, by default, conforms to them all.

Site Categorisation

There are several different categories of hosting and several different ways to categorise sites, with different requirements. However, in my opinion, sites should be categorised based on the information that they contain and the level of interaction allowed. Sites should then be logically and physically separated into their categories.

Sites can be categorised as brochure sites if they have static content or do not collect information. These sites can then further be categorised into public or private depending on whether the data that they contain is public or not. Sites within these categories may be co-hosted with other sites in the same category, but the two categories should be segregated.

Sites can be classed as data collection apps if they collect sensitive or personally identifiable information (PII) from the user. Sites within this category should be hosted on their own servers with no co-hosting and be segregated from all other sites. The data must be stored on separate segregated database servers that are secured and firewalled off.

Finally, any site with even more sensitive data on it or company secrets should be hosted internally if you have the expertise in house.

Hosted Environment

The following list is an example of the requirements for secure web hosting. It is not necessarily complete, but if you do not have the following then you may have issues in the future. All websites and web applications must:
  • be hosted on a dedicated environment - the hosting machine may be virtual or physical, but must not be shared with any 3rd parties. Multiple websites and applications from the same company may be hosted on the same machines according to the categories above
  • have DDoS protection in place
  • have AV running and configured properly on the server along with appropriate responses and reporting
  • be hosted behind a Web Application Firewall (WAF) to protect against common attacks, plus allow the ability to configure it for specific services
  • be hosted on security hardened Operating Systems (OS) and services to an agreed build standard
  • be subject to regular and timely patching of the OS and services
  • be subject to regular security testing and patching of any Content Management System (CMS) in a timely manner if used
  • be subject to active monitoring and logging by the provider for security breaches and reporting to/from the organisation
  • have formal incident management processes for both identifying and responding to incidents
  • not be co-hosted with additional public services beyond HTTP/HTTPS (e.g. no public FTP)
  • not allow DNS Zone Transfers
  • use proper public verified SSL certificates - with a preference for Extended Validation (EV) certificates
  • ensure that management services and ports are on different IP addresses and domain names preferably, but must not be available through the normal login or visible on the website
  • ensure that administrative interfaces and services are restricted to certain IP addresses at least, but make use of client-side certificates or two factor authentication (2FA) if possible
  • ensure staging servers are available for test and development, which must not be shared with live sites and should be securely wiped at the end of testing as soon as the site is deployed live
  • ensure staging and test environments are not available on the public Internet or, if there is no alternative, they must be devoid of branding and sensitive information in all ways and restricted as above
  • be built on a tiered architecture, or at least the database (DB) server must not sit on the same server as the web front end, must not be accessible from the Internet and must be securely segregated from the front end
  • use encrypted storage for all sensitive information, (e.g. passwords and sensitive information)

Hosting Services

It is up to the hosting provider and third party developers, but should be backed up by specific contractual clauses, to ensure that:
  • the site is backed up regularly off site in a secure location using encrypted media where the keys are stored separately from the media and able to be restored in a reasonable time frame with a suitable rotation and retention policy
  • hardware and media that has reached the end of its life is securely destroyed
  • all sites are made available for pentesting prior to going live and at regular intervals
  • all vulnerabilities considered of medium risk and above should be remediated prior to go-live
  • all sites are available for on-going regular automated Vulnerability Assessments
  • domain names, code and SSL certificates are registered to the company and not a third party
  • there are agreed processes for identifying approved personnel to authorise changes
  • change management processes that track all changes are in place along with rollback and test plans
  • capacity and bandwidth are actively managed and monitored
  • all management actions are accountable (unique accounts allocated to individuals)
  • all management should be through secure ingress from trusted locations
  • egress filtering should be in place to block all non-legitimate traffic

Sunday, 21 October 2012

Here come the Security Police

Security teams often attract antagonism from the business that they are supposed to serve, appearing as self-appointed policemen in a police state. This is unhelpful and not what we are or should be aiming for. Security departments should be providing a secure environment in which business users are free to do what they want. Obviously this environment will have boundaries, but they must be agreed with the business and not just imposed arbitrarily.

Take an example from children's play areas, children should be safe within the confines of the soft play area and not too much harm will come to them. They can run around and play whatever game they like as long as they stay within the boundaries. Children can't wear shoes in a soft play area as they may hurt another child, but this doesn't stop them from doing what they want as the play area has been engineered so that they don't need shoes to stop them from hurting their feet or getting wet and dirty.

The same principles can be applied to security. If we build a safe and secure environment that has everything that people need within it already then they are free to do what they want and need, and are far less likely to break the rules or circumvent security controls. The architecture has to be secure and services should be tailored to the business functions and not just imposed by the security teams. A good example is to provide a Choose Your Own device (CYO) offering to avoid the problems of Bring Your Own (BYO) or the restrictions of imposing a single device. It is possible to support a range of devices and then even offer a restricted service on some further devices, but allow the users choice.

In the end there will always be a certain amount of policing required, but if, as a security professional, you are spending most of your time in that role then your network, architecture and attitude are wrong.

Friday, 13 July 2012

Bank Card Phone Scam - new version of an old technique

There is a new take on an old phone scam currently hitting people. The old scam was to pretend to be the telephone company and phone someone saying that they are about to be cut-off if they don't pay a smallish amount by card over the phone immediately. If people don't believe them they are actually encouraged to hang-up and then try to make a call. When they hang-up and then pick the phone up again it is dead. How do they do this? Well it's actually very simple - the scammer doesn't hang-up, they just put their phone on mute. The call was never torn down.

So, what's the 'new take' on this scam? Well, they are now hitting bank and credit card customers. The scammers now pretend to be from the bank and start asking for card details, etc. If you get suspicious (or even sometimes prompted by the scammer themselves) you are encouraged to hang up and call them back on the telephone number shown on the back of your card. They then provide you with an extension number or a name to ask for.

When you hang up they do not, similar to before. However, this time they play the sound of the dialling tone to you until you start 'dialling' the number. All they have to do is wait for you to finish dialling the number then play the ringing tone to you. All the while they haven't hung up and you haven't dialled your bank at all. The scammers then 'answer' the phone and pass you to the person you were speaking to before. You now think you're speaking to your bank.

You did the right thing, but were still trapped. What can you do about this? My suggestion is to call back on a different line. Call your bank back on your mobile, not the landline you first received the call on.

Welcome to the RLR UK Blog

This blog is about network and information security issues primarily, but it does stray into other IT related fields, such as web development and anything else that we find interesting.

Tag Cloud

Twitter Updates

    follow me on Twitter

    Purewire Trust