The Underpinnings

1. "A few weeks ago malware known as Zero Day was found to have exploited a vulnerability in Microsoft's Windows operating system"
   
2. "allow online criminals to take control of a computer from anywhere in the world without being detected"
   
3. "Serious threats like Zero Day"
   
4. "Windows runs on nearly 95 percent of the world's computers, which is why it bears the brunt of online assaults"
   
5. "The company is also scrambling to develop an update that guards against Zero Day"
   

1. Zero day is not a specific piece of malware but is a generic classification people use to refer to any malware that exploits an unpatched vulnerability or was recently released. It is most certainly not a proper noun.
   
2. Anything that allows online criminals to take control of a computer from anywhere in the world also allows them to do so undetected. The two issues are completely orthogonal and this bug is not much better or worse in the detection respect than any other similar vulnerability or mechanism for full control.
   
3. All vulnerabilities are zero day vulnerabilities at some point. Every last one. As for this specific vulnerability, it is one of the less serious types vulnerabilities as it requires user interaction and a compromised website to trigger. The serious vulnerabilities are ones that do not require the user to do anything but be connected to the Internet.
   
4. Windows may run on a vast majority of computers, but server operating systems often receive a large portion of attacks highly disproportional to their market share because people are much more interested in compromising servers than clients.
   
5. No, they're scrambling to provide an update to bug they've known about for many months now. They are doing nothing to prevent zero day attacks.
   

1. The answer to the question need to be something you'll remember or could easily find out.
   
2. The answer can't be something anyone else would know or could easily find out.

I recently found some SCADA boxes and got my adventuring companion to take a few pictures of them with her iphone. (Didn't have a camera on me.) I thought a few of you might be interested in the security you might find at these outlying sites.

The particular site we ended up seeing was the Black Mountain site which mostly contains cell antennas. It's easily accessible—you just climb the mountain—but it's remote enough where it's not closely monitored. Certainly if you snuck up there at night you could probably do anything you wanted. I didn't see any cameras either. The site looks like this:


The SCADA systems are nicely labeled:



And are protected with only the finest and most cutting edge security solutions available for under $20 at your local home depot:

(For those of you who don't like picking locks, a pair of metal cutters would do the trick equally well.)

The SCADA boxes aren't even located within any of the locked cages, but to get inside those isn't hard either. This was the typical lock configuration. Talk about the weakest link:


I was perplexed for some time on why they set things up this way and finally realized that they've got a bunch of different organizations using these sites and no common key distribution, so each organization just puts their own lock on the chain and that way each org's field maintenance people can get in without having to coordinate with the others.

I found it slightly amusing that I could throw a lock on there between the two links before their sets of locks and mess up their entire system. One wonders how long it would take before each organization to have their access restored to the site as they'd have to cut the chain and then redeploy each org's locks on there. It doesn't seem like they talk to each other all that well. Of course they could try cutting the lock, but I'm sure you could put a lock on there that would make them opt to cut the chain instead.

You'd think there'd be enough crazy "oh no cell phone towers are killing our children and making my back ache" people out there that you'd get a few who'd want to lock repair people out of these facilities, but I guess this type of attack just isn't that common...

Anyway. I didn't try hooking into any of the SCADA systems. (I didn't have a laptop with me either, this was a spur of the moment hey what's that on that mountain there, let's go climb it and see type of thing. Usually I'd have a small amount of equipment hanging around in my car, but she drove so I didn't have access to that.) So, I can't say for sure how easy it would be to enter their network here, but if you were looking for a place, this is one of many.

We probably have a few on campus too in the facilities complex if anyone wants to take a look.

$ wget http://websvn.kde.org/*checkout*/trunk/KDE/kdesdk/cmake/scripts/gencmake
$ chmod +x gencmake
$ mv gencmake ~/bin
$ cd ~/projects/projectname
$ gencmake

[  118.830022] ------------[ cut here ]------------
[  118.830026] WARNING: at drivers/gpu/drm/i915/i915_gem.c:2470 i915_gem_idle+0x179/0x341()
[  118.830028] Modules linked in:
[  118.830032] Pid: 5377, comm: X Not tainted 2.6.28.2-DJC-AES #5
[  118.830034] Call Trace:
[  118.830041]  [] warn_on_slowpath+0x51/0x6d
[  118.830046]  [] lapic_resume+0x171/0x1fc
[  118.830051]  [] _spin_lock_irqsave+0x23/0x2a
[  118.830056]  [] lock_timer_base+0x26/0x4b
[  118.830060]  [] try_to_del_timer_sync+0x46/0x4f
[  118.830064]  [] i915_gem_retire_requests+0xf2/0x114
[  118.830068]  [] i915_gem_idle+0x179/0x341
[  118.830071]  [] i915_gem_leavevt_ioctl+0x0/0x35
[  118.830075]  [] i915_gem_leavevt_ioctl+0x14/0x35
[  118.830079]  [] i915_gem_leavevt_ioctl+0x0/0x35
[  118.830083]  [] drm_ioctl+0x1d2/0x260
[  118.830087]  [] vfs_ioctl+0x55/0x6b
[  118.830090]  [] do_vfs_ioctl+0x373/0x3ae
[  118.830095]  [] vfs_write+0xcd/0x102
[  118.830098]  [] sys_ioctl+0x51/0x70
[  118.830102]  [] system_call_fastpath+0x16/0x1b
[  118.830105] ---[ end trace 3a06ac7332c964b0 ]---
[  118.873541] mtrr: no MTRR for 80000000,10000000 found

aes ~ # gunzip -c /proc/config.gz | grep -i drm
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set

aes ~ # gunzip -c /proc/config.gz | grep -i mtrr
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

aes ~ # xrandr -q
Screen 0: minimum 320 x 200, current 2624 x 900, maximum 2624 x 900
VGA connected 1024x768+1600+132 (normal left inverted right x axis y axis) 304mm x 228mm
   1024x768       60.0*+   75.1     75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     75.0     66.7     60.0     59.9
   720x400        70.1
TMDS-1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
   1600x900       60.0*+   60.0
   1360x765       60.0
   1280x800       60.0
   1152x864       75.0     75.0
   1280x720       60.0
   1024x768       75.1     75.0     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     66.7     60.0     59.9
   720x400        70.1

aes ~ # glxinfo | grep -v GL | grep -v extensions
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.4

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x22 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x69 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None