26 June 2015

Vulnerabilities

Posts relating to the category tag "vulnerabilities" are listed below.

07 January 2015

Moonpig Website Vulnerability, Incident and Breaches

Personalised greetings card service Moonpig was all over the popular news yesterday.

Partial screen of the Moonpig customer support page that states 'A MESSAGE TO OUR CUSTOMERS: You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.'

Paul Price found an exploitable weakness in Moonpig's public API and contacted them in August 2013, and again a year later. Eventually he gave up and published details on Monday.

Following much Twitter activity, yesterday Moonpig tweeted:

We are aware of claims re customer data and can confirm that all password and payment information is and has always been safe.

Interesting spin, since the vulnerability relates to other personal data — passwords or payment card holder data. Shortly afterwards, Moonpig tweeted:

As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations: http://www.moonpig.com/uk/Information/Press/

Moonpig also added the following message to their customer support page:

A MESSAGE TO OUR CUSTOMERS: You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.

Although Moonpig has not responded to the core issue (personal information), the published details appear to indicate:

  • Breach of principle 7 of the Data Protection Act
  • Breach of the Payment Card Industry Data Security Standard (PCI DSS)
  • A disregard for customers' data when the company has been aware of the problem for so long, and it continued to collect and process personal data through the period.

PCI DSS is only relevant here if the system components for api.moonpig.com are within the PCI environment. There is no need for a cardholder data breach for there to be a breach of compliance with PCI DSS. The main www.moonpig.com systems are definitely within scope since payment cardholder data is collected on forms generated by the website and the data is sent back to the same Moonpig website.

Nevertheless, by passing through the shopping basket and check out, other application security and privacy concerns are evident such as system information leakage, sending personal data over unencrypted channels, and third-party code on checkout pages.

The API issue and the other public issues on the web site do not seem to even meet the baseline security controls published for years by OWASP.

The help page about Payment and Personal Details Security states:

Security is an important priority for us and we are committed to protecting your privacy. We are registered as required under the Data Protection Act 1998 (Reg. Z4843659) and we use the most up-to-date technology available to protect your personal details. To avoid the risk of computer fraud, your credit card number is not stored in our system at any point in the payment process. Please see our privacy and security policy here.

That is clearly not true and might therefore be a breach of the Advertising Standards Authority Online Remit. The above also hints that somehow payment cardholder data is safe because it "is not stored". That's good, but it is not the same as saying it is not processed by Moonpig systems at all, which is likely to be misleading to some consumers. The terms and conditions say very little about protecting personal data - except from "in transit", and as we know that is not true for all parts of the web site that collect or display personal data.

If that is not enough for Moonpig, if the API vulnerability also affects United States customers, we will see the US Federal Trade Commission get involved. That body has been very strict in recent enforcement actions for online privacy failings. Affected US readers can submit complaints to the FTC online.

Posted on: 07 January 2015 at 12:55 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

10 December 2014

Some Other Security Games

If you're not into card and board games like Cornucopia security requirements or Snakes and Ladders risks and controls, why not try a couple of new online hacking games?

Screenshot from the Game of Hacks

Try these:

  • HACKvent 2014 is an online advent calendar with a difference. There are 24 challenges - one each day - which started on 1st December (sorry this is a bit late). All the challenges are available until 31st December, and additional points can be earned for writing up detailed solutions.
  • Game of Hacks tests your application hacking skills as an individual or against someone you know, with beginner, intermediate and advanced skill levels.

And back to the physical games, Adam Shostack, inventor of the Microsoft Elevation of Privilege threat modelling card game, edited the OWASP Cornucopia wiki page to add a link to a list of tabletop security games and related resources he maintains. I've ordered a couple of those for the break.

Good luck.

Posted on: 10 December 2014 at 18:48 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

09 December 2014

Application Security At Scale and At Speed

Contrast Security has published a new guide about their ideas about building application security into development processes that are reproducible and can be automated as much as possible.

The title page from Contrast Security's 'Continuous Application Security Handbook'

The authors call this continuous application security (CAS) and unlike traditional approaches, applies continuous real-time security verification. Their Continuous Application Security Handbook describes eight steps to implement CAS. I am interested in this approach, but particularly because it touches on some aspects of application-specific intrusion detection (see my favourite OWASP project AppSensor of which I am a co-project leader). The eight steps are summarised as:

  1. Instrument everything
  2. Make security visible
  3. Take control of security
  4. Implement strong defenses
  5. Know your enemy
  6. Hack yourself
  7. Expect failure
  8. Think security.

In the seventh step "expect failure", the handbooks says "[this] means that you are prepared for a successful attack, are monitoring for attacks, and have captured enough information to make a thoughtful response possible". This includes attack detection and incident response and explicitly recommends AppSensor-like behaviour "applications can and should detect their own attacks" and "attempts to detect application layer intrusions from the outside, typically in some kind of perimeter device, are doomed to failure". Bravo!

In contrast, the first step "instrument everything" describes a different type of application instrumentation. The handbook recommends "sensors run on a continuous basis, verifying both positive and negative security aspects of software" and "positive sensors model correct behavior of an application, whereas negative sensors model vulnerable behavior". In this regard, the process of instrumenting an application for CAS has some similarities with the considerations for adding detection points in AppSensor.

However, AppSensor detection points are designed to log malicious (user) behaviour in order to identify an attack, rather than either correct (development) behaviour or vulnerable (development) behaviour. CAS sounds orthogonal to AppSensor in that it assists the prevention of vulnerabilities, whereas AppSensor helps detect malicious intent before an attacker can identify any vulnerabilities present. And the CAS handbook says "the investment necessary to build and deploy many sensors is often minimal, similar to the effort required to perform a single penetration test for that issue" and "some complex security defenses may require more complex sensors" — rather like AppSensor detection points then too.

Please read the concise 26-page document and consider the ideas yourselves. Registration is required to download the document. See also the presentation AppSec at DevOps Speed and Portfolio Scale and Introducing Continuous Application Security by Jeff Williams at AppSec USA 2013 and 2014 respectively.

Posted on: 09 December 2014 at 07:53 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

05 December 2014

The Problems with Security Badges, Seals and Marks

A paper presented at this year's Association for Computing Machinery (ACM) Conference on Computer and Communications Security discusses why security-related third-party seals are poor indicators of site security, and how in some cases can actually assist attackers to compromise the web sites.

Partial view of the content in the paper 'Clubbing Seals: Exploring the Ecosystem of Third-party Security Seals'

Problems with one of the privacy seal providers have been in the news recently, and the paper Clubbing Seals: Exploring the Ecosystem of Third-party Security Seals assesses the effect on a web site's security by including a security seal from service providers Norton Secured, McAfee Secure, Trust-Guard, SecurityMetrics, WebsiteProtection (provided by GoDaddy), BeyondSecurity, Scan Verify, Qualys, HackerProof, and TinfoilSecurity.

The paper's authors Tom Van Goethem, Frank Piessens, Wouter Joosen and Nick Nikiforakis examined the guarantees offered by these schemes, and the realities. Their findings were:

  • There is a lack of thoroughness, meaning insecure websites being certified as secure
  • Malware hosted on a certified web site can trivially evade detection
  • Some attacks can be facilitated by the seal scheme
  • Phishing attacks can be aided by the use of seals
  • The seals can be used to help attackers find vulnerable web sites.

The message is to concentrate on building and operating secure web sites, rather than using a seal to create the illusion of security. Application security through the software development life cycle (SDLC).

Posted on: 05 December 2014 at 08:32 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

28 November 2014

Game On at OWASP Cambridge and London

Next week I will be attending two free United Kingdom OWASP events, and providing a full talk at one of them.

Part of the OWASP Snakes and Ladders game board

Cambridge

On Tuesday 2nd December, I will speak for the first time at OWASP Cambridge about OWASP Cornucopia, the ecommerce website security requirement card game. Jerome Smith will present a second talk about a SSL Checklist for Pentesters.

Also at the event in Cambridge I will briefly mention the somewhat less serious application security awareness board game OWASP Snakes and Ladders and will be handing out free copies to everyone attending, kindly paid for by the OWASP Cambridge chapter. We will have time after the presentations to play both Cornucopia and Snakes and Ladders. On the subject of Snakes and Ladders, this week volunteers Yongliang He, Cédric Messeguer, Riotaro Okada and Ivy Zhang have generously translated the game for web applications into Chinese, French and Japanese.

Please register in advance for the free event in Cambridge The meeting will be held in the Lord Ashcroft Building, Room LAB003; 17:00 for a prompt start at 17:30 hrs.

London

On Thursday 4th December, OWASP London is holding its final event of the year in Skype's offices at 2 Waterhouse Square, 140 Holborn, London, EC1N 2ST, 18:00 for 18:30 hrs start. Christian Martorella will be talking about Offensive Open-Source Intelligence (OSINT) — the process, techniques and how attackers are using it to prepare their cyber attacks. Afterwards project leader Matteo Meucci will speak about the new OWASP Testing Guide v4.

Then, as in Cambridge, I will mention OWASP Snakes and Ladders, with printed copies available for everyone, but this time paid for by the London chapter.

Please remember to register for OWASP London on Thursday 4th December.

Elsewhere

There are numerous other UK OWASP chapters — join their mailing lists to be informed of future meetings.

Seeking a bigger application security event? In January OWASP London will be organising a cyber security week, and AppSec EU 2015 is being held in Amsterdam next May. The call for research, papers and trainers for the latter are now open.

Posted on: 28 November 2014 at 07:55 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

07 November 2014

75,000 GBP Fine For SQL Injection From ICO But With 90% Discount

Lancaster-based apartment booking company Worldview Limited has been fined under the Data Protection Act for allowing unauthorised access to customers' details. The company operates under two UK brands, Citybase Apartments and Central London Apartments.

Although customers' payment details had been encrypted, the means to decrypt the information - known as the decryption key - was stored with the data.

The Information Commissioner's Office (ICO) press release states that a SQL injection vulnerability that existed for 3 years was the root cause, so this might imply the the decryption key was either stored in the database or the database could be used to read the key from elsewhere, such as the file system. The information taken included 3,814 payment card details; this mentions that both primary account numbers (PANs) and three digit security codes were accessed, which is even more interesting. The terms and conditions (Citybase, Central London) state:

Your payment card details will be securely held for the purpose of processing the booking until the day of check in. On the day of check-in, the credit card details are removed from our systems.

That's the travel industry problem of stored card data.

Apparently the fine would have been £75,000 but this may have put the company out of business. However, I suspect the fact that Worldview Limited will also be paying forensic investigation charges, card re-issue fees, card monitoring fees and fines relating to their PCI DSS contractual obligations will also have been taken into account by the ICO. However, £7,500 is a lot less than Worldview should be spending to ensure their customer data is secure. The fine is reduced further to £6,000 if payment is made by 1st December 2014.

The monetary penalty notice is available on the ICO web site.

The two "site security" pages on both web sites (Citybase, Central London) put a lot of faith in the use of "industry standard Secure Socket Layer (SSL) encryption technology" only:

When you submit your card details the information is encrypted (scrambled) so that it can only be read by the secure server, making the transaction as secure as possible.

When Lush Cosmetics had an ecommerce incident in 2010-11 with a similar number of cards and other personal data compromised, there was no fine — just an undertaking (and of course the PCI DSS costs). I suspect this stronger response from the ICO reflects its view that SQL injection is a basic fault that is below any acceptable level of security.

Update 7th November 2014: Link to monetary penalty notice and details of early payment discount added.

Posted on: 07 November 2014 at 08:59 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

06 November 2014

OWASP Snakes and Ladders

In a month's time we will probably be in full office party season. I have been preparing something fun to share and use, that is an awareness document for application security risks and controls.

OWASP Snakes and Ladders Mobile Apps

Snakes and Ladders is a popular board game, with ancient provenance imported into Great Britain from Asia by the 19th century. The original game showed the effects of good and evil, or virtues and vices. In this OWASP version, the virtuous behaviours (ladders) are secure coding practices and the vices (snakes) are application security risks. I have created two versions so far:

I created the game to use as an ice-breaker in application security training, but it potentially has wider appeal simply as a promotional hand-out, and maybe also more usefully as learning materials for younger coders. To cover all of that, I use the phrase "OWASP Snakes and Ladders is meant to be used by software programmers, big and small".

OWASP Snakes and Ladders Web Applications

The game might be a useful transition from learning about the OWASP Top Ten Risks and before moving into the Top Ten Proactive Controls in a PCI DSS developer training session for example.

Snakes and Ladders Web Applications is available in German and Spanish, as well as in (British) English. Translations to Chinese, Dutch and Japanese are also in progress. The OWASP volunteers who are generously translating the text and performing proof reading are:

  • Manuel Lopez Arredondo
  • Tobias Gondrom
  • Martin Haslinger
  • Riotaro Okada
  • Ferdinand Vroom
  • Ivy Zhang

Print-ready PDFs have been published - these are poster sized A2 (international world-wide paper sizes). But the original files are Adobe Illustrator, so these are also available for anyone to use and improve upon. OWASP Snakes and Ladders is free to use. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar licence.

Just print out the sheet as large as you can make them. It is better to play using a real die and counters (markers), but you can cut out and make these from the paper sheet itself if you have scissor and glue skills.

You can also follow two mock games on Twitter which upload a position image every hour:

Please enjoy and share.

Further information, and all the PDFs and source files, are available on the Snakes and Ladders project website. Please keep in touch by joining the project mailing list.

Posted on: 06 November 2014 at 08:31 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

04 November 2014

Payment Checkout Flaws and Bugs

The announcement last week by researchers from Newcastle University about a problem with Visa's contactless cards reminded me to mention again commons issues with checkout and payment functions in web and mobile applications.

Photograph of customers in a household lighting stand during Clerkenwell Design Week 2014

The Visa fault relates to not enforcing the same limits on transactions when using foreign currencies. The paper is being presented this week at the 21st ACM Conference on Computer and Communications Security in Scottsdale, Arizona. While we hope we would not make similar mistakes ourselves, almost every web/mobile checkout/payment system I come across has some sort of problems.

I do not believe I have mentioned it previously, but if you are developing an online payment API, mobile or web payment application, you should read a paper from Microsoft Research issued in 2011. How to Shop for Free Online - Security Analysis of Cashier-as-a-Service Based Web Stores (presented at IEEE Symposium on Security & Privacy 2011 in Oakland, California) describes findings from research into the security of several web payment applications.

Many of these problems are data validation or authorisation issues, but can be labelled as "business logic flaws". My own checklist for reviewing payment application functionality is below:

  • Buy at arbitrary price
  • Buy at nil price
  • Buy without paying
  • Buy one at item at another item's price
  • Pay for one basket at another basket's price
  • Update the basket while paying for the original one
  • Voucher, gift card and discount enumeration or manipulation
  • Repeat order/payment
  • Missing "mandatory" steps
  • Refund after payment
  • Chargeback after payment
  • Pay customer instead of seller
  • Missing checks/enforcement of data validation/signing
  • Enumeration of accounts, customers, payment cards, baskets, orders, email addresses, phone numbers
  • Manipulation of out-of-band messages (e.g. emails, SMS, direct messaging)
  • Payment confirmation manipulation
  • Tax and currency conversion manipulation
  • Rate of use and floor limits
  • Staff/internal backdoors
  • Fraud opportunities
  • Test data/cards works/present
  • Third-party hosted content
  • Privacy contraventions
  • PCI DSS contraventions.

This does not describe every method, but I hope the list is of use to others anyway. Generic attacks (e.g. injection, path traversal, cross-site request forgery, man-in-the-middle, unpatched components) also crop up in ecommerce payment functions, like everywhere else.

Posted on: 04 November 2014 at 20:11 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

07 October 2014

OWASP Testing Guide v4

The OWASP Testing Guide team of volunteers has announced the publication of version 4 of the OWASP Testing Guide.

Partial view of the OWASP Testing Guide's contents showing the new formatting and typography

The creation of version 4 (PDF, HTML) lead by Andrew Muller and Matteo Meucci. The guide is the de-facto standard for performing web application penetration testing.

Following an initial overview, introduction and discussion of testing objectives, the testing guidance is structured in eleven main sections:

  • Information gathering
  • Configuration and deployment management testing
  • Identity management testing
  • Authentication testing
  • Authorization testing
  • Session management testing
  • Input validation testing
  • Testing for error handling
  • Testing for weak cryptography
  • Business logic testing
  • Client side testing.

The previous edition was a large step forward in the maturity of the testing guide, and this version 4 goes further. Congratulations to everyone involved.

If you are looking for what to test, and how to build a software security programme, see also these two other OWASP documents respectively:

All OWASP materials are free to download and use.

Posted on: 07 October 2014 at 18:00 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

16 September 2014

AppSensor 2x2x2

OWASP AppSensor co-project leader John Melton has published two further AppSensor v2 assets.

Screen capture of the AppSensor 2 web site showing the headings on the user guide section - instrument your application, test and deploy the system, monitor, and tweak as necessary

AppSensor defines how to implement application intrusion detection and automated response.

Website 2.0.0

John has designed, coded and written a new standalone website for AppSensor. It was published on Friday and includes a brief description of the concept, an overview, getting started information and a user guide for the reference implementation. In John's words, the objectives were to:

  • Explain the high level concept in a simple way and point people back to the project site and the book for more detail
  • Give developers a nice entry point to the project - modelled after other framework/library sites
  • Give us more flexibility in how we present the project (not just wiki format)
  • In the future, hoping to have live demos.

I think it succeeds on the first three of these, and I will help if I can with the final statement.

To provide feedback or to contribute, please use the project's general mailing list.

Code 2.0.0 beta

If the new website wasn't enough, John has also been putting in many hours of coding to finish developing the new standalone version AppSensor reference implementation. On Sunday he announced the beta release of version 2.0.0.

The reference implementation currently supports three execution modes:

  • REST web service
  • SOAP web service
  • Local (embedded Java).

John is hoping a final release can be arranged for October/November.

To provide feedback or to contribute, please use the project's code development mailing list.

2x2x2

So the AppSensor project now has a new guide, a new website, and will imminently have a final release of the version 2 code. I am thrilled. I will be highlighting this new code when I speak at the London API event tomorrow evening. If you are attending that, I will have some free printed copies of the AppSensor Guide with me — if you would like one, please ask me a question about AppSensor.

Posted on: 16 September 2014 at 07:58 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Vulnerabilities : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 54.147.0.174 on Friday, 28 August 2015 at 10:25 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk