« Previous Entries

Category

Security

• Security, Software, Technology

  WinHasher 1.6

  February 8th, 2010 (1 month ago) by Jeff | Permalink | Dump Core

  Wow! A non-Twitter digest post! Amazing!

  This is a quickie to let you guys now I’ve just released WinHasher 1.6. This is a minor release containing a few cosmetic and minor functional changes, so there’s no need to upgrade unless the features or bug fixes listed below seem worth the effort.

  • Added a progress indication message for all the console applications. Previously, these programs simply went off into lala land when you kicked them off, kind of like the original GUI version did, giving you no indication how far along things have come.  Now the program displays what it’s doing (“Computing SHA-1 of…”) and then a percentage complete as it works.  Once complete, it displays the resulting hash as it did before. I thought about making the progress indicator “graphical” with little periods, hyphens, or equal signs, but the percentage was a lot easier to do (and I’m lazy).
  • Added a “case kludge” for comparing computed hashes against reference hashes (i.e. digests copied from a website). Typically, most sites will display hashes as a lower-case hexadecimal string, which is why I made that the default. However, I and other users have run into occasions where a download site presents the hash as upper-case hexadecimal. Unfortunately, if you paste this value into the comparison field on either the main WinHasher form or the “Send To” result dialog, the comparison will fail simply because the case does not match, even if the actual hash values do. Technically, you can tweak the command line of the “Send To” shortcut or change the output type on the main form, but either can be a pain when you know what you expect to see. So I’ve added a little bit of code that looks at what the comparison expects (i.e. “I’m looking for a lower-case hex string”) and adjusts the case of the comparison field if necessary. This means lower-case hex and Bubble Babble comparisons are forced to lower-case, while upper-case hex is forced to upper-case, no matter what case the original pasted-in string was. In the case of Base64, which includes mixed case characters, the comparison string is compared unaltered. After any case adjustment, the hash comparison occurs as previously designed.
  • Fixed a bug that wasn’t displaying the icon correctly within the application itself. Oopsy.

  For those who don’t know, WinHasher is a cryptographic hash generator for Microsoft .NET. It is roughly analogous to digest programs on other platforms (such as “openssl dgst” from OpenSSL) but designed for Windows and other .NET platforms. It lets you verify the integrity of downloads and determine whether changes have been made to files. It does NOT guarantee the authenticity of a file; for that, use cryptographic signatures such those produced by PGP or GnuPG. It also lets you create hashes of arbitrary text, which is handy for generating strong “passwords”, although I’m working on a different project that will do a much better job of this particular task. [Looks around shifty-eyed.]

  

• Security, Technology

  Need help: Removing old certificate revocation lists in Windows

  July 9th, 2009 (8 months ago) by Jeff | Permalink | Dump Core

  I have a bit of a quandary that’s got me effectively stuck on a task at my day job. Thus far, Google and every other resource I’ve searched have been little help. In the unlikely event somebody out there that reads this blog (or at least gets the update notices via RSS, Twitter, or the other various feeds) can help me, I’m going throw this out and hope it garners some feedback.

  I’ll try to keep this as short as possible. Our production Web site, built in ASP.NET and C# and running in IIS on Windows Server 2003, recently added authentication via client certificates stored on users’ smart cards. We allow users to attach their smart card certificates to their existing account, then authenticate them by verifying their certificate, looking up the user account by that certificate’s fingerprint, and loading their profile. These certificates are signed by a trusted third-party certificate authority (CA) owned by the client and every morning we download the latest certificate revocation lists (CRLs) so we can reject certificates as they are revoked by the CA. My download process is working fine and dandy, so that’s not the problem; neither is the actual import process, as I know the command line options for Microsoft’s certutil command that will import the CRLs.

  My problem stems from removing the old CRLs, which so far I haven’t been able to accomplish without going into the Microsoft Management Console and clicking through the GUI. We’ve had problems with the size of the certificate store, as the CRLs tend to be very large and we have to remove the old ones before the new ones can be imported. I’ve tried the few suggestions I’ve found online that haven’t seemed to work, such as a command-line switch for certutil that’s supposed to overwrite the old CRL with the new one (it just imports the new one and leaves the old one in place). We want to automate this process into a scheduled task, so it can run early in the morning when our users aren’t on the system and without human intervention.

  Here are the tools available to me:

  • As previously stated, certutil (part of Microsoft’s Certificate Services package);
  • Windows PowerShell;
  • Anything I can throw into a .NET assembly and build an executable out of (preferably C# code);
  • Good old fashioned batch files.

  I’ll tell you, I’m pretty frustrated and exhausted by this task. It’s not that I can’t do the research and figure it out for myself; I have done the research, and everything I’ve read applies to certificates and not CRLs, and they’re not exactly a direct swap in usage. I’d prefer not to provide much more detail than this for security reasons.

  For the time being, I’ve been manually removing the old CRLs through MMC and then running a batch script to do the import every morning as my first task. That’s working fine for now, when I’m in the office every morning, but I’ll be taking some vacation time soon that will start to cause problems. I swear, if this was OpenSSL and Apache on Linux, I’d have this solved in a heartbeat (or at least an afternoon). If you have any suggestions, please feel to post a comment or shoot me a direct e-mail at the usual address.

  

• Internet, Security, Technology

  Look, Ma! I’m on Security Now!

  July 14th, 2008 (1 year, 8 months ago) by Jeff | Permalink | 2 Core Dumps

  I hope to post more on this when there’s more data to post, but I thought I’d throw up a quick note stating that the latest episode of the Security Now! “netcast” features a question posed by yours truly. (The best part was listening to Leo Laporte stumble over my long-winded rambling. ) The high-quality version of the show can be found at the previous link; a low-bandwidth version as well as a text-only transcript can be found at the corresponding page at GRC.com. A search in the transcript for “Darlington” will take you to the beginning of my question; in the netcast, it starts around 38 minutes, 22 seconds in. (Of course, I encourage everyone to read/listen to the entire thing.)

  For the full effect, though, you’ll also need to listen to/read the previous two non-Q&A episodes of the show, #149 and #151. (Low-bandwidth and trascriptions can be found here and here.) The entire dialog concerns the recent trend of ISPs selling out their customers to allow third-party advertisers to come in and install hardware at the ISP to facilitate tracking the ISPs’ customers’ surfing habits across sites. While the ad companies in question claim to not be recording personally identifyable information about the ISPs’ customers, the capability is there and the possibilities for abuse are enormous. It brings back many shades of the DoubleClick controversies of the late 1990s-early 2000s, only much more ominous. I provided a unqiue standpoint to the discussion: that of a Web developer hosting a site and encountering similiar mysterious “first party” cookies set for my domain but not set by me.

  The full body my question is present, but I’m not completely satisfied with the answer. Let’s just say I think Steve Gibson made an assumption about the GPF site that’s not 100% true. I’ve replied to his response with additional information. I don’t necessarily expect another response (he does, after all, have his own agenda to follow on his show), and even if he does it will likely be in episode #154, the next scheduled Q&A episode. If anyone is interested, I’ll post updates if and when this occurs. If I don’t get a response, I’ll post my response here, especially since it contains some disturbing observations about “first party” cookies that have mildly paranoid folks like me nervous. (I’d hate to see what it does to really paranoid people.)

  

• GPF, Internet, Security, Technology

  Cookie cunundrum

  February 6th, 2008 (2 years, 1 month ago) by Jeff | Permalink | 15 Core Dumps

  By now, I’m assuming most of you have read Mondays GPF News item. (If you haven’t, shame on you.) GPF is leaving Keenspot, and I’m neck-deep in unit testing the new site with hopes of releasing it to beta testers soon. If you’re interested in beta testing, you can volunteer in this thread on the old forum.

  However, I’ve hit upon one little programming snag, so I thought I’d put out an appeal for help. I thought the blog would be more appropriate venue for this than the forum; that assumption could be wrong, but I’ll go with it anyway. For those of you with some Web-based programming knowledge, especially in the areas of PHP and cookies, please put on your thinking caps.

  As part of the new site, I’m implementing my own version of Keenspot’s PREMIUM service, reusing the old relabeling of GPF Premium. Keenspot PREMIUM is going away (for several reasons I won’t go into here), but as the service’s biggest proponent and largest beneficiary, I’d hate to lose that functionality. So the new site will launch with its own independent Premium functionality including all the old service’s features (optional ad-free surfing, weekly archives, High-Def archives, tons of exclusives like Jeff’s Sketchbook, etc.) plus a few new features that I’ve been wanting to implement but haven’t had the time or technological hoop-jumping expertise to work on at Keen.

  For security reasons, I want to secure Premium sign-ups and account management via secure HTTP (HTTPS). The benefits should be obvious. By encrypting account creation & management pages, you eliminate sniffing attacks and protect user privacy. While these pages may still be susceptible to other forms of attacks (and I’ve coded them to be as resilient as I know how), encrypting the traffic end-to-end can go a long way to cutting off those vectors of attack.

  However, I seem to have hit a brick wall when it comes to setting the Premium authentication cookie. Like Keenspot’s implementation, the subscriber’s browser will be “enabled” by “branding” it with a cookie, which will be read and authenticated each time the page is loaded. If valid, Premium features for that page will be turned on; if invalid, the page will default to a non-enabled state, which could be a simple as showing all ads or as complex as denying access to the content within. Unlike Keenspot’s implementation, which was JavaScript based, mine is scripted server-side in PHP, meaning it should be more accessible to a wider range of browsers and in theory more secure (no Premium content is sent at all if Premium is not enabled, rather than letting the client browser decide). My implementation has been thoroughly tested and appears to work pretty much flawlessly… with one hitch.

  The problem occurs when I set the cookie over the encrypted HTTPS connection, then try to read it over unencrypted HTTP. I appears that none of my test browsers send the cookie back when the encryption state changes. The reverse is the same; if I change the URL and set the cookie over HTTP, then try to access a page via HTTPS, the encrypted page can’t see the cookie either. It works like an either-or situation, when what I really want is both. If I set a cookie over HTTPS, I want to see it in both HTTP and HTTPS mode.

  PHP’s primary cookie interface is the setcookie() method (for setting) and the $_COOKIE array (for reading). setcookie() includes a boolean parameter for secure cookies, i.e. cookies that will only be sent via HTTPS. What’s annoying is that even when I set this flag to false to force it to be insecure, the scripts continue to exhibit the same behavior: cookies set via HTTP can only be read via HTTP and vice versa. I’ve also tried setting the same cookie both ways–first in one protocol, then the other, without erasing the first cookie–but that didn’t seem to work. The second cookie overwrites the first one, effectively turning it off.

  I had heard that IE 6 exhibited this behavior as a bug. However, I tried the exact same tests in Firefox 2.0.0.11, Opera 9.24, and Safari 3.0.4 (all on Windows) as well as IE 7, and all reacted the same way. Cookies set over HTTP could not be read over HTTPS and vice versa. It’s a bit frustrating. Obviously, I don’t want my Premium folks to be forced to use the new site in encrypted mode all the time, as this would slow down all the pages and put a significant extra load on the server as the number of subscribers increases. But I want to protect my users’ privacy and settings (and one of my important revenue streams) by encrypting their account access.

  So I guess I’m looking for answers to two questions:

  1. Is this some new standard of behavior that I’m missing? I was operating under the assumption that secure cookies (those set with the boolean secure flag) were restricted to HTTPS, but otherwise all other cookies should be sent regardless of whether it was encrypted or not. When I use the awesome Firefox Web Developer plugin, it tells me that the cookie should be there regardless of the encrypted state. Yet it still doesn’t get sent. But am I asking too much? Am I not understanding the specifications, or has something changed that I wasn’t aware of? Can I not have my cake and eat it too?
  2. 1. If I’m right and this should be working, what am I doing wrong? Is there a feature of PHP I should be use other than setcookie() to do this? Is it a bug, either in PHP or the browsers?
     2. If I’m wrong and this behavior is expected, is there a workaround I can use to let the same Premium features work over both HTTP and HTTPS? Or should I just give up on the encrypted account management and assume my stuff isn’t worth stealing enough to bother?

  Any responses via e-mail or (preferred) comments below will be appreciated.

  Update March 5, 2008: Thanks to the input of many commentors below, it looks like I’ve got a solution. The problem, as usual, was somewhere between the chair and the keyboard and the faulty component has been sufficiently flogged with a wet noodle. Immense thanks to everyone who provided feedback and suggestions.

  

• Internet, Security, Technology

  Disturbing: PayPal in cahoots with DoubleClick?

  November 27th, 2007 (2 years, 3 months ago) by Jeff | Permalink | Dump Core

  I don’t usually do link-and-run posts (I prefer to have actual content in a blog), but I thought this was disturbing enough to disseminate. I’ll probably add my own blathering commentary which will make it more than a link-and-run post anyway. (After all, I know all of you who come here really come for the blathering. I’m just so blatherful….)

  I’m not sure how many of you out there follow the Security Now! podcast over at TWiT, but it’s probably obvious by now that I do, given recent posts. This past week’s episode, #119, exposes a rather unsettling fact that shouldn’t be ignored. (The high quality 64kbps MP3 can be found at that link, while a 16kbps MP3, a transcript in various formats, and additional notes can be found here.) While I encourage you to download and listen/read the facts for yourself, I’ll see if I can summarize it below for the attention-span impaired.

  For a long time, I’ve defended PayPal as a method of monetary transfer. They’ve always been good to me personally, even during the stormy periods where some GPF readers boycotted them for “questionable” practices. (See the PayPal Wikipedia entry for an abbreviated history.) For that matter, many online comics wouldn’t be able to monetize themselves in any fashion if it weren’t for PayPal, as many webcomics use the service for donations and online stores. (PayPal has always been an acceptable form of payment in every incarnation of the GPF Store.) They’ve always had issues with customer service, but they’ve also been champions in anti-phishing campaigns.

  But Steve Gibson and Leo Laporte have helped disclose a rather shady new practice: In a previous Security Now! episode, a listener mentioned problems downloading a software service from PayPal, only to discover that the download link was sending him to a server over at DoubleClick rather than PayPal. Since he was locally blocking access to the domain “doubleclick.net” in his hosts file, the link failed and the software would not download. Gibson promised to investigate the incident and after a number of side-tracks finally presented his results.

  DoubleClick, for the few out there unfamiliar with it, is one of the Internet’s largest online advertising agencies, serving ad banners to millions of Web sites (including, indirectly, GPF). DoubleClick has long been unpopular among netizens for its questionable policies of tracking Web surfers across multiple sites, using a trick with tracking cookies to follow you from site to site. Privacy concerns were raised even further when Google, a company that itself stores and indexes a lot of personal information about its users of GMail, Ad-Sense, and other services, recently purchased DoubleClick. DoubleClick eventually bowed to pressure from the Net at large and created an opt-out page so their tracking cookie would contain “non-personally-identifiable information” and thus negate some of the tracking cookie’s effectiveness. (This opt-out page is still linked to (now indirectly, as the URL has changed) from the GPF privacy policy page.) Many folks these days, however, including myself, simply run spyware scanners like Spybot: Search & Destroy or Ad-Aware and periodically delete such tracking cookies, or just block the “doubleclick.net” domain and its subdomains using the hosts file trick mentioned above. (This is how, in part, Spybot’s immunization against cookies works.) This eliminates or at least minimizes the opportunity for your Web surfing habits to be linked personally to you.

  However, PayPal’s new links bypass many of these anti-drive-by-cookie-ing techniques by sending you directly to DoubleClick’s servers, rather than inlining content like Flash or images from their site. Since these are internal PayPal URLs and not links that are expected to send you to the outside, they should be immediately suspicious. What’s even worse is that if you examine the URL closely, there appears to be some sort of “user ID” like number included that may personally identify you if you click on it. What’s even more disturbing is the number of these links you run across as you surf the PayPal site; while some obviously ad-like images contain the “doubleclick.net” URL, many links in the site bar that look like ordinary navigational links contain it as well. While Gibson points out–quite rightly–that there is no evidence to support any sort of conspiracy theories that many come to mind, it is obvious enough that some sort of information sharing is going on between the two companies, and that if a unique user identifier is indeed being passed along with the URL, there’s a likelihood that both companies can link your potential spending habits with PayPal to your surfing habits tracked by DoubleClick.

  Now it’s easy to be alarmist and to say everyone should boycott PayPal. Unfortunately, so many of us in webcomics depend on PayPal for survival, so there’s no way we can easily remove ourselves from it. And there’s no competitor out there with enough critical mass to really challenge PayPal for dominance, so there aren’t many viable alternatives. Thus the only current immunization option is diligent observation.

  The good news is that the DoubleClick URLs within PayPal’s site all contain at the end PayPal URL you will eventually be redirected to. It’s trivial to copy the URL, paste it into your address bar, crop out the DoubleClick portion, and go directly the the PayPal internal destination. Laporte even suggested that it won’t be long before someone comes up with a Firefox plugin that does that for you on the fly. The problem I see with this is that it won’t be long before the diabolical duo figures out savvy users are bypassing the links and they find a better way to obscure the redirection target URL so the copy/paste/edit trick will no longer work. While true encryption might be a bit too much server load for them to handle en masse, a simple ROT13 or Base64 encode might be enough to thwart all but the most stalwart gearheads.

  So… should you avoid PayPal? That’s up to you. I can’t, but I’ll be a lot more careful of where I click on their site from now on.

  

• Internet, Security, Technology

  Roaming authentication with Apache mod_rewrite

  November 7th, 2007 (2 years, 4 months ago) by Jeff | Permalink | Dump Core

  I mentioned last week that I was working on a neat Apache mod_rewrite trick for locking down access to certain administration pages, but that I wasn’t having much success with it. Well, it seems to be working now and, as promised, I wanted to share it with anyone who might be interested. Fair warning to non-technical readers: extreme geekery lies ahead.

  First and foremost, I can’t claim full credit for this idea. It borrows some from Steve Gibson’s roaming authentication scheme outlined in episode #113 of the Security Now! podcast. In that show (and subsequently continued in episode #115), Gibson outlines his method of allowing his employees to access secure portions of his site while traveling. The method described here is not quite as secure as his, as I’m forcing things to happen at the Web server software layer as opposed to the application layer and thus don’t have the same fine granularity of control he has. However, it uses many of the same ideas.

  It’s relatively easy with mod_rewrite to protect certain resources of a site by restricting access to certain IP addresses. Consider the following:

  RewriteCond %{REQUEST_URI} ^/store/admin/.*
RewriteCond %{REMOTE_ADDR} !^192\.168\.13\.
RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1$
RewriteRule ^/store/admin/.* /store/ [R,L]

  This rule set essentially says: (1) if the requested URL starts with the string “/store/admin/” and (2) the IP address of the requesting client does not begins with “192.168.13.” or (3) is not exactly “127.0.0.1″ then (4) redirect all requests for URLs starting with “/store/admin/” to the root URL of the store, “/store/”. Essentially, we’re only allowing access to what is apparently the administrative portions of an online store to a very limited number of IP addresses, one of which is fully qualified (the “loop-back” address of 127.0.0.1) and the rest belonging to a range (192.168.13.0 through 192.168.13.255). Anyone outside these IPs will be transparently redirected to the front page of the store. (Redirecting is much friendlier than outright forbidding access.) All of this takes place in Apache itself, before we even get to the application and any potential security flaws it might have. There are no worries about hacking the store software itself to deny access. Of course, we can list any number of REMOTE_ADDR entries that we wish; each condition is a regular expression (which are negated here by the “bang” at the front) so we can filter on any octet we want and can easily specify real, outside IPs rather than private ones. For example, for this site I limit access to my various admin sections to the IP of my cable modem and our outside IP at work.

  However, what happens when you are required to go on a trip and need to access the administrative parts of the site while on the go? Obviously, you can’t add the hotel’s outside IP to this rule set in advance (imagine asking the front desk for that information), and you probably won’t be able to add it easily once you get there. Sure, WordPress and the store front software have login security on their various admin interfaces, but we’re trying to protect those from hackers, right? Aside from reopening them to the entire Internet before the trip and closing them again once we get back, there aren’t very many options. How then can we identify approved “roaming” users and/or machines so they can access the admin sites without being inside a hard-coded list of IPs?

  Gibson’s answer was to optionally set a secure cookie in the user’s browser if they access the admin site within one of the approved IPs first. Being within an approved IP, they aren’t restricted by the access rule and they are allowed to reach the login prompt. During login, they are prompted on whether or not they want to enable roaming access on this particular machine. If they agree, a secure cookie is set in the browser and set to expire at some date in the future. Later, when the user attempts to access the admin site outside of the approved IP list, the site checks to see if the cookie has been set. If present, the user is allowed to log in, just as if they were within one of the approved IPs. The cookie acts as a kind of two-factor authentication: the first factor being “something you know”, the user name and password, and the second being “something you have”, the cookie. Since the cookie is set in secure mode (HTTPS), it will only be sent back to the site over a secure connection. And since (well behaved) browsers only allow a site to read the cookies it has itself set, no other site should be able to read it.

  This is all well and good… if you have access to the source of the application you’re trying to secure and you’re willing to hack it. Gibson wrote his own store front, so this was relatively easy for him to integrate. But I want to secure WordPress, a third-party store app, and a few random subdirectories that are pretty much statically built HTML. As much as I like running Open Source software, I usually prefer not to muck around with things if I can help it, lest I screw something up. Thus, I don’t particularly want to hack WP and the store to add this extra layer of functionality. Fortunately, though, mod_rewrite gives us a mechanism through which we can accomplish basically the same thing without modifying the underlying application. In theory, since all this occurs before we even reach the application, one could argue it may even be more secure than the application’s authentication mechanisms themselves.

  You can actually set browser cookies via mod_rewrite rules. Consider what happens if we insert the following before the rules we defined above:

  RewriteCond %{REMOTE_ADDR} ^192\.168\.13\.
RewriteCond %{HTTP_COOKIE} "!(.+; )*admincookie=uniqueval(; .+)*"
RewriteRule .* - [CO=admincookie:uniqueval:.domainname.tld:43200:/store/]

  This rule set essentially says: (1) if the remote IP starts with “192.168.13.” and (2) there isn’t a cookie already set by the name “admincookie” then (3) set a cookie named “admincookie” with the value “uniqueval” for the domain “.domainname.tld” (assuming that’s our real domain name) for a period of 30 days (60 minutes x 24 hours x 30 days = 43,200 minutes) restricted to the path “/store/” and its subdirectories. Now let’s modify the rule set from before:

  RewriteCond %{REQUEST_URI} ^/store/admin/.*
RewriteCond %{REMOTE_ADDR} !^192\.168\.13\.
RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1$
RewriteCond %{HTTP_COOKIE} "!(.+; )*admincookie=uniqueval(; .+)*"
RewriteRule ^/store/admin/.* /store/ [R,L]

  Note that we’ve added a new condition. In addition to checking for the approved IP list, we also check to see if the “admincookie” has been set and that its value is what we expect (“uniqueval”). Note the parenthetical parts at the beginning and end of the cookie regex; these should make sure we match the unique cookie name/value pair, regardless of how many cookies are present. (Also note the quotes around this regex; since whitespace delimits the parts of the rewrite statements, the quotes are required to include the spaces after the semicolons in the regex. Without the quotes, the regex produces a “bad flag delimiters” error when Apache parses the configuration file.) Since each approved item’s entry is negated, the rule is only applied if none of them match. So now we should be able to get into the site remotely if and only if we’re inside an approved IP or we have the secret cookie, which we know is only set if we’ve been in one of the approved IPs first. Instant roaming authentication!

  To summarize, the primary advantages to this scheme are:

  • Restricts access to specific requested URIs to specific IP addresses and/or ranges and to machines outside those addresses that have a special roaming authentication cookie.
  • The roaming cookie can only be set from within one or more of the authorized IPs.
  • The cookie is set and checked at the Web server level, before the request reaches application code, so this scheme can be placed on top of third-party applications as an additional layer of security. No changes to the application layer are required.

  There are, of course, a few caveats:

  • Based on these rules alone, none of the information transmitted back and forth is encrypted; it’s all sent in the clear, which may potentially be sniffed by a man in the middle. Then again, you can always use mod_rewrite to force certain URLs to always use SSL (assuming you have a secure certificate), thereby securing the connection first. All WP admin functions, the GPF Store, and my other secured admin locales here on this site are all secured via SSL, so that helps in keeping my site secure by eliminating sniffing. (Of course, if you go this route, don’t forget to copy any necessary rules from the main Apache configuration file to the SSL config file, as the secure site will be treated as a different virtual host with its own set of rewriting rules. This little hiccup is what was keeping me from publishing this for quite a while.)
  • Forcing SSL, however, doesn’t necessarily protect the cookie itself. Gibson’s roaming authentication cookie required an SSL connection. This is called a secure mode cookie. While I’m still doing research into this, as far as I can tell so far mod_rewrite does not have the facility to specify secure mode in a cookie set by a rewrite rule. Thus, the above cookie is not secure and will be sent with each request in or below the specified path, encrypted or not. The cookie is then theoretically susceptible to sniffing attacks. Setting a secure mode cookie is easy enough to do in application code, but not apparently so in mod_rewrite.
  • The value of the cookie is currently hard-coded to a set value, and every browser accessing it within the approved IP will receive the same hard-coded cookie value. Ideally, the cookie should be unique to each browser and somehow obscured or, better yet, encrypted. Unfortunately, while I’ve been researching this also, so far I haven’t come up with a way to create such a unique token natively within mod_rewrite. (Remember, all this is occurring in Apache before we even reach application code.) Right now, I’m using a rather large hash of a unique pass phrase string I use a small command-line script to create a very long, highly random string using random numbers, several hashes, a little bit of Blowfish encryption, and some random string manipulation, but the cookie value is still technically hard coded. It may be possible to write a cron that will periodically create a new value token, update the Apache config file, and restart Apache. This will update the value every so often, but it seems quite a hassle. (Plus, the user under which the cron runs has to be root in order to modify both the config file and to restart Apache.)
  • Similarly, there’s no way to distinguish between browsers behind the approved IP. My desktop is unlikely to roam anywhere, so it technically doesn’t need the cookie. Meanwhile, if my parents bring their laptop over and visit this site from that machine while within my network, they’d get the roaming cookie as well. Neither of these scenarios are ideal. In application code, it would be simple to set the cookie only after the user has been authenticated by the app’s internal mechanism first. But we’re not working with application code; we’re rewriting URLs in the server. Thus, this becomes a different security concern: controlling access to the approved IPs, which could be both a physical (who can patch directly in via Ethernet) and a logical issue (who can access the wireless LAN). One thing I’ve done to get around this problem is to require the browser to be authorized for roaming access to first navigate to a very large (~50 characters), randomly-generated alphanumeric subdirectory alias (generated using the same command-line script mentioned above) that is highly improbably that some might guess. This alias can only be accessed within a single authorized IP address that I directly control. It is only then that the cookie set. This eliminates the unintentional cookie setting by casual browsing of the site from other machines behind the approved IP.
  • The regular expression to match the cookie should probably be more precise. For example, the expression as stated above could also match the string “myadmincookie=uniquevalnum2″, which technically isn’t what we want. Since we’re only dealing with cookies that should be set by our domain, it may not be that big of a deal, but it’s still a vulnerability nonetheless. If nothing else, there’s always the potential of colliding with cookies sent by other applications running on your site, so picking a unique cookie name and value is important. The %{HTTP_COOKIE} variable gets all the cookies for a given site/path as one big string, with each name/value pair delimited by a semi-colon and a space (“; “) and the name and value are glued together with an equal sign. I’m looking into a better regex to match this more precisely and I’ll update this post if I find one. I’ve updated the regex so it should match the cookie name/value pair more exactly.
  • Of course, none of this by itself can completely secure a site. In addition to this scheme, I force SSL on certain paths, deny access for all users to other paths that should never be accessed directly, and even explicitly block certain IP ranges that have attempted to hack the site. It’s not fool proof by any means, but combined with many other secure practices and mechanisms, it adds one more layer of protection, and sometimes one added layer can make all the difference.

  I welcome any feedback on how to improve this, especially if anyone knows how to get around the secure and unique cookie caveats.

  Appendium: I should also point out that this scheme should be equally usable if you place the code in your master Apache configuration file (usually something like /etc/httpd/conf/httpd.conf on UNIX clones) or in per-directory .htaccess files. I usually prefer to put such rules in the master config file, mostly because it’s more secure (outside of the document root) and only gets parsed and loaded once while .htaccess files are read and parsed each time there’s a request in that directory (or any of its subdirectories). However, that only works if you have access to the master config, which most shared hosting services don’t provide. Of course, such rules placed in an .htaccess file will only apply to that directory and its subdirectories, so you’d have to tweak the rules (such as file paths and the cookie path) as necessary.

  Update 11/20/2007: Updated cookie regex to better match the exactly name/value pair; added notes about rotating cookie values.

  Update 11/30/2007: Put cookie regex in quotes to correct avoid “bad flag delimiters” parsing errors; added advantage summary to better showcase the advantages of the scheme; updated my cookie value scheme; added highly-random subdirectory alias to avoid unintentional cookie-ing

  

• Internet, Security, Technology

  WordPress security tweaks

  October 31st, 2007 (2 years, 4 months ago) by Jeff | Permalink | 1 Core Dump

  If you guys haven’t figured it out by now, I’m been becoming quite the Internet security nut over the past few years. A thorough search of the Technology category reveals a good bit of my interests in SSH, SSL, public key cryptography, etc. Maybe I ought to experiment with subcategories and introduce a Security category under Technology….

  Anyway, WordPress usually includes some default feeds in the Dashboard after you log in, mostly from WP developers. One recent entry linked to a “geek ramblings” post about creating a secure WordPress install, which in turn references a WordPress security whitepaper over at BlogSecurity. (If you didn’t know any of these sites existed, don’t feel bad. Neither did I until today.) There’s lots of interesting reading there, especially if you’re (a) interested in securing your WordPress site and (b) you happen to be curious and/or adept enough to dabble in a number of arcane Web server settings. I happen to fit both of those criteria.

  One of the main reasons I’m mentioning this is that there might be a few changes and improvements for folks who have registered to comment. The site now redirects you to a secure SSL page on login, and your cookies will be stored in secure mode too, meaning they can’t be read unless sent over an SSL connection. This might require you to log in the next time you try to comment, even if you’ve told the site to remember you, because the old cookies won’t be secure and will need to be reset. Otherwise, you probably will never notice the difference unless you go to edit your profile, which most of you probably will never worry about once you’ve registered.

  The rest of the changes are all behind the scenes, so I won’t bother you with them. Just read the links if you’re curious. I’m experimenting with some arcane Apache mod_rewrite rules to really locking down the admin pages, all outside the scope of the links listed above, but so far those tests don’t seem to work. However, if I get them to do what I want, I might post them here (to give back to the community and all). It will be pretty sweet and borrows a few ideas from recent episodes of the Security Now! podcast (#113 specifically) to lock down access to the admin site from only certain locations or certain roaming computers.

  

• Security, Technology, Webcomics

  SIGGRAPH Key Signing Party?

  May 24th, 2007 (2 years, 9 months ago) by Jeff | Permalink | Dump Core

  As previously mentioned, I’m headed to SIGGRAPH in August. The pre-con report is now up on the GPF Shows & Cons site and, as usual, will become the core place for news and updates about my trip there. (I’ll probably end up mentioning the same stuff here as well, but that’s the official place to look.)

  It occurred to me yesterday while I was writing up a News item for Monday that SIGGRAPH may–or may not–be a good place to hold a key signing party. For those unfamiliar with public-key cryptography, this is a gathering where PKC users can verify each other’s identities, prove you are who you say you are, and obtain signatures on your public key. This increases your perceived level of trust; the more signatures you have on your public key, the more people who say they have verified your identity and thus the more trustworthy your own signature becomes. This “web of trust” is the core to PKC; without it, anyone could create a key and say they’re somebody else and there wouldn’t be an easy way to prove otherwise.

  I said it may be a good place for a key signing because there will be a lot of computer professionals there. It might not be a good place because most of those computer professionals are more involved with graphics than with cryptography (which is ironic because both require a great deal of mathematical knowledge). Thus, I’m not sure if I’ll be able to find anyone there willing to sign my keys or not. My public key has a pitiful few number of signatures, mostly because I haven’t been able to meet face-to-face with like-minded cryptography nuts to add any. I’ve searched and searched and have yet to come up with anything in this vein officially or unofficially attached to SIGGRAPH.

  So here’s a two-pronged appeal. First, if anyone does know of an official or unofficial key signing event somehow attached to SIGGRAPH or that might be going on in the area during that week, please let me know the details so I can somehow get involved. If there isn’t one going on, I’d love to see one organized. I’d consider organizing it myself if it weren’t for the fact that I’m not from San Diego and I don’t have a clue about where would be the best place to hold such an event, let alone how to get the word out. I’ve put my entry up on BigLumber’s San Diego listing in hopes that someone might see it, and at least one San Diego resident has expressed interest. If someone else might take the initiative to get things started, I’d be more than willing to promote it on the GPF site.

  

• Gadgets, Security, Technology

  Palm + WiFi + SSH + vi = geek2

  March 1st, 2007 (3 years ago) by Jeff | Permalink | Dump Core

  Last night, I was working on one part of implementing the GPF update changes previously mentioned. Since I’ve been having some trouble getting a response from the Keen Tech Crew (who I assume have been as busy with real life things as I have), I decided to try and implement a backup plan in case they couldn’t get their part done by Monday. It’s all rather technical… but then you guys probably enjoy reading my technical ramblings from time to time. (Either that, or you ignore the Technology category altogether. Take your pick.) Unfortunately, it involves some intimate knowledge of Keenspot’s update mechanism, Autokeen, which most of you probably don’t have.

  Long story short, Autokeen uses templates that are parsed by a massive Perl script that replaces certain “tags” with actual content. For example, the tag ***todays_comics*** gets replaced with the necessary HTML to display any images or text that have been designated as “comic” files. This obviously includes the images for the dailyweekly strip, but it can also use text and even Flash. The GPF News is treated as a “comic” by Autokeen, even though it’s all text. Unfortunately, while there can be multiple “comics” under one account (for GPF, they include the main comic, the News, the Sketchbook, the High-Def archive, and a few others), the way these templates are used means that each “comic” is pretty much autonomous and self-contained. There are ways to get cross-comic content (like how I get the most recent News date and blurb automatically on the main and High-Def pages), but it’s definitely not trivial and it stretches Autokeen’s capabilities beyond their original intended functions. Autokeen is incredibly flexible, which is a credit to Darren Bleuel’s design, but you can tell when you’ve taken it places it’s never been before.

  Anyhoo, I was building a Perl script that would be run on a cron to do some of this cross-comic work for me, just in case my original pure-Autokeen design didn’t work as expected. I was connected to the GPF server via SSH, editing the file directly on the server via vi. I tested it pretty thoroughly and was happy with the results. By this point, it was getting late, Ben was already asleep in my wife’s arms, and we were both ready to go to bed. I shut down the laptop, we took Ben back to his crib, and while she brushed her teeth and performed other nighttime preparations, I climbed into bed.

  It was then that I realized I had a fatal flaw in my code. (Nobody ever said inspiration was either punctual or convenient.) While it would successfully build some symbolic links on Monday, Wednesday, and Friday, I forgot to limit the code that removes the symbolic links on the other days of the week. Thus, every Tuesday, Thursday, and Saturday it would undo all the changes it made the days before. It was getting late and I had to get up early in the morning to head off to work. I didn’t have time to fire up the laptop again and I didn’t want to go into the office to log into one of those machines and leave my sweetie waiting up for me.

  I grabbed my LifeDrive and fired up its WiFi connection. I have a small SSH client for Palm OS called pssh and used it to log into the GPF server. Now pssh is a wonderful little tool, but anyone who has used a PDA probably knows that entering text into one can sometimes be… challenging. Palm has used Graffiti for years, but it can sometimes be a pain when working with applications that are very sensitive to text input mistakes (such as, say, vi). I elected to use the on-screen keyboard instead, and only switched to Graffiti when I discovered the keyboard didn’t have a pipe symbol (required to do a boolean “or” condition). Switching back and forth between edit and command modes was <sarcasm>fun</sarcasm>, even though pssh includes a nice little “ESC” button on the screen for emulating the Escape key. Old hands at vi will know you can always hit ESC multiple times to ensure you’re no longer in edit mode and that you’re back in command mode, but it seems I left the volume on the Palm up pretty high from listening to MP3s earlier. The default “bell” was embarrassing loud, especially with a sleeping baby lying a few feet away.

  It took some work, but I finally got the changes incorporated and saved and compiled the script. As soon as I logged off, I realized just out absurdly geeky the entire experience was. I probably could have done things faster if I had just walked into the office across the hall and fired up PuTTY, but instead I decided to do things the hard way: working on a tiny little battery-powered device, connecting wirelessly, and fumbling with awkward text input mechanisms to use what is arguably one of the most complex text editors to make what would have been a ten-second change anywhere else. For some reason I found that obscenely amusing. You could probably care less, I’m sure, but I thought I’d share anyway.

  

• Internet, Security, Technology

  Does everyone get paranoid in their old age, or is it just me?

  January 30th, 2007 (3 years, 1 month ago) by Jeff | Permalink | Dump Core

  In addition to switching blog software, I’ve been quietly making a few other changes on my little Linux box lately. For one thing, I’m changing the authentication scheme for SSH from simple passwords to public key authentication. Only a few friends and family have direct access to my Linux box, so it only affects a few people. However, given recent events, I feel somewhat justified in ramping up my security.

  On the off chance you might have read this into the above statement, no, my network hasn’t been hacked. No advance GPF strips or story notes have been swiped from my hard drives. (Somehow, I detect a definite sense of mixed feelings from some of you, including relief and disappointment….) But my oh my, have they been trying. Not that I think it’s a directed attack by any means, but I have had a number of break-in attempts over the past few months, and they seem to escalate frequently.

  Like I’m sure many Linux admins do, I run logwatch daily. (Actually, it seems to come pretty standard with an install of Fedora Core, but if I ever switch distros I’ll make sure to install it if it’s not a default.) logwatch runs through most of your system logs and generates a single, combined report summarizing the health and status of your computer and plants an e-mail in your root mail inbox every morning. It covers just about everything, from crons, Web and FTP logs (especially errors), mail, system messages, automatic updates, and (especially for the topic of this article) security logs. It was because of logwatch that I discovered that Demeter’s hard drive was failing last year and had to be replaced (more SMART failures, surprisingly undocumented either here or in the GPF News, and completely unrelated to Apollo’s crash; last year was not a good hard drive year for me). It’s through logwatch that I watch various IIS-targeted worms periodically bounce harmlessly off of Apache (which I take a small dose of perverse pleasure in). And it’s through logwatch that I sit nervously and watch the almost daily hack attempts to break into my system.

  Having any computer on the Internet is a dangerous thing these days. I certainly don’t want to alarm the less tech-savvy of you out there (the last thing I want is to discourage people from getting online), but any computer connected to the Internet is under a constant barrage of probes and pings. Most of these are harmless and often routine, but a growing number of them are malicious. Hackers are constantly scanning the Net for connected systems that may have vulnerabilities that can be exploited. Over the years I’ve grown more and more curious about Internet security, and I’m finding myself get more and more paranoid about how insecure much of the Internet really is.

  Having a server on the Net is just asking for trouble. They are under a constant assault, being poked and prodded from all sides and on every port. Most regular users have a small amount of anonymity through the dynamic IPs of their ISP. Servers, on the other hand, are meant to be found, waiting for requests (as their very name states) to serve. By their very nature they advertise themselves with domain names saying, “Here I am! I’m here to help you.” Being so public, they make themselves more visible to attack. While some black hat hackers target specific hosts looking for various bits of sensitive personal or corporate information, most of these hacks are actually pretty casual: simple probes looking for any random vulnerable system that can be broken into. Perhaps they may find something useful to exploit, like financial information or blackmail material. But my theory is that they are mostly looking for new weapons to add to their arsenal, additional zombies to add to their growing botnet collection.

  Virtually every day, my logwatch report comes up with at least several hundred break-in attempts via SSH. On especially nasty days, the attacks can range in the thousands. Gaining access via SSH is more advantageous than other means, as it gives you direct command-line access to the system which is also encrypted end-to-end, preventing eavesdropping by anyone in the middle. Needless to say, unencrypted telnet is completely disabled on my system.

  The good news for me, at least, is that I’ve taken quite a few precautions to prevent these break-ins. The first and probably most important step is to prevent root from logging in via SSH. In order to gain root access, an attacker must first compromise another login, requiring them to break two passwords instead of just one. This adds an extra step for me when it comes to my admin duties, but that’s an extra step I’m definitely willing to make. I’ve also limited which logins can access SSH to a specific group, into which are placed only users that I want to explicitly grant such access. This greatly reduces the number of available logins that can be compromised. (Most of these attacks try various combinations of common user names, so odds are they have no clue what user names may exist on the machine.) The next big step, though, is to require public-key authentication. This means that those with console access not only need a password but a digital private key, and only the combination of the two will allow someone in. This is the form of authentication SourceForge uses for access to their build and test environments, and it’s probably the most secure method freely available (usually implemented via OpenSSH).

  Setting up GnuPG keys, securely wiping old hard drives, and now locking down my Linux box with strong-grade encryption… I’m quite the paranoid little thing, now aren’t I? Does everyone get this paranoid in their old age, or is it just me? If you know the answer, you know where my public key is….

  Edit April 2, 2007: I tried to make a follow-up comment to this, but that obviously didn’t work. So I’ll just edit this post to include a link to this analysis malicious SSH login attempts article I just found. It made my flesh crawl a little. In addition, check out the following Linux.Com articles on beefing up SSH security. Thankfully, I’ve already discovered that I’m doing most of these tricks already, which made me feel just a tiny bit more secure.

  • Advanced SSH security tips and tricks
  • Protect SSH from brute force attacks with pam_abl

  

« Previous Entries

About

Jeffrey T. Darlington is the creator of the popular online comic strip General Protection Fault. He is also the creator of a number of other inconsequential things, but seeing as they are inconsequential, he didn't think you should be bothered by mentioning them. More...

Search

Capitalism

Recent

• Weekly Twitter Updates for 2010-03-06
• Weekly Twitter Updates for 2010-02-27
• Weekly Twitter Updates for 2010-02-20
• Weekly Twitter Updates for 2010-02-13
• WinHasher 1.6

Tag Cloud

Twitter GPF Writing Recycle Bin Security humor Technology Software TWiT WinHasher Webcomics .NET Linux Star Wars server meta podcast WordPress Microsoft cookie Steve Gibson Security Now virtual machine Wii Fedora mod_rewrite Doctor Who Windows Apache schedule blog advertising C# Star Trek PHP Help Desk Christmas authentication hard drive DoubleClick comments anniversary gifts To Thine Own Self PayPal