Web Site Security

Cryptography Reading List

Here is my reading list related to implementing encryption in PHP.

1. Web Security 2016 from php[architect] magazine, https://www.phparch.com/books/web-security-2016/. This anthology includes Ed Barnard’s Securing Your Web Services series.

2. Cryptography Engineering: Design Principles and Practical Applications by Niels Ferguson, Bruce Schneier, Tadayoshi Kohno, http://www.amazon.com/gp/product/0470474246. Reading a book or two won’t make you a cryptographer. But read the book or two anyway, starting with this one.

3. Information Security at Stack Exchange, http://security.stackexchange.com/. I find the Information Security folks to be friendly, helpful, authoritative, and thorough. Learn to ask questions correctly and you’ll be delighted with the responses. Don’t be shy, but show that you’ve thought things through before typing out the question. Related are What to do when you can’t protect mobile app secret keys? and How to encrypt in PHP, properly?.

4. Myths about /dev/urandom by Thomas Hühn, http://www.2uo.de/myths-about-urandom/. Excellent article about randomness and random number generators.

5. Insufficient Entropy For Random Values by Padraic Brady, http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html. A good, thorough, enlightening discussion. Click the top left corner of the page to continue with the entire online book, Survive The Deep End: PHP Security.

6. How To Safely Generate A Random Number, http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/. This article explains one of the ways that OpenSSL gets it wrong, and why you want to be using /dev/urandom.

7. Block cipher mode of operation, https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation. Also, Precisely how does CBC mode use the initialization vector?. These explanations may help you understand how to use AES encryption correctly.

8. Using Encryption and Authentication Correctly (for PHP developers) by Paragon Initiative staff, https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly. Their web site has a number of useful articles, including The State of Cryptography in PHP, https://paragonie.com/blog/2015/09/state-cryptography-in-php.

9. The Cryptographic Doom Principle by Moxie Marlinspike, http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/. It’s a fun read on a serious topic, and why my examples are authenticate-then-decrypt rather than the other way around.

Security Reading List

Here is my reading list related to securing your web services.

1. Web Security 2016, https://www.phparch.com/books/web-security-2016/. This anthology includes Ed Barnard’s Securing Your Web Services series.
2. Survive The Deep End: PHP Security by Padraic Brady, http://phpsecurity.readthedocs.org/en/latest/. Excellent survey of what you need to know about PHP security. This short online book is a good starting point.
3. PHP Security Cheat Sheet by The Open Web Application Security Project (OWASP), https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet. I include the OWASP page to point out that you should be long past dealing with these basic web site security issues. But if you are new to PHP security, this is a good reference.
4. Web Service Security Cheat Sheet by OWASP, https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet. Checklists are valuable. Visit this cheat sheet from time to time to ensure you still have the right things covered.
5. Information Security at Stack Exchange, http://security.stackexchange.com/. I find the Information Security folks to be friendly, helpful, authoritative, and thorough. Learn to ask questions correctly and you’ll be delighted with the responses. Don’t be shy, but show that you’ve thought things through before typing out the question.
6. How to Hack a Paysite: What the Good Guys Need to Know by Ed Barnard, http://otscripts.com/how-to-hack-a-paysite-articles/. The article series is old, but my exploration of attitude and motivation remain relevant.
7. The Art of War: Complete Text and Commentaries by Sun Tzu, translated by Thomas Cleary, http://www.amazon.com/gp/product/1590300548. Various Twitter accounts quote this two-thousand-year-old classic including @battlemachinne. One line at a time, these can help you retain that all-important security attitude.
8. Threat Modeling: Designing for Security by Adam Shostack, http://www.amazon.com/gp/product/1118809998. This is the “big picture” look at formally anticipating security threats to your software. It’s a tough row to hoe. But if you don’t, who will?
9. Web Security: A WhiteHat Perspective, by Hanqing Wu and Liz Zhao, http://www.amazon.com/gp/product/1466592613. This one is tough to read but worth the energy expended. I believe there were two editions of the book published, one in Chinese and one in English. A former hacker himself, the author brings a useful perspective and solid information.
10. Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd Edition, by Ross J. Anderson, http://www.amazon.com/gp/product/0470068523. This thousand-page monster won’t be read in one sitting. Like Threat Modeling, this “big picture” book will give you perspective and strategies you won’t find elsewhere.
11. Cryptography Engineering: Design Principles and Practical Applications by Niels Ferguson, Bruce Schneier, Tadayoshi Kohno, http://www.amazon.com/gp/product/0470474246. I saved the best for last. If you’re planning to write security-related code, read this book first. It’s a good and surprisingly fast read. You’ll come away with a far better understanding of how things hold together and why.

Sociable Plugin Compromised

I disabled the “Be Sociable, Share!” plugin because it appears to be the source of the garbage showing up in the WordPress post content. The plugin pulls images from various sites and I’m guessing that it’s pulling something from a compromised site. Ouch.

Keeping the Hackers Out: I Can Hack You, Part 4

You really have three problems: The sharks, the crackers, and the exploiters.

First, you need to keep the sharks out. Once a live password has been posted for your site, the feeding frenzy kills your server, and you’ll be stuck with the bandwidth bill. So, given that your passwords have already been cracked, you must protect yourself from the freeloaders trying to get in. Your financial survival depends on it. (Several companies offer excellent shark-protection services.)

A good password-choosing policy will keep the crackers from feeding the sharks. It’s that simple! The master crackers themselves confirm that they depend on people (including billing companies) using poorly-chosen passwords. When the passwords become uncrackable, they must either find another way in, or intercept them as plain text. (We’ll discuss a possible password-choosing policy below.)

The exploiters are a very different situation. The exploiters are what we mean by “hackers” in the traditional sense of the word. All software has weaknesses, and those weaknesses can be found. Read more…

Exploiting: I Can Hack You, Part 3

Exploiting fits into two stages:

• Finding the security hole (called scanning for exploits)
• Using the security hole (called exploiting)

Scanning is easy. Pick a paysite and run through a list of URLs which might be interesting. You can download your own scanning program for free. You can do the same with other peoples’ URL lists. You’re supposed to then shorten your list to include only URLs that you personally know how to exploit. If you’ve noticed a bunch of weird off-the-wall URLs in your server logs from time to time, you’ve seen people scanning your site for exploits. You can safely ignore the scanning – unless they find something.

What they found, with the information necessary for its use, is called an exploit. Exploiters post lists of working exploits on the hackers’ boards, the same as crackers post lists of working passes, as a means of sharing information. At the same time as the sharks are using the passes, the other crackers are adding those passes to their John the Ripper word list. Read more…

Advanced Cracking: I Can Hack You, Part 2

The next step would be to apply your skill and experience to the specific password file at hand. If you know all passwords are eight random digits, for example, you can search accordingly. John the Ripper has its own programming language wherein you can tell it what approaches to take.

Suppose you have managed to crack a few passwords, and discover that when the username is firstname.lastname, the password is first initial followed by last name followed by 1-5 random digits. You can crack the rest of the file almost instantly! Tell John the Ripper to keep the first letter, drop everything up to the dot, drop the dot and keep everything following the dot.

With a bit of experience, you can make this example even simpler. Many paysites use standard unix-type passwords, called DES encryption. Only the first eight characters of the password are encrypted! So, to use the example above, if the person’s last name is seven characters or more, you know the password. No guessing is needed.

Do you see why this is so? The password (according to our assumed rules) is first initial followed by last name followed by digits. But… only the first eight characters are used. So, if the name is seven letters or longer, all the leftover characters (including all the digits) are ignored. So far as the paysite is concerned, the password is that person’s initial followed by the first seven characters of their last name.

In the same way, if the person’s last name is six characters, you need only try adding a single digit. That gives you a mere ten possibilities to try. Even if the last name is a single character, you only have a hundred thousand combinations to try. Since John the Ripper can run millions of trials per second, the worst possible case will still have you seeing dozens of passwords cracked per second. Read more…

The Making of a Hacker: I Can Hack You, Part 1

«Ï» çÅñ H@Çk ¥°Ü·
What the hackers do, and how to keep them from doing it

The Making of a Hacker

Picture, if you will, a parasite that calls itself an “immunity tester.” Our immunity tester travels from host to host, “testing” to see if it can feed off that particular host. When the feeding is good, our parasite tosses a few chunks of meat in front of the sharks. The feeding frenzy begins.

You’ll know the feeding frenzy when it happens. You’ve been hit by the password traders. Unless you have frenzy protection, your bandwidth use will go through the roof. Someone needs to pay that bandwidth bill – but it won’t be the sharks or the parasites.

In spite of the feeding frenzy, our parasite is a responsible parasite. He’s careful to not destroy or otherwise damage the host. Sure, he starts the feeding frenzy, but the frenzy itself is not his concern. He’ll add one or two passwords to your members area rather than two hundred. Two hundred might get noticed.

If he’s cracked hundreds of your passwords, he’ll only post a few at a time for the sharks. You’ll focus on the few without realizing that hundreds are known. As our parasite trickles out the “fresh” passes, he remains a hero for continually doing such great work.

Almost every hacker board calls itself the top resource for “security testing.” They are “educational” in nature, and not for profit. If you’re a webmaster, you can ask the board owner to remove all references to your site from their board – and they will. Read more…

Billing Exploits: How to Hack a Paysite, Part 4

Is somebody exploiting your billing script? How would you know? Many billing scripts have no tracing, no audit trail, no other validation or protection. If you have the keyword, you’re in. Your financial data is safe, but your paysite is wide open.

Other scripts do a bit better with authentication, and do leave an audit trail of sorts. The irony is, that very audit trail is highly prized hacker food! The audit trail shows the passwords, and all too often they’re crackable.

If you visit the “elite” areas of the paysite hackers’ boards, you’ll see that the billing scripts are the most commonly published method of breaking into a server. If you’re having a hacker problem, it’s very likely that a billing company is your problem. The problem could be your billing company; or the problem could be someone else’s billing script on the same server. (This is why you are far more vulnerable on a shared server. You have to worry about your own scripts and the other customers’ scripts.)

Have you noticed that I left out a step? To crack the passwords, you need to display a copy of the password file. You can trick a billing script into thinking you’re the billing company, and add your own password. If you can do that, you don’t need to crack someone else’s password! But that doesn’t get us a copy of the entire password file.

The other thing you can do with a billing script, is break into the server itself. You can use the billing script to display files that you shouldn’t be able to see. You can also display folder contents that you shouldn’t see. That’s how you find the things which are hidden, and how you find the secrets of other paysites on the same server.

How, then, do you get a copy of the password file, so you can crack it? You use a billing script, somewhere on the server, to display the file. Some billing scripts come with online instructions for the hackers. It tells you how to display the password file, how to add your own username and password, and even how to delete all paysite members.

Online help for hackers – remember that this is helping the hacker to hack your paysite – is nice, but far from the worst. Other billing scripts allow your hackers to run any unix command anywhere on the server. They can install their own stuff on your server, or scan your private areas for hidden webmasters’ notes. It doesn’t get much better than that! Read more…

The Buck Stops Nowhere: How To Hack a Paysite, Part 3

Let’s step back a moment, and consider the situation. Your billing company should take responsibility for protecting your customers’ billing information, and your server admin should take responsibility for protecting your paysite. After all, the billing info is on the billing company’s server, and the paysite is on the admin’s server.

After carefully analyzing the situation, I strongly disagree. Your customers’ credit card data is (usually) secure. Why is this so? Because that’s what your billing company does. They have firewalls, authentication codes, secure logins, and surely keep a careful watch on outside probing. If they’re being hacked, they know it.

But who’s keeping that close an eye on your members area? If someone got a copy of your password file, would you know it? If someone quietly added a couple of passwords, would you know that either? Nobody’s watching! Your billing company doesn’t consider it their responsibility. But if not, whose is it? Think about it: What are you paying them for?

Exploiting the Billing Companies

The basic problem is this: The billing companies are up against some serious technical difficulties when it comes to protecting your paysite. First, the server itself is outside their control. The server itself is your problem, and your server admin’s problem. Second, there’s a basic security flaw in how servers work. Read more…

Let’s Start Hacking: How to Hack a Paysite, Part 2

So you want to hack a paysite. Where do you start? With a password file! If you can’t find one on your own, visit one of the hackers’ boards and you’ll find ’em posted.

Not so long ago – perhaps two years ago – a lot of paysites allowed their security files (.htaccess and .htpasswd) to be visible in a browser. If you knew where to look, there it was! Fortunately most server admins have closed up this hole.

On the other hand… this trend seems to be reversing. More and more people have decided to save some money, and become their own server admins. There are more and more one-man hosting companies with great prices – but no security expertise. There are “web appliances” that will configure your server for you. By all means go the cheap route. The hackers will love you for it!

Meanwhile, though, you have a password file. This is a list of all members of your paysite. The usernames are in plain text (john, jacob, jingle, heimer, and so on). The passwords are encrypted (/Cphz8p6Emb3A, ooxdAVLkmR6/Y, auWXZ/088ALTQ, etc.). That makes them safe, right? Wrong! Read more…