I have a bad habit of wanting to post something of a certain size and weight before I post anything at all. The end result? I don't post anything! As the beginnings of an attempt to break this habit, I offer some almost entirely unrelated items I have come across lately. The top two items are from some recent adventures in Linux administration, while the last one is a really dumb one with an ASP.NET app.

Paranoid hosts.deny Can Trip You Up

One of my Debian-based firewall servers had the 'paranoid' option set in its /etc/hosts.deny file. The purpose of this option is to block access to any remote host where the host name does not match the address. I imagine it would work by pulling a PTR record from the IP, and then querying the resulting host name to see if it matches back to the IP again.

That system has had that setting for quite some time now, and it never caused me any trouble. Every connection I have apparently used in that time has had its DNS settings properly set. But I recently used a connection at a partner's office, which was provided through a small, local cable company. Hair-pulling ensued; While I had no trouble accessing the services on the systems behind the firewall, I could not connect to the SSH or VPN services provided by the firewall itself. Packet sniffing showed there were packets going back and forth. As I recall (it's been a few weeks now), something in syslog prompted me to think of hosts.deny;

I don't know how prevalent it is that ISPs will have improperly setup PTR records, but it's something to keep in mind.

I Was Creating a New Grub menu.lst Every Kernel Upgrade!

On another Debian-based firewall system I have, I kept a backup copy of Grub's menu.lst file to restore over the automatically generated one every time I did a kernel upgrade. This is a big-time case of "RTFM!" The reason I was doing it has to do with the perculiarities of the hard drive subsystem on the motherboard in question, requiring me to need to use the IDs of the drives.

But if I had simply read the comments in menu.lst, or read the man page, I would have known I had two options: 1) add special entries before/after the 'AUTOMAGIC KERNELS LIST' section or, more appropos for my situation 2) edit the default options within that section. The default menu.lst file comes with comments that describe the process quite well; the key lines are commented by a single hash (#), and that hash must remain there. When configuration of a new kernel is done, the defaults entered there are used. I was actually considering replacing this server with another one due to this issue, when all it took was literally a 30-second fix.

Don't Forget That Global.asax File!

Okay, you say, what kind of silly advice is that? Who would forget to upload one of the files of a web site? And wouldn't it be obvious when it happened? Of course, ASP.NET folks know that Global.asax is a special file. It's not a page that you load (requests for it are specifically denied by IIS by default, in fact), but it is frequently a vital file. Application-level code runs - or does not run - based on it.

I almost always use Code-Behinds in ASP.NET, where the 'web site files' (including Global.asax) merely contain markup, and then names of the compiled program objects from which they are to derive - those objects having been programmed via the 'code-behind' files, which are pure C# code, in my case. Even though all the code is compiled in an assembly, the web files are still needed (without some other special circumstances); The layout/design and markup code is still in the ASPX files - you will get the standard "File Not Found" error if such a file was not uploaded.

But the Global.asax is a special case. If it does not exist, the result is simply that no application-level code is run. This should seem obvious, but without the Global.asax being present in the web directory, the ASP.NET runtime has no way of knowing what, if any, HttpApplication-derived object that may or may not be in your code should run. You could derive a dozen such objects and compile them in your assembly. You may have compiled only one, but you don't want it used. My point is, the Global.asax file and the markup contained therein is the way that the runtime knows what you intended.

In my case, this oversight was the reason on my development system, a global variable set in Application_Start was valid, but on the staging server it was NULL.

I came across a post the other day where someone stated a misconception; That you can only host one HTTPS web site per IP address available on a server. I think most fairly experienced web server admins know that this is not actually the case, and also know why the misconception came to be. Most web server documentation I've seen tells one how to exceed that false limit, but of course it does not say so in exactly so many words!

Like pretty much everyone else who was ever a teenager, when someone says, "you can't do this", I want to know why. And I want to know why for the same reason I wanted to know why, as a teenager, I could not stay out past X time: so I can find a way around it. The long-and-short of the story is this: The actual limit for HTTPS sites is one per TCP socket, not IP Address. So, for every combination of IP address and TCP port, an HTTPS site can be hosted. Note that Host Headers have nothing to do with this. However; For a number of public uses of HTTPS sites, varying the standard TCP port is not a good option here, meaning the "one HTTPS site per IP" is still an effective standard.

More...

I have read, very conservatively speaking, at least 200 books about web-based programming frameworks and languages. I won't even try to put a number on how many web pages/sites I've read on the topics. Through that time, I've seen mentions of the basic difference between GET and POST requests as relates to web applications. As a side-note, a few comments are usually made concerning the security implications. Many of those brief remarks are, IMHO, not especially helpful. In essence, those remarks often boil down to, "GET is less secure because the data is visible on the query string". I say 'not especially helpful' here, rather than, 'patently incorrect' because one could make a somewhat convoluted case that what the authors are talking about sort of means the same thing I'm about to write about. But I think it's too clear that they mean the statement literally - that the fact that a user can 'see' the query string is the cause for concern, as opposed to the fact that POST data is not visible in a web browser.

More...

So, the other day I check into a small online community that has a small forum area where, among other things, people will sometimes discuss web development issues. While there, someone gave this bit of advice, to paraphrase:

Oh, as long as it's an application you programmed yourself, it's not really a big deal for you to have to take care of those old SQL Injection vulnerabilities. You can probably just let it wait until you upgrade the programming to a newer technology

I was a bit flabbergasted that someone would say such a thing, but it just so happens that I have, on hand, logs that prove that the assumption backing up that feeling of security is not at all based on reality.

Injection Bait

A little while ago, I set a client's database-driven web site to report errors to me generated as a result of attempts to exploit SQL Injection vulnerabilities. Normally, this sort of thing is "background Internet noise" that isn't terribly worth looking into - like 'port scans' on your home router. But I wanted to see what sorts of things were being tried. Also, since I had created all the code behind this site from the ground-up, I actually was curious how much I might see targeted SQL Injection attacks. The answer? Twice a week, average.

Of course, the WWW request logs contain lots of probing requests looking for certain popular web applications which have/have had SQL and other vulnerabilities. I swear I still occasionally catch sight of that now ages-old, telltale string of N's from Code Red in there, too... But these particular messages I was setting myself up to get were actual web application exceptions, caught when input fields have been tampered with to contain specially malformed values.

More...

Encryption is the art of making a message or other data safe for delivery over a medium where it may be intercepted by an unintended party. I say art because at least it often seems that way. It can be a very complex topic, made moreso by an often confusing array of (dis)information from mainstream media, technical media, software/hardware vendors, (quasi-)security experts, and white/gray/black hat crackers. I encourage developers who are attempting to understand encyption enough to implement systems which use it to read as much as they can on the topic, but with an extremely critical eye. I will attempt to share some information from my own experiences here, in a very small series of articles on the topic.

Today, I will cover some broad theory and general dos and don'ts. In the near future, I will share some more detailed information regarding actual implementation in code. Finally, I will share a library I developed for .NET developers to encapsulate some encryption code which does not always behave as one might intuitively expect.More...

A recently discovered bit of malware for the Apple Mac OSX operating system presents an opportunity to make a few brief points. I'll try not to preach. Too much.

The short version; The Peer-2-Peer file sharing networks have been discovered to be spreading a trojan horse software (link) posing as a free or cracked version of Apple's iWork 2009 (link) suite of productivity software. Apple does have a free trial version available for download for those who would legitimately like to try it out on their Mac.

For Heaven's Sake; Practice Safe Hex

Do not download from anonymous P2P networks. Forget the moral and ethical arguments entirely. These networks are simply a playground for people who would like to spread malware. All one has to do is create a trojan horse, and give it a name that suggests it is a crack for some expensive software, and off it goes. The prevalence of broadband connections means people will even download a 300 Megabyte piece of malware, which might actually be embedded within what appears to be the 'real' item claimed. The nature of most P2P networks makes it somewhat difficult to figure out where something came from, so there's little recourse when you get infected.

More...

Continuing my series on the SANS/CWE list of 2009's Top 25 Most Dangerous Programming Errors (link), I will cover three of the errors that involve apparently well-intentioned behaviors on the part of programmers, which nevertheless can end up in disaster. Specifically, Use of a Broken or Risky Cryptographic Algorithm (link), Use of Insufficiently Random Values (link) and Client-Side Enforcement of Server-Side Security (link).

It is unfortunately fairly common that persons in many professions, certainly including I.T. related ones, will operate from assumptions which are only half-correct. Most I.T. workers will agree with the statement that "computer security is an important topic". But from there, ideas, training and opinions fly in many directions, and unfortunately many of those directions are dangerous. You may have heard the statement, "Security by Obscurity is No Security at All". Literally speaking, this statement is wholly untrue; The whole basis of a good password, for example, is extreme obscurity. The idea is that a password is something so obscure, that no one could possibly ever guess it. So obscure, in fact, that if you didn't know it yourself, you would not be able to guess it.

However, passwords are really the only place the statement fails in relation to security. Although security is often seen as an issue for Information Security (I.S.) teams and administrators, it starts with application developers. (hence this series in the first place). The problem is, many novice - and frightfully too many experienced - programmers will take serious shortcuts when building in security to their applications. Often, developers will believe they have found some truly obscure method to protect data that won't be able to be cracked, without realizing that the best encryption schemes, for example, actually are those which are fully known, and thereby are constantly and thoroughly tested. Other times, a developer will implement a security mechanism imperfectly, being unaware of what is important in the algorithm working to protect the data.

More...

A couple of days ago, I put up a post about the SANS/CWE list of 2009's Top 25 Most Dangerous Programming Errors, and noted I would cover some of the items individually.

Today, I will briefly cover a couple that are somewhat related, in regards to the title of this entry. What I hope to get across is this; When you release an application (desktop or Web/Intranet), a programmer must always remember that malicious users will get access to the client side code. As a result, they can - and will - exploit whatever holes have been left. My goal with this article is to add something to the 'blogosphere that describes why these issues are important for programmers to consider at all times. If you are not a programmer, and never intend to be, perhaps this will be rather boring! Heck - even if you are, it may still be boring.

So the items which apply here are; Improper Input Validation, Improper Encoding or Escaping of Output, Failure to Preserve SQL Query Structure (aka 'SQL Injection') and Error Message Information Leak. All of these errors create a gold mine for people who want to use your hard work for their own nefarious purposes. These are very common and easily-made errors by inexperienced programmers, especially because these errors can be made in relatively simple web site code, where less-experienced programmers might more often find themselves creating something that will be available to be accessed by those seeking 'low-hanging fruit' to exploit. A common misconception is, "I'm not exactly creating another Amazon.com or a national bank's online-banking system; Who is going to try to hack my web site?" The answer to that question; Anyone looking for a group of users to exploit, a web server to send e-mail spam from, or a free place to host illegal content.

More...

The Common Weakness Enumeration (CWE) and SANS Institute (SANS) have posted the 2009 Top 25 Most Dangerous Programming Errors. As a developer who has always written code meant to be used in traditionally 'hostile' environments, it sometimes surprises me to see some of these items continue to be listed, and to continue to happen so frequently. Of course, I must admit that I probably have no place passing judgment on programmers in whose situations I have never quite been. I have never worked in a very large development shop with practically unrealistic deadlines set by management/marketing types, nor have I been in a project management position on any large-scale open-source project. Large-scale projects - whether open-source or wholly commercial - tend to have their own (often different) pressures which I absolutely can understand would lead to a desire to take shortcuts, and sometimes there is no true alternative than to work quickly, when one may prefer to work carefully.

However, I also do not want to provide excuses. Persons who write code for software are intelligent folks, by and large. They should know - or learn quickly - the many programming tricks and standards which can help them avoid these mistakes. Those who are tasked with dealing directly with management should also learn the intra-personal skills needed to assure that their teams have the time they need to develop code that is reasonably safe. One reason CWE and SANS have posted this list is to help developers hone in on these errors, and devote the time and energy to assuring that these issues do not become their issues. Software development is an art to a degree, and it is such a complex one that mistakes are probably a given in all but the simplest projects. But knowing what some of the most commonly-made and -exploited errors are should help.

As an academic exercise, I am going to cover some of these items in some upcoming entries - including noting some cases where I have struggled with them. For now, I just wanted to pass along the link to the very useful list itself.

Before anyone reading this sees the breathless headlines soon to come on the evening news, I thought I would post some quick analysis. In Berlin, Germany today, at the 25th Chaos Communication Congress (25C3), run by the Chaos Computer Club (CCC), a presentation was made which was entitled, "MD5 considered harmful today; Creating a rogue CA Certificate". I have no idea how the non-computer-literate (or even semi-) media will report this, but likely they will speak about SSL/Secure web sites being able to be spoofed, and that 'phishing' attacks will be more likely, and users won't have any way of knowing if they are victims.

Background

First, a quick attempt at giving a very simple explanation of what is actually very complex;

A 'Certificate Authority' (CA) is a company/entity which issues certificates that are used to verify the identity of something. Typically you will see this evident in the 'Padlock' or colored status bar of your web browser when browsing a secure web site. The 'certificate' is an electronic document, of sorts, which contains various information used to verify that the site is who it claims to be, and pointing your web browser (transparently to you) to a CA that does the actual verification. As you might expect, the identities of these CA's are very important. Every web browser comes with a pre-set list of known, trusted CA's. A user can add/remove CA's, which is a critical operation that in practice, is rarely done.

More...