I turn to you for advice.

I have uncovered a flaw in the 2checkout passback system (v2?) and have contacted 2checkout about it; we have exchanged words. Now, It's what seems like 5 days later and they are playing stupid with me (or not?) cause I have recieved answers for questions I didn't even ask, and wrong answers and then answers telling me old answers were false. What's a guy to do!?

I am not about to post this exploit anywhere public just yet, but I think 2checkout should actually listen to me and fix this, instead of just putting me off. I call them up and I get told to send a ticket. :mad:


Now, a quick rundown of this is, if the seller uses the passback system for a service like domains, you can place an order and not get billed, yet it looks to their passback system like it was a valid order.

I am not sure what is going to happen, I mean... I have contacted them via their ticket system that everyone leads me back to, and I haven't gotten a reply saying it will be fixed, or they acknowledge me.... just a few copy & paste responses.

What's a guy to do? I want to use their system, but I know a buyer can totally rip me off. It looks to me like 2checkout thinks I am a joke, cause I doubt they have even looked into it.

Do I exploit it and trip off some red flags so somebody will actually give a ****? I really think this is the wrong answer... get myself in the big house :D

But I may just have to leave them for another place; if they don't fix it.

Is there somewhere I can contact (NOT using a ticket system) a tech member via. a live phone number?

Like I say, I have submitted a ticket or 2, and one of the replies said to me (In my own kind of way) "Yes, this can be done. We could care less."

In the end its not 2checkout who is at a loss, it's the seller.

Any advice guys?

Wait, and if you feel unsecure using their system then don't use it.

Um, I guess that's an option.

Report it to visa. Every PSP should be AIS compliant and if the exploit is that bad you should report it to Visa.

I'm sure it would soon get fixed then...

It doesn't really have much to do with Visa... its more an issue between the 2checkout system & the users passback scripts.



But, just the same.... I guess it sort of has something to do with Visa? If they leave a hole this big open on the user front end I can hardly think about what other holes they have.

....so, how would one go about contacting Visa to report an insecure vendor who doesn't really want to do anything about it?


** On a side note, I still have an open ticket with them. What seems like 5 days now.

Matt,

No it does everything to do with Visa as it sounds like their product is NOT secure. Visa give PSP's a checklist they must follow and if you can compromise data then what other systems could be breached.

Visa are taking IT security strongly now and in Europe it will soon be the rules to have a security audit on your webservers to ensure data is secured.

Thanks

Gavin

A friend of mine does the audit checks. I will ask him when he logs into MSN..

Ok, well I guess that's my next stop. How & where do I go to contact them?

Let 74s3 make that initial contact. Getting someone over there that actually knows / listens, is very difficult. I tried to report a webmaster who was factoring for his clients & I just kept getting canned responses - most telling me to contact the processor (who I did not know) or the acquiring bank (which I did not know)

Well... they were quick to take my payment for the account, & to process cards.

Only thing I am a bit pissed off about is the fact I call to report a serious error and I get told to "make a ticket".

And the fact that I was told that other support tech answers were not true, well... bahh! Need I say more?

I'll wait and get in contact with Visa unless 2checkout fixes this.

hmm... they have a very slow response. I have submitted a question few days ago and still haven't heard from them.

Nybble,

Please contact me directly at the email address below. Give me a brief description of the issue, and I will have a tech email you back this afternoon.

I suppose I can do this; I hope it doesn't totally kill my relationship with you guys. I still want to use the service... once its a bit more secure.

I will send that email ASAP(later today).

ALL IS GOOD!

Happy happy joy joy!
5 days now; problem is fixed & solution put into place. Thank you 2checkout.

I guess this means you won't get getting an email from me... sorry. :D


** And of coure you know I am going to test this patch, but it looks rock solid.

Now the only exploit left lets a user give someone else money ^_^

But, I don't know why someone would even mess with that.... their money into someone elses account. Bah!

Maybe I'll bring it up just incase. :)


Thank you Tom for your offer, but I guess the ticket worked out :)

Now I guess the right thing for me to do would be to post this exploit (Not how to run it, just the exploit) so that everyone here who uses 2checkout can secure their setup.

Also, would anyone know who to contact to re-write teh 2checkout plugin for oscommerce? I am interested in helping out :)

Now, lets take this from the top:
The exploit allows an attacker to click buy (item or custom), add &demo=Y to the url (To turn this into a demo) and then enter demo stuff (Which noone at 2CO will ever see, cause I doubt they read over demo orders)

Now, the demo=Y is only the first part... you click order, keep going:

At the last page, there is a postback form that the user clicks to post data back to you (Still not wild about this idea.. I would rather the server contact me).. so now, the users just edits the html to change demo=Y into demo=N, and then they run it using a proxy so that they can fake the refer log.

To your passback system it looks like a real order. (This has been fixed)

Now, the smart thing 2checkout did was use md5.
md5 ( secret word + vendor number + order number + total )

Now the only problem with that was that it didn't contain the DEMO var, so.... it was a valid md5 of a REAL order.

I don't know if you follow me yet or not :)

Now, if it is a demo order it is this:
md5 ( secret word + vendor number + 1 + total )

So now, you should all go update your scripts to check for this "number 1" in the order number field of the MD5.





Now onto exploit #2.... the user can fake their payment ID.
Not sure if I want to bring it up, it would have to be a valid order & they would have to TRY to give another person ordering at the same time the funds.

Grr..... now that I think about it, this other exploit would allow your current users to "card" you and you wouldn't have much of a trail on your end, since the records would not match up.

I gotta think about it some more... but I think another ticket is coming :(

Originally posted by nybble
I turn to you for advice.

I have uncovered a flaw in the 2checkout passback system (v2?) and have contacted 2checkout about it;
I contacted them months ago about this (as well as MB who's broken 2CO module caused this to hit my mail box) Note the date on this following return I got.

Quick rundown,
Customer pays ticket from your invoice, payment page etc. Passback comes from 2CO and it contains EVERYTHING the client input. None of this data is masked btw, it is raw and complete. This is one from May. I have at least 100 more just like it.
Example



2004/04/07: 07:56:13

x_2checked => Y
x_response_code => 1
x_response_subcode => 1
x_response_reason_code => 1
x_response_reason_text => This transaction has been approved. x_auth_code => 123456 x_avs_code => NN x_trans_id => 79562-17175231 x_MD5_Hash => 60B17AAF910D8E9B97B5EF378B1068DE 2co_ip => 121 bankphone =>
cart_order_id => 779526-2737
cc_num => 4825680777777758
cem => 05
cey => 07
cvv => 324
demo =>
header =>
invoice => 1
order_number => 17165891
sid => 56889
total => 199.99
verify => on
x_address => 2085 Bagwell Rd.
x_amount => 19.99
x_city => Denver
x_country => US
x_email => customer@domain.com
x_first_name => Fred
x_invoice_num => 2737
x_last_name => Jones
x_login => 76775
x_phone => 678-479-5670
x_ship_to_first_name => Fred
x_ship_to_last_name => Customer
x_state => CO
x_zip => 39962
MyKey => F954258F1313BAA7F4DE2
REMOTE_ADDR =>




--

I am not sure what made them fix it, but I held my ground and didn't put up with anything from them - and I think TomD might have said something to someone about it.

So far so good - it's fixed. :)