eEye Digital Security zero day tracker

eEye Digital Security have a Zero-Day tracker page to catalogue the latest zero-day exploits and vulnerabilities.


Link to zero day tracker here

Really Really persistent cookies

Extremely persistent browser cookies:

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.

evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.

Specifically, when creating a new cookie, it uses the following storage mechanisms when available:

• 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 Web History (seriously. see FAQ)
• HTML5 Session Storage
• HTML5 Local Storage
• HTML5 Global Storage
• HTML5 Database Storage via SQLite

And the arms race continues....

DNSMadeEasy DDoS

DNSMadeEasy.com suffering a sustained DDoS attack at the moment, somewhere in the region of 50Gb/sec!!

Another timeline generator

Part of my quest to find a great timeline tool that can be used for both forensics and network investigations.

http://www.learningtools.arts.ubc.ca/timeline.htm

Timeline tool

Just a reminder to the tool

http://simile.mit.edu/wiki/Timeline

as i always have trouble tracking it down

UPDATE

Now moved to http://www.simile-widgets.org/

Example of the sort of things it can do

http://www.simile-widgets.org/timeline/examples/jfk/jfk.html

Block, Quarantine or Delete?

Taken from http://www.sophos.com/blogs/chetw/g/2010/04/23/mcafee-fix-dangers-virus-handling

McAfee fix and the dangers of virus handling
from Security Bloggers Network by Chester Wisniewski, Sophos

In the security world the news has been dominated for the last 48 hours with tales of woe regarding the false-positive some McAfee customers encountered with svchost.exe. McAfee customers who have run into the problem can find detailed advice on fixing the issue in McAfee KB68780.

Our emotions regarding malware often lead us astray. Instinctively we want to delete or quarantine malware. McAfee's situation shows why this is a bad idea. According to their KB article if your system experienced this issue your copy of C:\Windows\System32\svchosts.exe has either been quarantined or deleted.

When I was in the Sales Engineering department here at Sophos it seemed to be a full-time job explaining to prospects why it was a bad idea to delete or quarantine viruses and other malware. Why on earth would I want a known malicious file to remain on my PC?

Upon the discovery of malicious code, anti-virus solutions are unable to determine with 100% confidence whether the file in question is required to boot, or required for the regular operation of your PC. As a safety precaution it is best to prevent access to the identified file, but leave it in place and by no means delete it. Viruses often infect critical drivers and other key components of the operating system. If you delete these files upon detection (or even move them) you create a much more difficult recovery process.

Fortunately in this case, McAfee customers are able to boot into Safe Mode and take the actions necessary to restore the computer to a fully working state. There is still a lot of manual work involved, but it does not require you to boot a live CD or USB stick to save the system. In cases where more important files have been moved it can be difficult if not impossible to fix once the files have been tampered with.

My Point? For everyday computers in your workplace the best practice is to attempt to cleanup viruses, but not move them to a central area or delete them permanently. For extremely risk-averse environments and mission critical systems you may wish to be more conservative and simply block access to the file and require a human to take action before making system modifications.

The good news is that false positives are few and far between. Recovery is difficult enough, don't complicate it more than necessary.

Take it from an expert - don't transport malware around your computer/network, clean it up in place, and do your best to do no harm.

DNS Monitoring Script

Script to monitor dns requests on an interface, can be behind tap and then forward result to syslog for collection. Scripts a bit dirty and probably not very well constructed but appears to do enough.

Main bulk of script unashamedly ripped from

An Ajax-Enhanced Web-Based Ethernet Analyzer

Main Ruby script

dns-watcher.rb

------------------------------------------------------------
#! /usr/bin/ruby -w


# following packages required on ubuntu
# apt-get install rubygems
# gem install net-dns - no longer works as version updated to 0.6 use 0.5.2 from http://rubyforge.org/frs/?group_id=721&release_id=35799
# apt-get install libpcap-ruby*

require 'rubygems'


require 'net/dns/resolver'


require 'syslog'



require 'pcap'

require 'net/dns/packet'

capture = Pcap::Capture.open_live( 'bond0', 1500 )

capture.setfilter( 'udp port 53' )

# NUMPACKETS = 5000

puts "#{Time.now} - BEGIN run."

$log = Syslog.open('dns_logging', Syslog::LOG_PID, Syslog::LOG_LOCAL1)

capture.loop do |packet|

dns_data = Net::DNS::Packet.parse(packet.udp_data)

dns_header = dns_data.header

if dns_header.query? then

print "Device #{packet.ip_src} "
print "(to #{packet.ip_dst}) "
print "at #{Time.now} looking for "
question = dns_data.question
question.inspect =~ /^\[(.+)\s+IN/
puts $1
if $1 != nil
$log.info("dns queried for " + $1)
end

STDOUT.flush

end

end

capture.close

puts "#{Time.now} - END run."

---------------------------------------------------------------

Bash wrapper to start the script

dns-watcher

---------------------------------------------------------------

/bin/bash

case $1 in
start)
echo $$ > /var/run/dns-watcher.pid;
exec 2>&1 ruby /home/dns/dns-watcher.rb 1>/tmp/dns-watcher.out
;;
stop)
kill `cat /var/run/dns-watcher.pid` ;;
*)
echo "usage: dns-watcher {start|stop}" ;;
esac
exit 0

------------------------------------------------------------

Script can be started with

dns-watcher start &

and stopped with

dns-watcher stop &

Sometimes the script unexpected and my lack of coding skills stop me from understanding why so I use Monit to monitor the process and restart it if need be.

Monit config - follow normal rules for getting Monit to work and then add the lines below specifically for the dns-watcher script

--------------------------------------------------------------

# Monitor Ruby process for dns-watcher

check process dns-watcher with pidfile /var/run/dns-watcher.pid


start program = "/home/dns/dns-watcher start &"
stop program = "/home/dns/dns-watcher stop &"

---------------------------------------------------------------

Can use something like phpLogCon to monitor syslog output

USB Device Forensics

Taken from Windows Incident Response by Keydet89

I posted to the Win4n6 Yahoo Group on USB removable storage devices and tracking connections, and got some really good confirmation from Rob Lee, so I thought I'd share it here, as well.

So, when I was writing WFA 2/e, I did some testing and found that when connecting a USB removable storage device to a system, beneath the unique instance ID key (under the DeviceClasses key), a Control subkey was created, and when the device was disconnected, the Control subkey was deleted. The creation/deletion of this subkey constitutes a modification to the unique instance ID key, updating the key's LastWrite time and allowing us to track the usage of the device.

However, there appear to have been changes to this functionality since then, and Rob's more expansive testing has confirmed my own. Essentially, if you sit down to a running system (XP SP2 or 3, Vista, Windows 7), and plug in a USB removable storage device (even one that's been previously connected to that system), you'll see the Control subkey created...but when you disconnect the device, the Control subkey will remain until the system is rebooted. Rob has confirmed that this LastWrite time survives logins, as well.

So, now the LastWrite time on the unique instance key refers to the time that the device was last connected to the system, which is an important distinction to make when performing analysis of the usage of these devices. This requires further testing for more complete confirmation, but this is how things appear at this time. Shout outs to Rob Lee for the testing on this!

So this should give us a bit more on when and should look to automate it if possible