============================================ ||| 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)