Question
With all the recent auction start-up's, it seems an issue constantly being echoed is security. As one recent flop has shown, many of our concerns might not be totally unjustified. I was reading this post on FAS, linked from the Blujay thread:
http://www.freeauctionscripts.com/co...=4055&start=50
That got me pondering last night, just how secure are these servers really, and what would it take to hack them (proving that they're actually insecure)? If you ask any of the owners of these new websites, they will tell you their site is "secure", but what does that really mean? Here's a definition from eBay's website:
Secure Server
A special server used for processing credit card information submitted by users. This server uses Secure Socket Layer (encryption for the protection of our users). For details about the secure server, please see our Credit Card Policy.
By that definition, I assume eBay means their server is secure, since all parts of it that have sensitive info are "secured" by SSL. SSL encrypts data so that eavesdroppers can't view sensitive details, like your password or credit card # as it travels thru the network. So, if I'm sitting on the line of auction user "john_doe" with a packet sniffer as he log's on, I just see encrypted gobbledy-gook.
And yet, if I click on eBay's link for "Forgot my password", and supply the username "john_doe", I'm shown a verification form (see attachments) asking me to answer at least one question. One of which (if you can BELIEVE it!) is simply for the zipcode. If I can eavesdrop on john_doe's traffic, then I know his IP, which I can enter at a site like http://www.ip2location.com/ to get his zipcode. Then, when eBay sends the UNENCRYPTED e-mail with the "reset password" instructions to john_doe, I check my packet sniffer and grab the e-mail. Follow the instructions, setup a new password, log-in and steal as much data or wreak as much havoc as I want with John Doe's account before he finds out. Now...... is eBay's definition of a "SECURE SERVER" really the right one?
For those who still think SSL is secure, imagine this. Let's suppose I am located with my packet sniffer somewhere between john_doe and eBay. That means I can alter packets (as long as they aren't encrypted) as they travel back and forth. john_doe does a completed item search, or goes to myEbay, or whatever, and his browser sends a request for the proper page. eBay detects that he isn't logged in, of course, so it sends a 301 or 302 code back, which redirects the browser to the https:// login page. However, since I can alter packets, I change https://signin.ebay.com/ with the address of my Argentinian web server which hosts a duplicate of eBay's log-in page. Now, john_doe sends his username and password to my Argentinian server, which will then forward him back to the proper https://signin.ebay.com/ page. John Doe may or may NOT notice the weird accidental reload--he might just think he hit the wrong button, who knows, I already have his password and he can't do anything about. Still thinking eBay is secure...? Any website that doesn't encrypt EVERY page in SSL is vulnerable to this attack. (And even still, DNS requests for the domain name can be altered en-route too, so a resolve from eBay.com to 66.135.192.87 can be replaced with the IP address of my Argentinian web server, before eBay ever receives contact.)
One last final exercise. Let's consider PayPal... a REALLY secure server, right? I mean, they have every page encrypted in 256-bit SSL (session key encrypted with 1024-bit RSA, data encrypted with 256-bit RC4). OK, so let's say I can't alter packets as they flow between john_doe and PayPal (so no DNS spoofing). Because I can see the data, however, I have a copy of the encrypted transmission as he logs in to PayPal. Here's one problem I realized tho, with the approach PayPal (and many other websites) take: 99.9% of the data is static. In other words, the PayPal homepage is the same HTML sent to everyone. Even after logging in, a great deal of the data is still static (the only dynamic info being my username, account balance, and then account history, etc...)
This means it is very easy to launch a known plaintext attack. Here's a simple example. The PayPal homepage consists of the text: "Welcome to PayPal". John_doe receives the RC4-encrypted message "AOIWJEFOAIW". If I figure out WHAT session key will encrypt "Welcome to PayPal" -> "AOIWJEFOAIW", then I can also read all future messages (like when john_doe sends his password). Some algorithms are notoriously insusceptible to known plaintext attacks... in other words, to figure out the session key, I'll have to try every possible choice (could take years). Some algorithms are "weakened" by plaintext attack: instead of years, might take days, depending on the quantity of plaintext you have. So how does RC4, the choice algorithm of SSL, fare?
I found this thread: http://www.cs.uni-magdeburg.de/~ssch...nksarcfour.txt
Essentially, it doesn't take years or days: it takes seconds, maybe minutes, and the code is simple as pie. XOR the plaintext (the homepage for instance) with the encrypted data, trying various offsets, to obtain a list of candidate "key streams". Now, XOR the candidate key streams at different locations of the encrypted transmission (the place where you'd expect the dynamic data to be) until the result turns into valid HTML packets. Voila, SSL encryption broken, in mere seconds, with the benefit of only a packet sniffer. (Note: I haven't verified that this attack actually works, so if someone can explain why the above attack wouldn't work, I'd be glad to hear. Clearly, the period length of the RC4 keystream, and exact quantity of plaintext obtained will make a big difference, but with kilobytes and kilobytes of plaintext, the probability of obtaining the entire key stream is very high.) This attack depends on PayPal caching session keys: for almost all servers, this is recommended, since calculating a new session key for each session requires about 2-3 seconds of CPU time (compared to milliseconds if its cached). I've noticed eBay actually never caches session keys, but then they only encrypt the log-in pages and nothing else. I don't know about PayPal per se, but my point is, how many auction site owners do you think even KNOW whether they're caching session keys? Could they tell you which version of SSL they're using? What handshake protocol? Which symmetric cipher? Would they even know what a plaintext attack is if you asked them...?
So I'm curious... what do people think? What's YOUR definition of security, and what if anything needs to be done to make sure that auction start-up's are really secure and not just blowing hot air?
DISCLAIMER: I'm not encouraging anybody actually try any of these attacks. It's highly illegal, and you could go to jail. I hope nobody is actually dumb enough to think I'm endorsing that you go out and try this stuff, just to prove to someone that their site is insecure. I provide these examples so we can have an intelligent discussion on what web security means for the on-line auction industry.
Answer
Please forgive the "dumb down" of the discussion...
Late last year, I sent $1200 to someone for an item they had auctioned on eBay, and then emailed me saying the high bidder had some health problems, and had to back out. They offered the item to me, and I was happy to buy it... but I wanted to be careful, so I contacted the high bidder to verify the story. The high bidder said they had indeed backed out of the transaction. Then, since the email had come directly to me, and not through eBay's system, I contacted the seller through eBay's system to verify that they had sent the offer. The husband of the seller emailed me back, said his wife was on the road, and that he talked to her and she had offered it.
The seller had very excellent feedback, and so I complied with the request to send a cashier's check via Priority Mail.
A couple days later, someone contacted me saying they received my cashier's check and wanted to talk to me about it. I found that the person I sent the $1200 to was a car salesman in the midwest who had an ad on Monster.com to try and pick up some extra money. A company contacted him and told him to await further instructions. Then they told him that 3 cashier's checks would be arriving, and for him to deposit them into his bank account and await further instructions. He smelled something fishy and contacted me, and then sent my cashier's check back.
Later, I contacted the seller again and got the actual seller, who didn't have anything to do with ANY of the emails I sent or received. Someone was intercepting them and replying, using a trojan or some other method. The high bidder, I dunno... And the guy who returned my money, well, he was like the others... like them how? Nobody wanted to discuss it further. Everyone knew that something was happening, and everyone wanted to stay out of it. I tried contacting several police agencies, eBay, etc., and found that nobody cared, because I had my money back and didn't suffer any loss.
Obviously eBay is being exploited in various ways. At the moment, most of the smaller sites manage to avoid the more extensive scams. What you are talking about... you (the general "you", not you in particular) could do that on eBay, but why WOULD you do it on LunarBid or BidVille or some third tier site? That's like fishing with a tuna boat on a stock pond.
I think the measure is... does the site take reasonable measures to protect it's users and their information? And "reasonable" is subjective, but the failed site you speak of didn't even measure up to the minimum standard required by MC/Visa to accept credit cards online... and that is certainly UNreasonable. I think MC/Visa have enough at stake that their minimum requirements can be accepted as "reasonable". They have no qualms about imposing requirements on merchants, they stand to lose the most, and they are in the best position to know what kinds of fraud are being used.
Answer
another avenue connected but a bit different
I look on these secondary sites and I see a laptop computor for sale and I think....hummm is it a scam?
and how could it be avoided
any ideas jason?
Answer
Originally Posted by Toy Ranch
Obviously eBay is being exploited in various ways. At the moment, most of the smaller sites manage to avoid the more extensive scams. What you are talking about... you (the general "you", not you in particular) could do that on eBay, but why WOULD you do it on LunarBid or BidVille or some third tier site? That's like fishing with a tuna boat on a stock pond.
I think the measure is... does the site take reasonable measures to protect it's users and their information? And "reasonable" is subjective, but the failed site you speak of didn't even measure up to the minimum standard required by MC/Visa to accept credit cards online... and that is certainly UNreasonable. I think MC/Visa have enough at stake that their minimum requirements can be accepted as "reasonable". They have no qualms about imposing requirements on merchants, they stand to lose the most, and they are in the best position to know what kinds of fraud are being used.
I agree exactly, actually. The attacks I mention are high-level... by bad luck, RC4 has a plaintext vulnerability that even a 1st year comp-sci grad could crack. But many other authentication algorithms that are theoretically less secure than SSL (like challenge-response) are harder to break in real-world practice. I don't think the average eBay scammer (or hacker for that matter) is very intelligent. The intelligent hackers are spending their time more wisely on sites like Citibank or the military. Don't even get me started on what I think the general skill and proficiency of a lunarbid or blujay hacker to be
Which brings me to... why the whole fuss about SSL? What I didn't even mention about the attacks above is how infeasible they are. I addressed them mainly to people who are paranoid about security, but seem to find a false sense of security as long as they know SSL is installed. However, SSL guards against a vulnerability that in real life is almost non-existent. The difficulty in all the attacks above, is that they assume I can eavesdrop on someone's traffic. As someone who has been paid to professionally hack into networks (some with mediocre security, some with very good security), I have never once been able to take advantage of promiscuous packet sniffing ("eavesdropping" on network data, essentially). The reason being that it requires either:
a) A physical wiretap on the line carrying data (and don't get me started on how suspicious you're gonna look breaking into a telephone box, with laptop in hand, or digging up a fiber-optic line with your shovel...)
b) A computer on a NON-SWITCHED branch of ethernet that either the client or server is on. (Most server networks are self-contained in data centers, making them next to impossible to infiltrate. On DSL, many houses are switched separately, so you'd have to physically break into the house to eavesdrop. I don't know about your home, but a hacker wouldn't be able to hide in mine for long Cable I think is more lax, but you're still not seeing many other users' traffic at a given time. The only place where this approach is maybe viable is in a company or college, where it's typical to see 10-20 other users' traffic at a time... Also, I can't speak for companies, but at least at my school I know there are network traffic analyzers in place which specifically detect promiscuous packet sniffing, meaning if you're running one, you won't be for long! Company's policies will vary on this, but again, this whole approach is very unlikely.
c) Actually install a promiscuous packet sniffer on one of the internet backbone's routers. (These machines see significant amounts of data, making them the most sought-after targets for such activities. However, most of them aren't even "computers" that you can hack: they don't run windows, or linux... they run firmware. Also, because they are the most sought-after targets, they also are the best-protected. I'd be amazed if anyone in history has ever accomplished a backbone router take-over, unless they actually managed to get a job as the technician who maintains the router.)
d) Install a packet sniffer on the client's computer or the server computer itself, as a virus or trojan perhaps. (If I could do this, I would just install a keystroke logger for a client, or a program to steal data off the hard disk and send it back if a server... why bother gathering the crumbs when the cheese is right in front of you? So this approach isn't even worth discussing.)
For all these reasons, I still don't understand why people insist so much on SSL. Instead, they should be worrying about client and server security, not the connection in between... In the case of waggleflop, we saw a situation of very bad server security. In the case of eBay, I see a lot of client security problems (phishing e-mails, or viruses and worms that can steal passwords). Any of the client and server attacks would be far easier to accomplish than the eavesdropping attacks I mention... so why are people so concerned about securing the connection? Personally, I see a similar trend in browsers too... I use FireFox, and I love it, but I also realize that FireFox doesn't make me any safer than IE against worms or e-mail viruses, which have nothing to with web browsing... and it only makes me marginally safer against phishing scams (FireFox will gladly send your password and info to a party in Brazil if you tell it to, just like IE).
What's a list of questions we could ask auction site owners, besides "Do you support SSL?" that might really make a difference for security?
Answer
Originally Posted by gabs-a-lot
another avenue connected but a bit different
I look on these secondary sites and I see a laptop computor for sale and I think....hummm is it a scam?
and how could it be avoided
any ideas jason?
One definition I've seen of security goes: "security is when something always works the way we expect it to". By this definition, a scam is the same as a security violation. I "expect" that so-and-so will sell me a laptop, because these are the rules in place; when he fails to, it violates my trust and it has also violated the security policy.
Why do you give your hard-earned money to a bank, to hold in an account? If you told someone from the medieval era, they might think you were making it up. But our trust in the modern banking system derives from its excellent security record: I expect that my bank will always give me back the money I give them, according to the terms I sign, and this has always been the case. The reason it works is because of government institutions that regulate banking and prosecute fraud. Why would the government bother? Because it's key to a working economy.
When Pierre implemented feedback, he did it because he knew that building trust between buyers and sellers would also create a sense of security. And he was right... people were more willing to buy and sell because of the extra security they felt when dealing with a person having high feedback. It's amazing that such a tiny effort towards security made such a big difference in people's positive outcome.
Personally, Gabs, I'd love to hear more auction site owners talking not just about the security of our credentials and passwords, but also of the marketplace. The feedback mechanism Pierre put in place was nice, but is it the best we can do?
I'm not providing any solutions, b/c after all, that's what we pay these site operators for!! But it's always good to let them know what we're concerned about.
Answer
You know, while I'm at it, I thought I'd throw this out there too: all companies now seem to KNOW that they need to provide a privacy policy on their site. How about also providing a SECURITY policy. Some of the things they might state in such a policy are:
a) What data is collected? How is it protected? Who can access it?
b) How is the server secured? What services does it run? Are all those services patched, are any not necessary? What measures have been taking to ensure that said services are secured (other than taking it for granted)? How is the server protected against physical access? Can the server be accessed remotely via FTP, for instance? Who has the FTP password? Is the FTP password vulnerable to a dictionary attack? How is the server safe against natural disaster? DDoS attacks?
c) Auditing? What actions are tracked? How are logs guaranteed against tampering? How often are logs checked for suspicious activity?
d) How does the company respond if (I should actually say WHEN) the server is hacked? How do they guarantee that data isn't leaked to say, employees during the ensuing confusion? How do they ensure that the integrity of software, data, etc. is restored? Is there a procedure for contacting law enforcement officials to assist?
By creating such a policy, at least companies would have a physical checklist of things they need to work on. And they don't have to meet everyone of these requirements, either... but at least then customers know what IS and what ISN'T covered, rather than just assuming that "well, XYZ says their server is secure, so it must be secure against everything!"
What do you think? Is this too much trouble for a start-up to think about, or something we should start asking for?
Answer
The only problem with posting a security policy like your suggested list is that it gives the hackers exactly the kind of information they need to formulate a hack that works.
...but my point is, how many auction site owners do you think even KNOW whether they're caching session keys? Could they tell you which version of SSL they're using? What handshake protocol? Which symmetric cipher? Would they even know what a plaintext attack is if you asked them...?
If a person or company is using a hosted site, these things are the responsibility of the site host and said host damn sure better know the answers or they won't last long in the business. If a person or company is running a dedicated server, documentation on how these things are implemented is provided as part of the service. I don't have much experience with running a rented dedicated server, but I know that the hosting companies are very insistent about their users keeping up with issues like this. If a person or company runs their own server, the question is more problematic.
Answer
I think I'm picking up what you're laying down, but I haven't seen any successful examples of RC4 being compromised. Not saying it hasn't happened, just haven't seen it reported. Paypal's site is probably better defined as consistent blobs of dynamic data, rather than static, in my opinion.
That being said, I think it'd take quite a while to get the results you wanted without being noticed, and add a second layer to cover your tracks from being noticed.
Good discussion
Answer
Anyone know why Bidzig has EVERY page secured? My bank doesn't even do that
My habit is to hit the back button alot, and get the infamous post-data errors frequently.
Answer
Probably because its easier to secure ALL your web page documents, than set up your software to deliver one directory SSL encrypted, and one not encrypted.