Jump to content


Photo
- - - - -

Verifone CC Processing Software


  • Please log in to reply
24 replies to this topic

#21 Enmaku

Enmaku

    SUP3R 31337

  • Members
  • 163 posts
  • Country:
  • Gender:Male
  • Location:Las Vegas, NV

Posted 02 May 2010 - 02:39 AM

OK, so hopefully this post isn't so old that this would be considered necromancy, but I've come to a conclusion. Counsel advises me that my NDA only covers stuff I learned or knew when I worked for VFI, anything I learn after the fact is fair game so here goes.

I never got to support integration, we always referred them to their point-of-sale manufacturer for that stuff, so I've been playing with it a bit since this hit the open market and here's what I've got:

Integration in any version before 5.8 appears to be either TCP or SMB based, no encryption anywhere. 5.8 appears to offer SSL but it's clunky and definitely not the default. I've sniffed my own traffic and sure enough there's the whole transaction unencrypted on the local wire for anyone with access to see. I'm pretty sure PCI compliance requires that merchants secure their own networks but it seems like kind of a douche move to dump that kind of a vulnerability on end-users who are probably as technically competent as a garden slug. Talk about enforcing the letter of the law rather than its spirit.

Transactions are sent from client to server as unencrypted XML regardless of the method chosen. TCP just connects on the specified port (default 31419) and dumps the XML, then waits for an XML-formatted response before closing the connection. SMB puts the data in a file which is copied into a shared folder over the network, the transaction is run and then the file deleted and another file created with a similar name but different extension. The incoming transaction is a .INX file, the outgoing is a .OUX file, both containing unencrypted plain XML with every detail perfectly human-readable.

These are the results of sniffing network traffic between a node running payment server and one running client, I can only assume that integration with third-party software works in much the same way. Based on sniffing I've done at places like Starbucks and McDonalds I'm pretty sure the big name stores hire someone to handle their networks, I've never seen a card number go over the wire there, but this does look similar to something I've seen at a smaller local coffee house, and I'll bet there's a lot of small businesses who could get screwed by this badly.

More to come when there's more to tell :)

#22 PurpleJesus

PurpleJesus

    Dangerous free thinker

  • Members
  • 1,578 posts
  • Gender:Male
  • Location:800

Posted 02 May 2010 - 01:48 PM

OK, so hopefully this post isn't so old that this would be considered necromancy, but I've come to a conclusion. Counsel advises me that my NDA only covers stuff I learned or knew when I worked for VFI, anything I learn after the fact is fair game so here goes.

I never got to support integration, we always referred them to their point-of-sale manufacturer for that stuff, so I've been playing with it a bit since this hit the open market and here's what I've got:

Integration in any version before 5.8 appears to be either TCP or SMB based, no encryption anywhere. 5.8 appears to offer SSL but it's clunky and definitely not the default. I've sniffed my own traffic and sure enough there's the whole transaction unencrypted on the local wire for anyone with access to see. I'm pretty sure PCI compliance requires that merchants secure their own networks but it seems like kind of a douche move to dump that kind of a vulnerability on end-users who are probably as technically competent as a garden slug. Talk about enforcing the letter of the law rather than its spirit.

Transactions are sent from client to server as unencrypted XML regardless of the method chosen. TCP just connects on the specified port (default 31419) and dumps the XML, then waits for an XML-formatted response before closing the connection. SMB puts the data in a file which is copied into a shared folder over the network, the transaction is run and then the file deleted and another file created with a similar name but different extension. The incoming transaction is a .INX file, the outgoing is a .OUX file, both containing unencrypted plain XML with every detail perfectly human-readable.

These are the results of sniffing network traffic between a node running payment server and one running client, I can only assume that integration with third-party software works in much the same way. Based on sniffing I've done at places like Starbucks and McDonalds I'm pretty sure the big name stores hire someone to handle their networks, I've never seen a card number go over the wire there, but this does look similar to something I've seen at a smaller local coffee house, and I'll bet there's a lot of small businesses who could get screwed by this badly.

More to come when there's more to tell :)


That is quite frightening.

#23 Enmaku

Enmaku

    SUP3R 31337

  • Members
  • 163 posts
  • Country:
  • Gender:Male
  • Location:Las Vegas, NV

Posted 02 May 2010 - 02:53 PM

Just tested the excel "rainbow table" of expiration dates that was in the package, it's accurate but incomplete. BTW if you start the program with a /D flag (case sensitive) it runs in "demo mode" and doesn't appear to communicate with the outside world. Any MOD10 valid card number is authorized. I made an import file with the excel tool included and it ran 20 transactions in a couple seconds so generating one of these tables for all card numbers seems like a very real possibility. I'm thinking I might actually write a program to generate the appropriate import files for, say, all possible visa and MC numbers as well as a more complete list of expiration dates and dedicate some CPU time to running it if anyone is interested. Not sure what format I would store the results in either, any suggestions?

#24 dreamseller

dreamseller

    Will I break 10 posts?

  • Members
  • 2 posts
  • Gender:Male

Posted 19 January 2014 - 10:06 AM

please help me

all link for torrent "Leaked Verifone Files" is not active now

i need documentation about Verifone cryptography

who may upload it and put download link?

contact me at jabber dreamseller@xmpp.jp



#25 cardplayer

cardplayer

    the 0ne

  • Members
  • 1 posts
  • Gender:Male

Posted 05 April 2014 - 07:25 PM

hi brother i just read now almost after 4 years. and link are not working all files are removed from rapidshare.com .

 can i get all these file in anyway ? kindly reple me ... or if any one there who can send me these files.

 thnx .... waiting ..






BinRev is hosted by the great people at Lunarpages!