Kagi Registration Module (lack of) security
I'm in the process of choosing an eCommerce partner for selling my future shareware. I have narrowed down to eSellerate and Kagi as they are widely adopted by Mac shareware developers. After reading their respecting obfuscated pricing policies, I decided to have a look at what they offer for integrating the purchasing process into the application.
Kagi offers the Kagi Registration Module (KRM) which is basically a library that provides an in-application one click purchase experience. Sounds pretty good. I start reading the KRM developer documentation and stumble on the Security section:
The ZonicKRM submits orders through an SSL connection for security, however pricing information is currently passed from the application to the ZonicKRM as an XML string.
If this data is not checksummed, or otherwise protected, a malicious user may be able to edit the XML string within an application's executable and submit an order with an invalid price.
In the long term, this attack will be denied by moving the responsibility for pricing information from the KRM library to the KRM server. When this process is complete, vendors will be able to override the pricing information in shipping copies of an application using their Kagi database entry.
WHAT THE FUCK ? The user is able to choose the price he wants to pay ? Can't be true, this part of the documentation must be outdated. Guess what... it's not, long term is long term!
Note that checksumming or protecting is pure bullshit as long as the price comes from the application and not Kagi's server.
I searched for the first shareware using KRM I found, opened it with an hex editor, did search and replace of the string 30.00 to 01.00 and I indeed successfully ordered the shareware for $1.
This is totally irresponsible from Kagi. I don't know how this registration scheme could have been designed this way in the first place. No sensible person can design an ordering system where the price is set by the client.
Please don't flame me, I'm a good guy. I contacted the $30 shareware author and offered to pay the remaining $29 I owe him. I should have searched a bit longer for a cheaper shareware. $1 + $29 is a bit expensive to demonstrate that KRM sucks ;-)
The Bottom Line
Don't use KRM as long as you can't set the price of your shareware on Kagi's server.
18 comments:
guess what? i found an email that Kagi has found your entry and that they are now monitoring all purchases... poor kagi... i think, as nobody would ever have thought, the policy has worked for so many years without flaw.
as i am a software author using kagi krm i am posting this anonymously. Anyways: whatever you do, without the benevolence of people you are getting nowhere. if they want to steal your app, they will go to a warez site or even if it is done perfectly as regards security, if they don't like it, they just won't buy it.
Yet, if people like it, they will pay.
I was offering freeware for over six years and got quite some "but i DO want to pay" requests.
in short: don't focus too much on the wrong spot.
also: macromedia and adobe have such a weird security policy and user support, that they are just last choice and only bought, when there is no alternative left.... what can be done without photoshop? it is hopeless. but if there was a second app as good and as compatible as that, i would goodbye them instantly and many, many other users as well.
We allow the KRM client to set the price of the product so that the product supplier can optionally provide discounts. We do have a back-end price check built into the KRM server so that if the supplier wants us to prevent a purchase from happening below a specified price, we can support that request. The ability for the supplier to set the price of their product within their application is a feature, not a bug.
I believe it would be fair to say that you see this feature as a huge security hole and because of it you would never use KRM. That is of course your opinion and your choice.
In the entire life of KRM, you are the first person to take advantage of this exploit. The only reason you were able to do so was because the product supplier compiled the KRM XML into their application as clear text. I would hazard a guess that almost all KRM users do the same thing. The reason why is that having a customer change the price that gets submitted is an annoyance, not a security risk. Here's why:
If someone is using their own credit card, and they change the price, they have committed theft and we know who they are, we have their credit card number. We can contact the issuing bank and report the theft and all sorts of bad things befall them. So there is no reason for someone to alter the price and defraud the supplier with their own credit card number.
If someone is using a stolen credit card, why would they change the price and draw attention to themselves? It makes no sense to alter the price because it increases the odds that their stolen card data will be noticed and deactivated sooner.
In neither scenario does it make sense to change the product price which is probably why no supplier has asked us to protect their price on the backend server and probably why this supplier didn't bother to encrypt the configuration XML. Even if someone was to encrypt the configuration XML, a determined person could figure out how to decrypt it, modify it, and re-encrypt it. There is no such thing as absolute security, there is just a tradeoff between cost to break some security and the value gained by breaking the security. In this situation, there is no value gained when the configuration XML is manually edited in the compiled application code.
As for security that does matter, the KRM client is very secure when it comes to collecting and transmitting the customer credit card information to the KRM server. The KRM code is provided to the supplier in it's compiled and signed state and the data transferred between the application and our servers passes via HTTPS. The credit card data has a different security value so consequently, KRM security of that data is much much greater. Could it be hacked, of course, with time all security can be broken. But the cost to gain the credit card data is much higher and the person who would be in the best position to do the most damage is the product supplier and they have lots to lose by posting a hacked application onto their servers to steal their customer's credit card data.
So yes, we absolutely paid attention to KRM security issues. We provided heavy protection for the stuff that needed it, and light protection for the stuff that suppliers wanted to be able to alter.
All that said, we are going to add code on the backend servers to set a minimum purchase price in an automated manner from the price specified in our database by the supplier so that other potential customers don't annoy our suppliers by editing their compiled code to buy a product for a dollar.
Kee Nethery, Kagi CEO
thank u r information
it very useful
u r blog Is very nice
Key Netherly is basically threatenig anyone who asks Kagi: "I want to buy app. X at price Y" and is charged price Y and sent the code by Kagi server.
If I ask a seller (here Kagi through its servers) "are you ok with selling me this 10$ widget for 1$" and he says OK, then fine, it is not theft.
I think that a developer using KRM would have a much stronger case by pointing out that Kagi sells his application for less that the price he set.
Nicolas Seriot
> We allow the KRM client to set the price of the product so that the product supplier can optionally provide discounts. We do have a back-end price check built into the KRM server so that if the supplier wants us to prevent a purchase from happening below a specified price, we can support that request. The ability for the supplier to set the price of their product within their application is a feature, not a bug.
As a customer, I like this feature a lot. In fact setting the price I want to pay is the best feature I've ever seen for a shareware :->
> I believe it would be fair to say that you see this feature as a huge security hole and because of it you would never use KRM. That is of course your opinion and your choice.
I wrote Don't use KRM as long as you can't set the price of your shareware on Kagi's server. It does not mean I would never use KRM, it does mean I'm not confident in a system where the customer can set the price he wants. In fact, I'd really like to use KRM for my own shareware because I think it's far superior to other solutions in term of user experience. The one window Purchase from Kagi where the user enters his personal and credit card information is very well designed compared to other purchase systems.
> In the entire life of KRM, you are the first person to take advantage of this exploit.
A few lines above, you talk about a feature, not a bug. Now you talk about an exploit. An exploit in computer security, according to wikipedia, is a piece of software, a chunk of data, or sequence of commands that take advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software [...]. Something is rather incoherent in your wording. Using the word exploit implies there is a bug, glitch or vulnerability.
Also, the fact that I'm the first person to talk about this scares me. Does it mean that shareware developers do not read the documentation ? Does it mean they read the documentation but do not understand the flaw ? Does it mean they do understand the flaw but they do not care ? Anyway I think it's worrying.
> The only reason you were able to do so was because the product supplier compiled the KRM XML into their application as clear text. I would hazard a guess that almost all KRM users do the same thing.
No, no, no, and no! This is wrong! I was able to do so because the KRM purchase system is flawed. You even explain why a few lines below: a determined person could figure out how to decrypt it, modify it, and re-encrypt it. And I'm quite a determined person ;-)
> The reason why is that having a customer change the price that gets submitted is an annoyance, not a security risk. Here's why:
If someone is using their own credit card, and they change the price, they have committed theft and we know who they are, we have their credit card number. We can contact the issuing bank and report the theft and all sorts of bad things befall them. So there is no reason for someone to alter the price and defraud the supplier with their own credit card number.
I'd like to read the message you will send to my bank. Dear bank, we sold a license code to Cédric Luthi for $1. The intended price was $30, but we nevertheless sold it for $1 because he changed the price. Can you please tell us where to find a security expert ? We heard banks hire security experts. Sorry, I can't resist to be somewhat ironic.
> If someone is using a stolen credit card, why would they change the price and draw attention to themselves? It makes no sense to alter the price because it increases the odds that their stolen card data will be noticed and deactivated sooner.
Agreed.
> In neither scenario does it make sense to change the product price which is probably why no supplier has asked us to protect their price on the backend server and probably why this supplier didn't bother to encrypt the configuration XML. Even if someone was to encrypt the configuration XML, a determined person could figure out how to decrypt it, modify it, and re-encrypt it. There is no such thing as absolute security, there is just a tradeoff between cost to break some security and the value gained by breaking the security. In this situation, there is no value gained when the configuration XML is manually edited in the compiled application code.
Talking about manually editing the compiled application code (data to be accurate), please imagine a new scenario: A malware scans for applications and identify those using KRM. It then searches for the configuration XML and automatically modifies the prices without the user consent. Now, the customer buys that shareware using the KRM he downloaded a few months ago for $2 honestly thinking the shareware costs $2. Can he be considered a thief ?
> As for security that does matter, the KRM client is very secure when it comes to collecting and transmitting the customer credit card information to the KRM server. The KRM code is provided to the supplier in it's compiled and signed state and the data transferred between the application and our servers passes via HTTPS. The credit card data has a different security value so consequently, KRM security of that data is much much greater. Could it be hacked, of course, with time all security can be broken. But the cost to gain the credit card data is much higher and the person who would be in the best position to do the most damage is the product supplier and they have lots to lose by posting a hacked application onto their servers to steal their customer's credit card data.
I have no concern with this part, transmitting the credit card information over https is standard for credit card transactions and it's fine.
> So yes, we absolutely paid attention to KRM security issues. We provided heavy protection for the stuff that needed it, and light protection for the stuff that suppliers wanted to be able to alter.
I think there is no such thing as light protection. The secure way to alter the price for suppliers is to provide coupon codes thus transferring responsibility of computing the final price on KRM server, period.
> All that said, we are going to add code on the backend servers to set a minimum purchase price in an automated manner from the price specified in our database by the supplier so that other potential customers don't annoy our suppliers by editing their compiled code to buy a product for a dollar.
I'm very happy to hear that. It seems I achieved my goal with this shock blog post. As I said, I'd really like to use KRM for my own shareware. Having responsibility of the final price on the server is a requirement for me, as it should be for any supplier.
> Kee Nethery is basically threatenig anyone who asks Kagi: "I want to buy app. X at price Y" and is charged price Y and sent the code by Kagi server.
No. The ability to set the price on a per customer basis is allowed by KRM. If the supplier has previously agreed to the price before the sale occurs, Kagi has no problem with the sale happening. It's when someone alters the price in the supplier's code and the supplier does not approve of the altered price prior to the transaction where there is a problem.
> If I ask a seller (here Kagi through its servers) "are you ok with selling me this 10$ widget for 1$" and he says OK, then fine, it is not theft.
No. Supplier sets an offer price in their software. You either agree to the price or not. Changing the price to whatever you wish is not a negotiation, it is a hack and it is not contractually valid.
>I wrote Don't use KRM as long as you can't set the price of your shareware on Kagi's server. It does not mean I would never use KRM, it does mean I'm not confident in a system where the customer can set the price he wants. In fact, I'd really like to use KRM for my own shareware because I think it's far superior to other solutions in term of user experience. The one window Purchase from Kagi where the user enters his personal and credit card information is very well designed compared to other purchase systems.
The solution several suppliers use is to store their product price on their server and to do a simple HTTP request for the current price, and to use that. They do not use the price embedded in their software, nor do they use the price on Kagi's servers.
>A few lines above, you talk about a feature, not a bug. Now you talk about an exploit. An exploit in computer security, according to wikipedia, is a piece of software, a chunk of data, or sequence of commands that take advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software [...]. Something is rather incoherent in your wording. Using the word exploit implies there is a bug, glitch or vulnerability.
Having a customer changing the price to something the supplier has not agreed to and receiving an unlock code is the exploit I was referring to. Allowing the supplier to alter the sale price based upon circumstances is the feature.
>Also, the fact that I'm the first person to talk about this scares me. Does it mean that shareware developers do not read the documentation ? Does it mean they read the documentation but do not understand the flaw ? Does it mean they do understand the flaw but they do not care ? Anyway I think it's worrying.
No you are not the first person to talk about this. This has been discussed previously, just not in a public forum. The ability to change the price is listed in the docs. You are the first person to actually alter someone else's product code and then to place a purchase using that altered software. Suppliers have done purchases of their own products with different prices to test the capability. You are the first to alter code that does not belong to you and to place an order with that altered code.
>No, no, no, and no! This is wrong! I was able to do so because the KRM purchase system is flawed. You even explain why a few lines below: a determined person could figure out how to decrypt it, modify it, and re-encrypt it. And I'm quite a determined person ;-)
Like I said earlier, all security is a trade-off between cost to acquire something, and the value once it is acquired. The specific supplier you used as an example, felt that the encrytion of the XML in his software was not worth the effort. Am guessing that his next version will encrypt the XML, it's simple to do. Others did encrypt the XML. Some pull the XML data from a server that they control. Each is a step up on security. KRM is not flawed. The supplier feeds it data and it is the storage of that data that made this possible. Had the supplier stored their XML in encrypted format, opening it with a text editor and searching for the price would not have worked for you.
> I'd like to read the message you will send to my bank. Dear bank, we sold a license code to Cédric Luthi for $1. The intended price was $30, but we nevertheless sold it for $1 because he changed the price. Can you please tell us where to find a security expert ? We heard banks hire security experts. Sorry, I can't resist to be somewhat ironic.
Actually we would probably say that you altered the code to cause our server to sell you the product for $1. Am pretty sure that in no country is "altering the code" considered a legal thing to do to get a product for less than the sale price.
> Talking about manually editing the compiled application code (data to be accurate), please imagine a new scenario: A malware scans for applications and identify those using KRM. It then searches for the configuration XML and automatically modifies the prices without the user consent. Now, the customer buys that shareware using the KRM he downloaded a few months ago for $2 honestly thinking the shareware costs $2. Can he be considered a thief ?
This specific scenario is why we have the ability to price check on the back end.
> I think there is no such thing as light protection. The secure way to alter the price for suppliers is to provide coupon codes thus transferring responsibility of computing the final price on KRM server, period.
Ah, but then someone could pass around coupons and achieve the same result :-)
> I'm very happy to hear that. It seems I achieved my goal with this shock blog post. As I said, I'd really like to use KRM for my own shareware. Having responsibility of the final price on the server is a requirement for me, as it should be for any supplier.
Actually the price enforcement on the server is and has been part of the existing system. You would be more than welcome to use it.
Kee Nethery
There is no need to hack Kagi KRM module,"customer" just have to buy product and then ask Kagi for refund. Every single, even the most idiotic reason will be accepted on behalf of "customer" and against supplier. Some "customers" do that all the time.
I sell software through Kagi for 5 years and I know what I am talking about. My advice to other software developers would be to avoid Kagi, to go somewhere else where reseller will give them chance to decide about refund and where reseller will stand up for suppliers rights and interests in cases of chargeback. This way they will spare weeks of work to transfer several KRM products to some other reseller.
"I'm in the process of choosing an eCommerce partner for selling my shareware. I have narrowed down to eSellerate and Kagi as they are widely adopted by Mac shareware developers."
>I am in a similar position but need an application embedded solution that is Windows compatible (inc. Vista). I can make Kagi initialize in Windows XP but not Vista.
Is Kagi MS Vista compatible?
What are the best choices for application embedded solutions for Windows?
If there really is a check on the back-end for a minimum price the developer of the shareware can control, there isn't really a problem here. I agree it's a feature, not a bug, the exploit referred to is changing the code of the executable (which is out of Kagi's control).
I'd have a hard time understanding why anyone would use this product again, based on the responses of the CEO - even if they do fix it.
Changing the XML isn't 'changing the code'. The XML is just the request - it would be the same as if the url was /purchase?price=15, and you changed it to ?price=1. This isn't changing any 'code', or anything on your servers - it's simply sending a new request to you, to buy product X for 1. Your 'code' then checks this requests, and responds with 'sure'.
Shoddy code, and in no way theft.
It breaks the basic tennent of financial app security, never EVER trust the client. Provide the feature on the server end. I can just imagine the response of the bank's security department, "your app does WHAT?!? How on earth did you get PCI compliant with THAT?!"
kee wrote:
"Ah, but then someone could pass around coupons and achieve the same result :-)"
No, they wouldn't achieve the same result, unless the developer created a coupon that would sell normally $30 software for only $1. This is unlikely, but if it did happen, it happened only because the developer intended it to.
I think it's wonderful that the CEO of Kagi, rather than accepting that their solution is inadequately architected, is defending this "security through obscurity" model as a feature.
Sorry, but when money changes hands, being able to alter the price is a MAJOR problem. I don't care what kind of functionality it affords the supplier; a properly architected solution could achieve the same without causing this "annoyance".
So, if I understand correctly, Kagi has a team of people in a "Fraud" department to work with banks to sort out this kind of thing? A well-written email to a bank will do nothing - my wife works in the fraud department for a major financial institution. Proving fraud is extremely difficult and time-consuming. Given this, I'm sure the Kagi has never actually gone through the process.
Even if Kagi would rather spend their money on a Fraud department rather than fixing this bug, it's still grossly irresponsible to expose an API that defaults to this insecure behavior. An API consumer should have to go out of their way to enable this feature so as to ensure that the API consumer actually understood the ramifications.
Bottom line: there's no excuse. I will go out of my way to warn all developers to stay away from Kagi simply because their CEO doesn't understand the fundamentals of security within a financial transaction.
This is a true WTF.
Kee Nethery has founded Kagi in 1994 and he still does not see the problem with letting CLIENT software change prices.
I wish Kagi was a bank *tears of joy* :)
Now he feels the heat so he was to re-assure us how secure the client is and how security through obscurity really works because of the good will of people.
Seriously, bugs happen. Bad architectures do exist. Fix them and get over them. Just DON'T BULLSHIT us with your spinmeister skills.
Oh yeah, what was the point of assisting the MacCrypto conference if you don't understand security basics ?
Changing prices to suit yourself is fraud, whichever way you look at it. It's highly illegal to hack the XML in the way suggested here, in exactly the same way that it's highly illegal to go into a shop that doesn't have an EPOS system and swap items' price tags around.
Agreed it's poor design that Kagi allows you to do this when it needn't, but the assertion that there's no case for criminal proceedings against somebody who exploits the system is just plain wrong.
I just keep wondering what would happen if you'd enter a negative number :-)
Post a Comment