Windows 7 – My Take

October 15th, 2011 by sjan

Having just completed a Microsoft certification (MCTS 073-680) I have learned more about Windows 7 (and some about Server 2008 R2) than I have in over a year of using it. To be fair, I do not use Windows 7 as my primary platform, but I do use it in a VM on a fairly regular basis. For the most part I pretty well like Windows 7, at least as far as Windows goes. But that is not the primary point of this post. I would like to point out what I feel are some security-related pros and cons of some new (and some not-so-new) features in Windows 7 and Server 2008.

BranchCache: In a typical main office / branch office setup with a file server in the main office, every time a user in the branch office opens a file from the file server (in the main office) it travels across the WAN link. This is not only a waste of limited bandwidth, but it is slow, leading to things like users copying files to their local machine, grabbing copies of several files onto a thumb drive while in the main office and even (I have seen this), emailing the file to their private (non-work) account. BranchCache helps out here, with only one copy of any file accessed going across the WAN to be cached in the branch office (thus the name). Every time the file is opened after that in the branch office it is opened from the local copy. The only time files are transferred across the WAN again are when they are modified on either end.

  • Pros:
    • Removes the need for users to come up with “creative” ways to get copies of files from the main office to work on.
    • Files are encrypted in transport.
    • Only one copy of any file is ever cached at the branch office, and it is kept up-to-date with the version at the main office.
  • Cons:
    • Requires Server 2008 R2 at the main office, with Active Directory and Certificate Services.
    • Using “Hosted” BranchCache (where the cache is held on a server in the branch office) requires Server 2008 R2 with Active Directory and Certificate Services at the branch location as well.
    • Using “Distributed” BranchCache (where the cache is held on the peer user machines in the branch office) can lead to more trips across the WAN for the files, since whenever a machine is powered down or unplugged from the network part of the cache goes down with it.

BitLocker: Full-drive encryption. Sweet! But … ?

  • Pros:
    • With a TPM the entire drive can be encrypted.
    • With a TPM, removing the drive and placing it in another machine means it will not boot without the presence of a recovery key.
    • Can require a USB key and password to boot.
  • Cons:
    • Without a TPM the drive cannot be locked to a particular boot environment.
    • With a TPM BitLocker can be configured to boot with nothing more required than the TPM itself. If you set it up this way, why bother? The machine will boot and the drive’s contents will be available regardless.
    • Only available for Windows 7 Enterprise or Ultimate editions.

Network Access Protection: This is a really good idea, and not limited to Server 2008 R2, but around since Server 2008. NAP allows a server to check connecting clients (either through VPN or DirectAccess) to make sure they are up-to-date with OS patches, have the proper version and patch level for software and anti-virus and are not running anything blocked through Group Policy Application Security settings.

  • Pros:
    • Computers that do not pass the NAP requirements can be shunted off to a quarantine network where the needed updates can be pushed to the computer before they are allowed to connect to the internal network.
    • NAP can enforce Application Security policies, and can keep remote users up-to-date with the patches and application versions used in the internal networks.
  • Cons:
    • NAP requires that connecting computers have the proper settings in their local Group Policy Object to allow DHCP or IPSec NAP Enforcement, which can make implementation difficult if they are not connected internally first, to get those Group Policy settings pushed to them.
    • NAP is likely to make some users unhappy when they cannot simply log on to the VPN and start to work, but instead are forced to wait for updates. This could cause the sort of push-back that makes admins likely to scrap these sorts of setups.

DirectAccess: I am so unsure about this one. The definition from TechNet:

DirectAccess allows remote users to securely access internal network file shares, Web sites, and applications without connecting to a virtual private network (VPN). ... DirectAccess establishes bi-directional connectivity with an internal network every time a DirectAccess-enabled computer connects to the Internet, even before the user logs on. Users never have to think about connecting to the internal network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.

  • Pros:
    • DirectAccess connects via ports 80 and 443, meaning that it works from within most firewalls (in hotels, coffee shops, airports, etc).
    • Even when connecting via port 80 all DirectAccess communications are encrypted.
    • Bi-directional access means that admins in the internal network can access the connected machine as if it was in the internal network to push out Group Policy changes, provide remote assistance, etc.
  • Cons:
    • DirectAccess connects before the user even logs on. This means that if the machine is on and has internet connectivity it is connected to the internal network.
    • Since it does not require the user to take any action to connect (like connecting to a VPN) the user is less likely to be aware that anything they download (like this “really cool Java game”) also has access to the internal network.

A scenario: Company A and Company B both have Windows networks with Server 2008 R2 and traveling users with Windows 7 Enterprise laptops with a TPM. Both companies have set the laptops up with BitLocker full drive encryption and boot protection. Both companies have set the laptops up with DirectAccess. Company A is quite a bit stricter than Company B, however. Company B’s laptops are set to boot automatically without a USB key or password, while Company A requires both. Further, the local Group Policy security settings on Company A’s laptops will log the user off and shut down the computer if the USB key is removed. Company A has gone a step further in implementing NAP to ensure that all their traveling computers are always up-to-date.

While User A (from Company A) and User B (from Company B) are having drinks in an airport lounge their laptops are stolen. Both User A and User B think p@ssw0rd is a good enough password. The thief opens the laptop from Company A and cannot boot it without the USB key which is in User A’s pocket. The Company A laptop is only as useful to the thief as the hardware. The Company B laptop, however, will boot (automatically decrypting the drive) and will also connect to Company B’s internal network. A couple guesses later the thief is logged on as the laptop’s user and connected to Company B’s internal network with all the access that the user would have were they plugged in locally.

There is room to implement a great deal of security in Windows 7, but there is also a lot of room to totally mess it up. As I said earlier, I am not sure that DirectAccess is such a good idea, but I guess it depends on how the rest of the system is configured and how well users are educated.

Data breach for Kroger

April 2nd, 2011 by sjan

Just got an email today from Kroger saying that they had suffered a data breach and to (essentially) watch out for spam. The text of the message:

Kroger wants you to know that the data base with our customers’ names and email addresses has been breached by someone outside of the company. This data base contains the names and email addresses of customers who voluntarily provided their names and email addresses to Kroger. We want to assure you that the only information that was obtained was your name and email address. As a result, it is possible you may receive some spam email messages. We apologize for any inconvenience.

Kroger wants to remind you not to open emails from senders you do not know. Also, Kroger would never ask you to email personal information such as credit card numbers or social security numbers. If you receive such a request, it did not come from Kroger and should be deleted.

If you have concerns, you are welcome to call Kroger’s customer service center at 1-800-Krogers (1-800-576-4377).


The Kroger Family of Stores

And now, why I am not in the least concerned.

  1. Kroger is the parent company of 29 supermarket, warehouse, discount grocery and convenience store chains, 4 jewelry store chains and 3 financial services companies. I have a “rewards card” type account at one of those 29 grocery-type places that links my email address with my name. However, I do not have an online account with any of them. (I don’t see the need to create yet another account to “log in” to the web site of a store down the street to print the same coupons they send me in email and physical mail.)
  2. I do not have any payment methods tied to that account (obviously, as I have no “online account” with them.)
  3. When I am sent details of my coupons and money-back rewards I get those via email with a link to view them. Sure, someone sniffing on the wire could get the link and print out my money-back certificates. But they are tied to the physical “rewards card” I have with the store, so they don’t really do anyone else any good unless they clone my card.

So, even though I am not particularly worried about this data breach (especially since my real name is tied to that email address in lots of publicly available places on line) I do have to give Kroger credit for informing their customers. Now I am just hoping they release a little more information about how it happened, what steps they took, etc. Are you listening, Kroger? Thanks.

Edit: @Tekneek pointed me to this article by Brian Krebs. According to Krebs’ article it looks like their email marketing service provider Epsilon was breached.

Looking into evercookie

September 23rd, 2010 by sjan

Things have been rather quiet around here lately as I have been busy with work and school. Something in my twitter stream yesterday caught my eye, though. It seems that Samy Kamkar has come up with a way to make a seriously persistent cookie. How does it work? By storing the cookie value in (currently) 10 different methods.

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in and reading out Web History
  • Storing cookies in HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

It seems from the site that this is a project in current development with even more methods to come. Currently the only mitigation is using Safari in Privacy Mode which destroys all versions of the evercookie on browser restart. In the coming weeks I will have some time to spend on personal projects, and I may use some of that time to look into this further.

Fix for firehol get-iana script

June 28th, 2010 by sjan

I have talked before about using firehol to configure iptables. I won’t go into all the details about how wonderful and awesome it is, but trust me, it makes configuring iptables a snap.

Firehol includes a script,, that downloads the IPv4 address space list from IANA and populates a file called RESERVED_IPS that firehol uses when configuring iptables. Basically, any traffic from outside coming from any reserved or unallocated IP block is dropped automatically. As you can imagine, keeping this file updated regularly is important, as previously unallocated blocks are allocated for use. To this end, whenever firehol starts it checks the age of the RESERVED_IPS file and if it is older than 90 days warns you to update it by running the supplied

However, there has been a change recently in how the IANA reserved IPv4 address space file is formatted. There are lots of posts on plenty of forums with patches for to accept and use the new format plain text file (while the default is now XML rather than plain text) and needless to say I tried every single one I could find. None of them worked, so what to do? How about a complete rewrite in Python? And while we’re at it, let’s use the XML format that IANA wants everyone to use.

So, one lunch hour of hacking and here it is, working like a charm. You can copy this, but I recommend downloading it to avoid whitespace issues.



Replacement for that ships with firehol and no longer seems to work.
This is less code, less confusing, uses the preferred XML format from IANA and works.

Copyright (c) 2010 Sjan Evardsson

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.


import urllib
import xml.dom.minidom
import os
results = []
x = xml.dom.minidom.parse('address-space.xml')
for i in x.childNodes:
    if i.localName == 'registry':
        for j in i.childNodes:
            if j.localName == 'record':
                for k in j.childNodes:
                    if k.localName == 'prefix':
                        prefix =
                    if k.localName == 'status':
                        status =
                if status == 'RESERVED' or status == 'UNALLOCATED':
outfile = open('iana-temp','w')
for r in results:
    hi = int(r.split('/')[0])

Botnet on port 23130?

September 19th, 2009 by sjan

Yesterday evening my roommate’s machine was botted. I got a text message to my phone from Pingdom that my site was down and I did a bit of digging and found that his machine had somewhere in the range of 80-100 open outbound connections at all times.

I notified him and he immediately went to TrendMicro House Call to clean it up. He said it found “a few things,” but he didn’t note what they were, nor did he try to isolate them so I could attempt to decompile and inspect them. Ah well, such is the world, and he had work he needed to be able to finish with his machine.

The odd thing was, once his machine was cleaned and no longer in contact I began to get a flood of TCP SYN packets and UDP packets to the server on port 23130. The size of the UDP packets (between 75 and 196 bytes) leads me to believe they were some sort of botnet commands, while the TCP SYN packets were bots trying to reconnect to their lost buddy. This definitely did not have the marks of a DDoS of any sort, as once the bot on the Windows machine was stopped (and I once again had outbound bandwidth) the packets were hitting the server in a fairly steady fashion, but not in any kind of flooding behavior. In other words, each host was trying no more than 5 times to connect via TCP and no host sent 2 identical UDP packets in a row. The reason they were hitting the server is that the packets were being sent to a specific IP address, and trying to create a new connection with that IP means you are trying to connect to the server. Without the established connections in NAT on the router, all these packets were going to the server. Unfortunately the server in question is not beefy enough to run tcpdump, even for a few minutes, and trying to alter my network enough to get my laptop in where it could sniff the packets was out of the question.

While I didn’t have tcpdumps or even extensive firewall logs I did have the abbreviated logging that takes place in messages. (I also had dmesg logs to look at, but I never realized until last night that dmesg logs are not timestamped. I wonder if that is a configuration error on my part. Right now I am too exhausted to try to figure that one out.) So, I had the log entries in /var/log/messages and there is plenty good information there – and here is what I saw, from the hours of Sep 18, 19:16:59 to Sep 19 03:06:49. (Note that the packets are still coming in, but now at a rate of somewhere around 2 attempts per hour.)

There were a total of 178,335 TCP SYN packets to port 23130, along with 33,894 UDP packets to the same port. These requests came from 1,994 unique IP addresses. Below are some interesting statistics.

Top ISPs by number of unique hosts
ISP Country Hosts
Comcast Cable Communications United States 129
Abovenet Communications, Inc United States 119
Road Runner HoldCo LLC United States 92
AT&T United States 77
Shaw Communications Inc. Canada 51
Verizon Internet Services Inc. United States 41
Cox Communications Inc. Canada 34
Rogers Cable Communications Inc. Canada 26
Bell Canada Canada 19
Charter Communications United States 19
All countries by number of unique hosts
Country Hosts
United States 643
Canada 152
United Kingdom 135
India 117
China 67
Philippines 65
Australia 62
Malaysia 39
Japan 33
Russian Federation 32
Mauritius 30
Netherlands 30
Portugal 27
Uruguay 25
Pakistan 22
United Arab Emirates 22
Spain 21
Greece 21
Romania 19
Thailand 19
Poland 19
Saudi Arabia 18
Germany 18
France 18
Bulgaria 16
Norway 16
Singapore 16
Korea, Republic of 15
Taiwan, Province of China 13
Brazil 13
Viet Nam 12
Italy 11
Turkey 11
Mexico 10
Sweden 9
Croatia 9
Finland 9
Israel 9
Ukraine 8
Hong Kong 7
Ireland 7
Argentina 7
Switzerland 6
Denmark 6
Estonia 6
Cyprus 6
Czech Republic 5
Kazakhstan 5
Chile 5
Qatar 5
Belgium 5
Sri Lanka 5
Latvia 4
Iran, Islamic Republic of 4
Indonesia 3
New Zealand 3
Slovakia 3
Dominican Republic 3
Serbia 3
El Salvador 3
Slovenia 3
Unknown 2
Kuwait 2
Trinidad and Tobago 2
Brunei Darussalam 2
Costa Rica 2
Bangladesh 2
Venezuela, Bolivarian Republic of 2
Hungary 2
Moldova, Republic of 2
Barbados 2
Puerto Rico 2
Aruba 1
Malta 1
Ecuador 1
Bahamas 1
Austria 1
Peru 1
Montenegro 1
Angola 1
Guatemala 1
Paraguay 1
Antigua and Barbuda 1
Lithuania 1
South Africa 1
Palestinian Territory, Occupied 1
Aland Islands 1
Macao 1
Jamaica 1
Honduras 1
Oman 1
Iceland 1
Guam 1
Bahrain 1
Albania 1
Nepal 1
Luxembourg 1
Iraq 1
Afghanistan 1

Edit: Mostly I am curious about the botnet in question. If anyone comes across a bot that is communicating on port 23130 please let me know what you find out about it.

Data Scrubbing: Is there a right way?

September 9th, 2009 by sjan

An article yesterday from ars technica got me wondering. In my former position we often “scrubbed” databases for sample data from which to work. And certainly one can see the value in working with data with personally identifiable information removed for the purposes of business or health-care informatics, service level determinations, quality of service surveys, and so on. Yet, according to a study at Carnegie Mellon University:

87% (216 million of 248 million) of the population in the United States had reported characteristics that likely made them unique based only on {5-digit ZIP, gender, date of birth}.

This seems to be the balance point: 3 pieces of non-anonymized data are enough to identify the majority of the population. (Think, “Three Strikes! You’re out!”) So what do we do when we need solid, anonymous data from which to work?

Taking the example of the health records from the article linked above, I would think that the following steps would be enough to fully scrub the data beyond where “reidentification” would not be possible. Since this is medical records we can safely (I feel) assume that randomizing the gender is a non-starter. (“Wow, according to this data 14% of all men went to the Emergency Room with pregnancy-related complications!”)

And since this data is taken from an area where the zip codes are known we are already at two strikes. So why did they not randomize the dates of birth? It would be difficult to do in the case of infants beyond a few days or weeks, since many of the health issues are related to their age in months. But for anyone over the age of 8 it should be simple enough to randomize the month and date of birth, and allow a set of ranges for randomizing the year of birth. If we assume a 20% range up or down we gain a lattitude of possible years of birth which increases the older the patient actually is. Another possibility is to give everyone the same date of birth, differing only in the year. (Jan 1, xxxx).

This of course means that any reporting done on age is meaningless, but it also means that the data can more safely be widely distributed. In cases where exact age and gender are required for study it would be better to merge data from many different areas, covering as many cities, counties, states and regions as possible. In this case we would still need to weigh the risks, as all three pieces of data would still be available, although at a much higher level of trail and error. In the case mentioned by ars technica the study covered seven zip codes. Perhaps spreading the information over a few hundred would make it much less worth the effort to sort through them all to try to identify individuals, and even then one would expect multiple possible hits.

The need for real data for statistical analysis and study is not going to go away. When you are considering releasing scrubbing data to release a “sanitized” version it would be good to keep the mantra “Three Strikes! You’re out!” in mind. When it comes to data for testing software operation, however, I still think the better method is complete randomization. Totally bogus data that has the look and feel of “real” data. (Which is no doubt why all the bogus users in my test dbs live in different cities, in different states, and at addresses ranging from 123 to 999 on Any Street!)

Interesting log activity

June 6th, 2009 by sjan

While trying to debug the Shorten2Ping plugin (a really nifty thing, if I could get it working) I went digging through my Apache error logs looking for any PHP errors. (Well, okay, I didn’t actually dig, I just did a last on the file.) What I saw was interesting, even though it did not help the debugging at all. In fact it kind of derailed the whole process. What I saw was an obvious attempt to find Horde on my server (which I did run temporarily a few years ago). My first guess was that there was a new exploit out for Horde. I did some digging around and found that, yes, indeedy, there is. I found the details of the exploit at (which is a mirror of or mirrored by which is where the first relevant Google link took me.) Oddly enough I have not seen this show up on any other security sites yet, even though I see that the report on is from March.

Anyhow, in case you are curious, here are the relevant lines from the log. (IPs have not been changed to protect the guilty.)

[Sat Jun 06 01:46:53 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:53 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:54 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:55 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:56 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:57 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:58 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:58 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:46:59 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:00 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:01 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:02 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:03 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:03 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/
[Sat Jun 06 01:47:04 2009] [error] [client] File does not exist: /var/www/localhost/htdocs/

New Class of Exploits: Dangling Pointers

July 23rd, 2007 by sjan

While dangling pointers are a common coding error (especially in C++) there has previously been no way known to exploit them. In fact, they were generally considered a quality control issue rather than a security issue. That is all set to change. According to an article today from SearchSecurity Jonathan Afek and Adi Sharabani of Watchfire Inc have uncovered a way to exploit generic dangling pointers to run shell code on a server in much the same fashion as buffer overflows. According to Danny Allen (also of Watchfire) this technique can be used on any application with dangling pointers.

Afek will be giving a presentation on the technique in August at the Black Hat Briefings in Las Vegas.

Technorati Tags: ,

Web 2.0 Attack – AJAX Vulnerable to JavaScript Hijacking

April 2nd, 2007 by sjan

A white paper from Fortify Software outlines a major Web 2.0 Vulnerability. According to the white paper, all current frameworks that use JSON for data communications are vulnerable. They have released the information to all the major framework developers so that this can be addressed within the AJAX frameworks. They noted, however, that one quarter of the participants in an AJAX survey hosted by Fortify did not use any framework at all. Fortify recommend a two-pronged mitigation approach:

  • Include a hard-to-guess identifier, such as the session identifier, as part of each request that will return JavaScript. This defeats cross-site request forgery attacks by allowing theserver to validate the origin of the request.
  • Include characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a <script> tag to witness the execution of the JavaScript.

Computer Business Review has a more extensive write-up available.

Technorati Tags: , ,

DNS Root Servers Attacked

February 6th, 2007 by sjan

At least 3 of the 13 global root servers were briefly overwhelmed in a sustained attack last night, lasting, in some cases, as long as 12 hours. Looking at the RIPE NCC DNS monitoring service it seems that 2 of them, G (US Dept of Defense) and L (ICANN) were having the most difficulty dealing with and recovering from the attack.

At this point the attacks seem to have been aimed at UltraDNS, which primarily handles traffic for .org sites.

While there is as yet no mention of who is suspected or what their motives may be, there was a similar attack last year on UltraDNS.

The AP’s report is here.

Technorati Tags: , , ,