Forgot your password?
typodupeerror
Censorship Microsoft Security

Microsoft Tries To Censor Bing Vulnerability 275

Posted by kdawson
from the don't-shout-and-wave-it-about dept.
An anonymous reader writes "Microsoft's Bing search engine has a vulnerability with its cash-back promotion, which impacts both merchants and customers. In traditional Microsoft fashion, the company has responded to the author of the breaking Bing cash-back exploit with a cease & desist letter, rather than by fixing the underlying security problem. It is possible for a malicious user to create fake Bing cash-back requests, resulting in not only fake cash-back costs for the merchant, but also blocking legitimate customers from receiving their cash-back from Bing. The original post is currently available in Bing's cache, although perhaps not for long. But no worries, the author makes it clear that the exploit should be painfully obvious to anyone who reads the Bing cash-back SDK."
This discussion has been archived. No new comments can be posted.

Microsoft Tries To Censor Bing Vulnerability

Comments Filter:
  • Mirror (Score:5, Informative)

    by Rufus211 (221883) <`rufus-slashdot' `at' `hackish.org'> on Tuesday November 10, 2009 @03:43AM (#30043110) Homepage

    Ive never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Lets see how these transactions might have accidentally got credited to my account.

    First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here [microsoft.com]. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this:

    https://ssl.search.live.com/cashback/pixel/index? jftid=0&jfoid=<orderid>&jfmid=<merchantid> &m[0]=<itemid>&p[0]=<price>&q[0]=<quantity>

    This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. Im not going to explain exactly how to generate the fake requests so that they actually post, but its not complicated. Bing doesnt seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have cleared, and Im guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.

    Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I havent done enough work to say it with confidence, but a malicious user might be able to block another users legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order IDs (e.g. sequential), a malicious user can use up all the future order IDs, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.

    Based on what Ive found, I wouldn't implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, Ill demonstrate some other subtle but important reasons to avoid using Bing Cashback.

    It seems like people have still not learned to never trust anything from the user. This reminds me of some trivially exploitable web merchants years ago. The would store the entire shopping basket, including prices, in the user's cookies. User simply modifies their cookies so that everything costs $1 or $0.01 and they could order a dozen cpus / t-shirts / whatever for a few bucks.

  • Most entertaining... (Score:5, Informative)

    by netpixie (155816) on Tuesday November 10, 2009 @03:47AM (#30043130) Homepage

    is the line from the letter

    "cease and desist the posting in any location of the material and information contained in this post"

    Seeing as it is their SDK that contains the details of this "feature", are they going to send themselves a C&D and then pull the SDK?

  • by Anonymous Coward on Tuesday November 10, 2009 @03:58AM (#30043170)

    Just wait for it.
    -Barbra

  • Source of URL (Score:4, Informative)

    by pgn674 (995941) on Tuesday November 10, 2009 @04:12AM (#30043220) Homepage
    If anyone is quickly wondering exactly where he got the info to construct the request URL in his original post (like, how did he know about jftid, jfoid, and jfmid?), it looks like page 33 of the linked Integration Guide PDF [microsoft.com] gives the URL https://ssl.bing.com/cashback/javascripts/1x1tracking.js [bing.com]. That JavaScript file has info on constructing that URL.
  • mirrored post (Score:3, Informative)

    by lkcl (517947) <lkcl@lkcl.net> on Tuesday November 10, 2009 @04:59AM (#30043400) Homepage

    http://lkcl.net/reports/bing.censorship.attempt [lkcl.net] - additional mirrors will be added as i find them.

  • by Anonymous Coward on Tuesday November 10, 2009 @05:07AM (#30043428)

    like this you mean?

    Breaking Bing Cashback
    Posted November 4th, 2009 by Samir

    I've never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Let's see how these transactions might have "accidentally" got credited to my account.

    First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this:

    https://ssl.search.live.com/cashback/pixel/index [live.com]?
    jftid=0&jfoid=&jfmid=
    &m[0]=&p[0]=&q[0]=

    This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. I'm not going to explain exactly how to generate the fake requests so that they actually post, but it's not complicated. Bing doesn't seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have "cleared," and I'm guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.

    Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I haven't done enough work to say it with confidence, but a malicious user might be able to block another user's legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order ID's (e.g. sequential), a malicious user can "use up" all the future order ID's, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.

    Based on what I've found, I wouldn't implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, I'll demonstrate some other subtle but important reasons to avoid using Bing Cashback.

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Tuesday November 10, 2009 @06:15AM (#30043710)

    Say what you will about Microsoft's business practices, but incredibly smart people [microsoft.com] work there. The idea expressed by your comment and the ten million others just like it is a cop out: it's a lot easier to call Micro$oft stupid than to take a hard look at our society and thinking about why large software companies (and large companies in general) have strong economic incentives to produce shit, about why they're not accountable to society at large, and why they can accumulate so much power.

    Microsoft is hardly stupid: on the contrary, its managers are quite savvy, and are the reason Microsoft is where it is today. Other large software companies would do exactly the same things in the same position.

    The real reasons we're angry are political. Our antitrust enforcement is lax. Our politicians are corrupt. We don't hold our government responsible for passing laws that favor the very few over the very many, like the DMCA. Our income taxes aren't progressive enough. We're not willing to enforce open standards. We let anything under the sun be patented. We need to address the root causes of these problems.

    But thinking about all that is hard. It's easier to just say Microsoft sucks, isn't it?

  • Re:Solution (Score:3, Informative)

    by QuoteMstr (55051) <dan.colascione@gmail.com> on Tuesday November 10, 2009 @06:26AM (#30043746)

    Can you elaborate on that?

    Sure. A MAC actually can mean two things, depending on context: an algorithm or a value. I'm going to use "MAC" to mean the algorithm, and "authenticator" to refer to the output of the algorithm. YMMV.

    The MAC takes as input the message to be authenticated, M, and a key S. Let's say that M is information about the item to be purchased, and S is a password the merchant set up with Microsoft. Running the MAC on M and S produces A. The sender of the message sends both A and M to the recipient. In more concrete terms, the tracking pixel's URL includes both information about the purchased item (like it does now) and the output of the MAC algorithm.

    The recipient runs the MAC algorithm on the M' he receives (using the agreed-upon S), and compares its output, A' to the A it received along with the message. If A = A', M is authentic. If not, M is a forgery.

    A malicious user could alter the tracking pixel URL, sure, but because she doesn't know S, she can't generate an authenticator A that the server will accept. She can choose to either send A and M unaltered, or not send anything at all.

    One of the more popular MACs is called an HMAC, which stands for Hash MAC. Unsurprisingly, it's a MAC build out of a hash function. The Wikipedia article [wikipedia.org] provides details about how an HMAC is actually constructed. It's important to use that construction, because simpler approaches to building MACs out of hash functions (like just concatenating S and M) are vulnerable to various attacks.

  • Re:Solution (Score:3, Informative)

    by Rufus211 (221883) <`rufus-slashdot' `at' `hackish.org'> on Tuesday November 10, 2009 @07:10AM (#30043922) Homepage

    It's pretty clear that whoever designed this API didn't even take an passing glance at the security or reliability implications. There are 2 ways (from the linked slides) for a merchant to report cashback activity to MS:

    1) Tracking pixel: this gives instant update to the user, but is completely insecure and also fairly unreliable (image fails to load, cross site https issues, random network hickup, etc).

    2) FTP upload of a plain text list: yes really, plain old FTP. This is at least reliable but is only authenticated by a plain-text user/pass. The list does not have any signature for authentication.

    I'm not a web guy at all (I'm an ASIC hardware guy) and off the top of my head I can think of 2 real solutions:

    The right way: SOAP. Gives instant update to the user, should be trivial in any backend web language, is reliable, is trivial to encrypt (https), is trivial to authenticate (a simple shared secret would be enough).

    A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different). As an added bonus a cryptographic signature should be added to the list.

    The problem with simply adding a MAC to the existing tracking pixel is that it doesn't fix the reliability issue. Also the advantage of the current tracking pixel is that it's stupidly easy to implement. If you're going to load in some libraries to do the MAC calculation on the server, you might as well load in a SOAP library and do the transaction properly.

    It really boggles the mind that a bogus transaction could actually be paid out. That indicates there is absolutely no auditing or rationalization between what the e-tailer thinks should be paid out and what MS thinks should be paid out. Even something as stupid as end-of-month totals should flag that there are bogus transactions.

  • by Alex Belits (437) * on Tuesday November 10, 2009 @08:14AM (#30044204) Homepage

    Microsoft Research is not "people working for Microsoft", it's "people are paid by Microsoft not to work for Microsoft's competitors". Not a single meaningful Microsoft product or feature came from there.

  • by lorenlal (164133) on Tuesday November 10, 2009 @08:42AM (#30044370)
    Microsoft is working their Bing campaign hard. I'm seeing ads for it everywhere. I've got a feeling there are at least some folks who will try it out, and maybe even like it. Oh, and if you ever go to Microsoft.com and try searching for anything you're using Bing. There's a reasonable chance that you'll eventually accidentally use Bing.
  • by AvitarX (172628) <me@brandywinehund[ ].org ['red' in gap]> on Tuesday November 10, 2009 @09:09AM (#30044514) Journal

    I keep an IE window open at work for the sake of an additional gmail account.

    Sometimes I accidentally use its search box over Fire Fox's, and yuck, nobody will like it.

    The results are so haphazard, it feels like their parody of google is what actually drives Bing.

    I don't know how this late in the game a search engine can be so bad.

  • by abigsmurf (919188) on Tuesday November 10, 2009 @09:12AM (#30044544)
    Admitting a crime does not absolve you of it. In the first example, it's still technically a crime, it's just not worth anybodies time to report and prosecute it.

    This guy has been seriously stupid. Not only is it clearly fraud, he's also up for conspiracy to defraud charges for telling other people how to do this.
  • by IsThisWorking (883966) on Tuesday November 10, 2009 @09:33AM (#30044688)

    Security through obscurity [wikipedia.org] is not about relying on secrecy of data, but about relying on secrecy of the algorithm or implementation. Those two things are different.

    If you do not make the distinction between data/information secrecy and design/algorithm/protocol/implementation secrecy, then you do not understand what security is.

  • by 0100010001010011 (652467) on Tuesday November 10, 2009 @09:34AM (#30044692)

    CashBack? Last Christmas Live cashback was up to 30%. I milked the hell out of that for Christmas presents.

    Now it fluctuates between 5 and 10%, nothing big but it's not bad.

    As far as actually using it for its intended purpose, nah.

  • Re:Mirror (Score:2, Informative)

    by Boomerang Fish (205215) on Tuesday November 10, 2009 @10:31AM (#30045264) Homepage

    Ive never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Lets see how these transactions might have accidentally got credited to my account.

    Also the guy who posted this is an idiot for placing a $100,000 transaction which would result in a $2,000 payment, and then bragging about it. His two $1 transactions proved the vulnerability and the $0.06 payment generated is easily ignored. The $100k transaction with $2k payment is just flat out wire fraud asking for federal PMITA prison.

    Has anyone here actually read the words he has posted at the begining of his post? At face value it looks like he "discovered" this when he noticed he had an account balance for SOMETHING HE CLAIMS TO HAVE NEVER USED.

    But no, it's so much more fun for everyone here to ignore the words Ive never bought anything using Bing Cashback and Apparently, I placed... and call him an idiot for posted about committing a crime.

    --
    not wort it...

  • by realityimpaired (1668397) on Tuesday November 10, 2009 @10:36AM (#30045326)

    Wow, I didn't realize that there are people that still believe in that 'security through obscurity' nonsense.

    It's not nonsense, it's just silly to expect it to be your only line of defense. By all means use an obscure platform, as long as you have people who can maintain and support it, but don't use it as a substitute for some common sense, and for securing your system, keeping it properly maintained and updated, limiting points of entry, blocking remote root access, using non-standard, non-root usernames with very secure passwords for system maintenance/root tasks, etc..

    But security through obscurity does still offer an amount of extra security, and shouldn't be dismissed out of hand.

  • by FlyingBishop (1293238) on Tuesday November 10, 2009 @11:47AM (#30046266)

    No, but let's take a car analogy, as this is Slashdot:

    Say you leave your keys in your car, in plain view, and someone notices this, and goes into the conference center that you're at and informs several people that someone has left their keys in plain view out in the parking lot, and should deal with the situation. Soon everyone knows, and the conference management (Slashdot, we'll say) makes an official announcement.

    Now, to make it a little more interesting, it isn't your car, but you were driving, and you tell the owner of the car (also at the conference) not to worry about it, it will be fine. The owner does not agree, but cannot leave, and you refuse to remedy the situation.

    Now, there are three responsible parties here, should the car get stolen.
    1) The moron who left the keys in the car (Microsoft)
    2) The guy who went around describing the make, model, and location of the car (exploit publisher)
    3) Everyone at the conference. (The Internet)

    Now, Slashdot falls under #3, but why call out Slashdot to the exclusion of #2, or the internet at large? Slashdot is likely the first place many will hear of it, but if they hadn't published it that wouldn't have stopped anyone from reading and talking about the exploit writer's publicly available explanation.

    In short, citing two causes of something as primary causes when there are clearly other actors with notable roles is the very definition of placing blame.

  • Re:Mirror (Score:1, Informative)

    by Anonymous Coward on Tuesday November 10, 2009 @11:48AM (#30046282)

    I own a laundromat, and I have 2 change machines there that are quite old (but have had their firmware updated over time to read new bills). They do not look in the corners, they read the incredibly fine detail on the bill in certain areas (a strip of lines), and make sure they match known good parts.

  • by witherstaff (713820) on Tuesday November 10, 2009 @12:51PM (#30047316) Homepage
    There is a current case before the supreme court along this line. The argument is there is no constitutional right not to be framed. [npr.org] Oh and the Obama admin backs this stance, along with 28 states.

You scratch my tape, and I'll scratch yours.

Working...