Message-ID: <34476.129.35.231.17.1188204918.squirrel@129.35.231.17>
Date: Mon, 27 Aug 2007 10:55:18 +0200 (CEST)
From: "Alexander Klink" <a.klink@...ops.de>
To: full-disclosure@...ts.grok.org.uk
Subject: Stampit Web - DoS (CVE-2007-3871)

============================================
||| Security Advisory AKLINK-SA-2007-003 |||
||| CVE-2007-3871 (CVE candidate)        |||
============================================

Stampit Web - Denial of Service
===============================

Date released: 27.08.2007
Date reported: 17.07.2007
$Revision: 1.1 $

by Alexander Klink
   Cynops GmbH
   a.klink@...ops.de
   https://www.cynops.de/advisories/CVE-2007-3871.txt
   (S/MIME signed: https://www.cynops.de/advisories/CVE-2007-3871-signed.txt)
   https://www.klink.name/security/aklink-sa-2007-003-stampit-web-dos.txt
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3871

Vendor: Deutsche Post IT Solutions / GFT Technologies AG
Product: Stampit Web
Website: http://www.stampit.de
Vulnerability: Denial of Service (design problem)
Class: remote
Status: patched
Severity: moderate (DoS potentially affecting tens of thousands of customers)
Releases known to be affected: ??? (version numbers are classified, cf.
below)
Releases known NOT to be affected: ??? (releases after 2007/08/27)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Background:

Stampit Web is an internet stamping application created by Deutsche Post
IT Solutions and GFT Technologies AG. Users can buy stamps online and
download PDFs which contain a 2D barcode as the actual stamp.
Stampit has over 120.000 customers in Germany and is also used in
the UK ("SmartStamp"), Switzerland ("WebStamp").
Deutsche Post offers the service as an application service provider
or the software for companies who want their own infrastructure.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Overview:

Before printing the downloaded stamp, the PDF file verifies - using
Javascript and a SOAP request - that the stamp has not been printed yet
(apparently, this is a security-through-obscurity feature, as the SOAP
server can easily be faked). Once the request has been sent to the server,
the stamp is marked as printed and can no longer be printed easily.
The vulnerability results from the design decision to use serial numbers
as the identifier for the stamp in the SOAP request instead of random
IDs. An attacker can thus send requests for all stamps currently being
downloaded and thus outrun the customer.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Technical details:

A network dump reveals the following communication between the PDF
and stampit.deutschepost.de:

> POST /policyservice-dp/services/PolicyWS HTTP/1.1
> User-Agent: Mozilla/3.0 (compatible; Spider 1.0; Windows)
> Content-Type: text/xml; charset=utf-8
> Accept: */*
> Soapaction: ""
> Content-Length: 376
> Connection: close
> Host: stampit.deutschepost.de
> <?xml version="1.0" encoding="UTF-8"?>
> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="
> http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soa
> p/encoding" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>    <soap:Body>
>       <impl:in0 xmlns:impl="urn:PolicyWS">$id</impl:in0>
>    </soap:Body>
> </soap:Envelope>

< HTTP/1.1 200 OK
< Date: Tue, 10 Jul 2007 20:55:04 GMT
< Server: Apache/2
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/xml; charset=utf-8
< Content-Language: de
<
< 148
< <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope
xmlns:soapenv="http://sc
< hemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" x
<
mlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><printConfirm
< Return
xmlns="urn:PolicyWS">$boolean</printConfirmReturn></soapenv:Body></soapenv:E
< nvelope>
<
< 0

The parts marked as '$id' and '$boolean' are the locations of the stamp
ID as well as the boolean result ('true' meaning that the PDF has not yet
been printed) of the SOAP request. Note that the SOAP request is sent
unauthenticated and can be sent from a different IP than the one which
was used in downloading the PDF.

Watching IDs over time gives us the following list:

28.06.2007, 20:19:35 - 24404625
10.07.2007, 20:55:04 - 27560610
11.07.2007, 23:47:59 - 27910511
11.07.2007, 23:48:31 - 27910724

This shows that the stamps are monotonically increasing. Even if not
every number is used (~ 400 stamps/minute during nighttime sounds a bit
high), it is easy to guess the currently used IDs and send SOAP requests
for them. If those SOAP request reach the server earlier than the user's
request while opening the PDF, the user is denied from printing the stamp
he has already paid for. Note that one even does not need to know a current
stamp ID (although it can be bought for a mere 0.45 EUR), but the starting
point can be easily found via binary search, as the SOAP server replies
which stamps it has already seen.

Conclusion: using only as little as about 10 HTTP requests per second,
it is possible to disrupt the service completely and create a number of
angry customers that have paid for a service but not received it.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Communication:

* 18.07.2007: Contacted Deutsche Post and GFT via (social) networking
              (no security contact whatsoever on their websites)
* 18.07.2007: Received acknowledgement, developers and management are
              evaluating the problem
* 20.07.2007: Deutsche Post replies: the risk is already known from an
              internal security analysis, the problem will be fixed in
              the next release, asks for deferral of advisory release
              until August 27th if a release is at all necessary
* 24.07.2007: Contacted Deutsche Post to ask for some details (which
              products talk to the SOAP server, are the IDs just $i++,
              version numbers affected/not affected)
* 24.07.2007: Deutsche Post replies: all of the above is classified
              information (including the version numbers!) and can thus
              not be communicated and again states that they would like
              it best if no advisory is released

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Solution:

Use (pseudo-)random identifiers for the stamps. As a temporary workaround,
allowing the SOAP request only from the IP from which the PDF was
downloaded seems feasible (but of course creates some usability issues
for customers who relied on the PDF to be distributable to another machine).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Credits:

Alexander Klink, Cynops GmbH (discovery)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists