Fixed links to SpyHunter Challenges

Google Drive made some security changes a few months back, which caused the links to my SpyHunter Challenges to break. I have fixed those links now. Thanks for letting me know that they were broken.

Upgrade VMWare vSphere 5.5 to Update 3b

To upgrade your ESX 5.5 server to 5.5 Update 3b, you will need to do the following:

1) Shutdown all running VMs

2) Put ESX in maintenance mode
> vim-cmd /hostsvc/maintenance_mode_enter

3) Enable the outbound HTTP client through the ESX firewall
> esxcli network firewall ruleset set -e true -r httpClient

4) Perform the upgrade to 5.5 Update 3b.  As always you can get information about this update or other updates on the VMWare knowledge base here and here
> esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20151204001-standard

5) Reboot the ESX Server

6) List available updates that came out after the Update3b.  You want the standard one and it can take FOREVER for it to complete, say more than 5-10 minutes with no feedback.  You may see versions that include an "s" at the end of the filename, these profiles only contain security patches, not other bug fixes.  These security only versions would be for those organizations that are restricted by their change control board from patching anything but security fixes.
> esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-5.5 | grep standard | grep 2016

7) You will see from this list that there is another update, as of today.  It is called ESXi-5.5.0-20160104001-standard.  If you wanted more information about this update, you can go to the VMWare Knowledge base and search on "vmware esxi-5.5, patch ESXi-5.5.0-20160104001"

8) Perform this update as well
> esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20160104001-standard

9) Reboot the ESX Server

7) Exit maintenance mode:
> vim-cmd /hostsvc/maintenance_mode_exit

Spy Hunter Holiday Challenge 2015

This holiday season I have created another network forensics challenge for the community to try and solve. This scenario called “Spy Hunter – Operation Ares” is the second in a series that follows the questionable activities of Insider1.

All solutions should be submitted to me at Jordan 2175 with no space at Google’s mail service no later than December 20th, 2015. Winners will be announced in January. Entries will be rated based on completeness and overall explanation of what happened and how.

Please NOTE I will NOT accept any documents in PDF or Word format.  Only plain text email and documents, something readable by pine, vim or emacs, will be accepted. By submitting a solution you grant me the right to list your name on this blog.

Good Luck.

PDF: https://drive.google.com/file/d/0By0KeB0IEqeTNnd1WUFHQmt0TzQ/view?usp=sharing&resourcekey=0-B6SOqOuNK2Eh4vV7HrWp8w
MD5 (SpyHunter-Operation_Ares-ver1.pdf) = 5b428889accb3f7760c4418bb5b5b629

PCAP: https://drive.google.com/file/d/0By0KeB0IEqeTaHZDdWhMNUR2T00/view?usp=sharing&resourcekey=0-_GJ38BPGpaVsArQGJSiZ6w
MD5 (SpyHunter-Operation_Ares-ver1.pcap.zip) = 02aa6ab22bd628e819ace4d3df669caf

Official solution information will be available to full-time faculty members teaching courses in digital forensics or cyber security at accredited academic institutions.

Working with binary in Go (golang).

I have recently been working with raw IP packet generation in Go and came across a bit of code in the "golang.org/x/net/ipv4/header.go" file that I believe could use some explanation.  It uses a bit of binary manipulation which some people find confusing.  The code in question is on line 71 and can be found here.  Lets look at this line and walk through its explanation.

b[0] = byte(Version<<4 | (hdrlen >> 2 & 0x0f))

First off, in an IPv4 header, the first byte of data is actually broken up in to two 4 bit fields.  The first 4 bit field is the IP version and the second 4 bit field is the number of 32-bit words in the header.  The smallest header a valid IPv4 packet can have is 5 32-bit words or 20 bytes.

Second, network byte order is big-endian, meaning that the biggest bit values are first, thus:

128 (decimal) = 1000 0000 (binary big-endian)

Lets look at the first part of the code so we can understand this expression:

Version<<4

To figure this out we first need to see that on line #25 the Version constant is defined to be 4.  Thus this expression expands to 4<<4 which is to say 4 times 2, 4 times, or 4*2*2*2*2.  This gives a value of

64 in decimal or 0100 0000 in binary big-endian

Now if you were to look at just the 4 left most bits of that byte, you would see 0100.  And if that is all you had, that would equal 4, which is the IP version.  The reason for the calculations is to get the right bit in this byte set, so that when you break the byte up in to two 4 bit blocks, the values are in the right places.

Now lets look at the second part of the expression which is actually two expressions:

(hdrlen >> 2 & 0x0f)

We see on line #69 that hdrlen is computed, and has a minimum value of 20.  So for the case where hdrlen equals 20 the first part of this expression could be expanded to 20 >> 2 which is to say 20 divided by 2, 2 times, or 20/2/2.  This gives a value of:

5 decimal or 0000 0101 in binary big-endian

Now we have the "&" operator, which is a bitwise AND.  What the bitwise AND gives us, is all of the bits that are a 1 in both values.  So lets look at both sides of the bitwise AND in binary big-endian.

hdrlen >> 2 = 5 = 0000 0101
0x0f (hex) = 15 decimal = 0000 1111

Now lets line up the binary and do the bitwise AND operation, thus giving you just the bits where the values are 1.  This is a type of mask to make sure we ONLY populate the 4 right most bits.  Remember the 4 left most bits are part of the version not part of the header length and we do not want to accidentally have them in this answer.

0000 0101 (header length)
0000 1111 (mask)
==========&
0000 0101

The last thing to do is join the two values together.  Remember the code was:

b[0] = byte(Version<<4 | (hdrlen >> 2 & 0x0f))

To this we use the "|" operator, which is a bitwise OR.  The bitwise OR gives us all of the bits that have a value of 1 in either of the two values.  So the first value is the Version from up above and the second value is the header length that we just did. Lets line them up in binary and compute the bitwise OR.

0100 0000 (version)
0000 0101 (header length)
========|
0100 0101

Thus the first byte of the b[0] of the slice is:

0100 0101 binary big-endian or 69 decimal or 0x45 hex

You can see that if you broke that byte up in to two 4 bit fields you would have:

0100 = IP version 4
0101 = 5 32-bit word header (a header that is 20 bytes in size)

So all of this binary manipulation was done to make sure we could get the right bits in the right parts of the byte so that we can treat a single byte of data as two separate 4 bit fields.

DHS and MITRE to Transition STIX and TAXII to OASIS

"DHS LEADS EFFORT TO TRANSITION AUTOMATED CYBERSECURITY INFORMATION SHARING SPECIFICATIONS TO INTERNATIONAL COMMUNITY

We are pleased to announce today that the US Department of Homeland Security (DHS) intends to transition the STIXTM and TAXIITM specifications for the automated exchange of cybersecurity data to the Organization for the Advancement of Structured Information Standards (OASIS), a non-profit consortium that drives the development, convergence, and adoption of open standards for the global information society.

This transition is the culmination of three years of work in collaboration with the private sector to define, develop, and implement a robust set of technical specifications to advance the state of the practice in computer network defense. From the inception of these efforts, DHS has maintained that STIX and TAXII would be transitioned to an internationally-recognized standards development organization once the specifications reached an appropriate level of maturity. That day has come, and the transition to OASIS represents an exciting next step in the continued advancement and evolution of STIX and TAXII.

OASIS has an excellent track record in successfully transitioning accepted technical specifications to voluntary consensus standards and in recognizing and building on that existing work. In addition, the global membership of OASIS mirrors the diversity of the STIX/TAXII community and includes a wide variety of government entities, technology vendors, academic institutions, and end-user organizations that have been so critical to the success of the specifications. And finally, the selection of OASIS guarantees that the entire family of STIX/TAXII specifications will always be freely available to anyone around the world.

The transition of STIX and TAXII to OASIS will provide greater transparency and stakeholder participation in the development process which will help ensure the stability and continuing viability of STIX and TAXII as true international standards. These changes have the potential to significantly increase adoption and use of STIX and TAXII and thereby strengthen global cybersecurity practices.

This transition will allow DHS to concentrate our efforts on ensuring the widest and most effective implementations of STIX and TAXII to achieve our mission. We will continue to play an active role through our participation in OASIS, and we will continue to support the development of critical documentation, tools and application programming interfaces.

The only thing that is changing is that the direction of STIX and TAXII will now be in the hands of a robust global community committed to its success. We are confident that this transition will mark the beginning of an even more vibrant and successful cybersecurity ecosystem built on STIX and TAXII that will yield significant improvements in the overall security of our cyber infrastructure."

JSON Support for TAXII 1.1

Today on the TAXII discussion list I released v1.00 of the JSON Message Binding Specification for TAXII 1.1.  APIs written in Go, for generating and consuming JSON based TAXII messages can be found here on Github.

Why I switched to Go (golang), the next great programming langauge

I have been asked a lot as of late, why I switched to writing code in Go.  The answer is pretty simple and to quote another developer;

• The language is modern, small, simple and quite strict. There's a minimalism here that I like - what you see is what you get. Some things that wouldn't even merit a warning in other languages (like unused variables) are errors in Go - your code won't even compile. I like the tidiness this promotes.
  
• Awesome concurrency. Go's concept of goroutines and channels is simple, beautiful and works well. This is essential for something like syncthing where there's a lot of stuff going on in parallel.
  
• Simple deployment. Go compiles to a single statically linked binary that you just need to copy to the target system and run. It's trivial to cross compile from one os/architecture into all others supported by the Go compiler.
  
• Modern standard library, "some batteries included". This includes an HTTP server, a clean (non-OpenSSL) crypto and TLS implementation, JSON and XML serializers, etc.
  
• Good enough performance. The Go compiler doesn't generate as fast code as the best C or C++ compilers out there, but it's still faster than interpreted languages.
  
• Tooling and community. Go does things somewhat differently than many other languages and this can be a bit of an acquired taste... But for example the existence and adoption of "go fmt" means there is no discussion about formatting or indenting - there is only one standard. "Go get" simplifies fetching and building, plus results in a standardized repo layout. Etc.
  
• I think it's a really nifty language to work with and IMHO, it is the next great system language.
  
• It has the backing of a fiscally stable company, Google. So if anything it will only increase in popularity.