the original cloud security

AKLINK-SA-2007-003.txt

AKLINK-SA-2007-003.txt
Posted Aug 27, 2007
Authored by Alexander Klink | Site cynops.de

Stampit Web suffers from a denial of service vulnerability.

tags | advisory, web, denial of service
advisories | CVE-2007-3871
MD5 | 4e202522846f0c7234d94246e0eb549a

AKLINK-SA-2007-003.txt

Change Mirror Download
============================================
||| 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@cynops.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)

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

July 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    2 Files
  • 2
    Jul 2nd
    3 Files
  • 3
    Jul 3rd
    15 Files
  • 4
    Jul 4th
    4 Files
  • 5
    Jul 5th
    15 Files
  • 6
    Jul 6th
    15 Files
  • 7
    Jul 7th
    10 Files
  • 8
    Jul 8th
    2 Files
  • 9
    Jul 9th
    10 Files
  • 10
    Jul 10th
    15 Files
  • 11
    Jul 11th
    15 Files
  • 12
    Jul 12th
    19 Files
  • 13
    Jul 13th
    16 Files
  • 14
    Jul 14th
    15 Files
  • 15
    Jul 15th
    3 Files
  • 16
    Jul 16th
    2 Files
  • 17
    Jul 17th
    8 Files
  • 18
    Jul 18th
    11 Files
  • 19
    Jul 19th
    15 Files
  • 20
    Jul 20th
    15 Files
  • 21
    Jul 21st
    15 Files
  • 22
    Jul 22nd
    7 Files
  • 23
    Jul 23rd
    2 Files
  • 24
    Jul 24th
    19 Files
  • 25
    Jul 25th
    28 Files
  • 26
    Jul 26th
    2 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close