Exploit the possiblities

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

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

January 2018

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close