Sunday, June 15, 2014

Beginning Memory Forensics - Volatility

In the previous post, the memory image of a Windows 2003SP2 machine was dumped. Now that we have the memory image, let's use volatility to analyze its contents.

First, let look at the memory image to see what OS volatility thinks it may be. Do remember, I already stated this is a Windows2003SP2 but let's see what volatilty says.

To identify the image, we use following volatility command.
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw imageinfo

As can be seen above, the imageinfo plugin gave us some suggested profiles. From the additional information, we can see we also have the time the image was aquired. We will also use the KDBG address information as we continue to analyze our image.

Let's move on to the connections plugin to see what network connections may have been established at the time this memory image was acquired.

To find the network connections we use:
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw connections


There seems to have been a connection from the localhost on port 1033 to host 192.168.0.15 on port 4444. We also see this connection reports it was using PID 4712.

Let's look at the process tree to see what we can find using command:
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pstree

Name                                                  Pid   PPid   Thds   Hnds Time
 0x812923e8:rundll32.exe                             4712   4700      2     35 2014-06-13 01:49:51 UTC+0000
. 0x81292b70:cmd.exe                                 4728   4712      1     30 2014-06-13 01:49:51 UTC+0000


It seems process 4712 also had a child process with PID 4728 (cmd.exe). From this perspective, I would say someone at IP 192.168.0.15 had access to the  command prompt. We also see that process 4712 parent is reported as PID 4700.

Let's see what we can learn about PID 4700
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pslist --pid=4700


Hmmmmmm!! This is strange, PID 4700 does not seem to exist.

Let's move on. What privileges was PID 4712 (rundll32.exe) and PID 4728 (cmd.exe) running with? Let's find out.


From the above, it seems these 2 processes were also running with Local System and Administrator privileges.

Since, were unable to find anything relating to PID 4700, let's see what DLLs may be in use by PID 4712 (rundll32.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4712



... and now for PID 4728 (cmd.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4728



Let's go back to process rundll32.dll (PID 4712) and see if there may be any malware in there.

vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw malfind -p 4712 --dump-dir /tmp

The above command created the file process.0x812923e8.0x90000.dmp in the /tmp directory

Let's post this file up to virustotal and see what we get.



Looks like the file was detected as containing malware by 2 out of the 54 AV engines.

As the above shows, we can use tools like volatility to analyze the contents of memory to draw conclusions.

Reference and Additional Readings:
https://code.google.com/p/volatility/wiki/CommandReference
http://moyix.blogspot.ca/2008/04/finding-kernel-global-variables-in.html
https://www.virustotal.com/

Saturday, June 14, 2014

Beginning Memory Forensics – Getting the contents of RAM - DumpIT

Why would we want to do memory Forensics?

As I’ve said previously, in analyzing an intrusion or any signs that  there may have been an intrusion, the more data we have the better. This data can be from the IDS/IPS, log sources, etc. One area we should not exclude is the memory of the device we are investigating. Using only the log sources and IDS alert, it is unlikely we will get a full picture of all the processes, listening and or established network connections, etc.

In this post we focus on getting the contents of a Windows 2003SP2 system using DumpIT. According to the description from the moonsols.com website "This utility is used to generate a physical memory dump of Windows machines. It works with both x86 (32-bits) and x64 (64-bits) machines"

So without further ado, lets DumpIT.
Using this tool is super easy, all you do is run the executable and it creates the image in the directory from which the executable was run. The file name is a combination of computer name, date and a final number of which I'm not sure what it is at this time. The extension of the file is ".raw" Eg. of the filename is "SECURITYNIK-SRV-20140613-015002.raw"


As can be seen above, first we executed "dumpit".
The second step in the process is to press "Y" or "N" if you would like to continue. Once you pressed "Y", the process runs and once completed successfully, you will see "Success"

That's it. Next post we will use Volatility to analyze the the memory.

References and Additional Readings:

http://www.moonsols.com/resources/

Thursday, June 12, 2014

snort rules - Pandemiya Trojan - Zeus-based Variant - Revision 2

After some discussion it was recognised that the string which was being searched for in the URI may be randomly generated. It was suggested that "User-Agent: Hello 2.0" should be unique enough to capture any usage of this Zeus variant. As a result, I'm releasing Revision 2 of the rules. These two rules should capture any GET or POST request made from the variant leaving the "$HOME" network.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Va riant - POST request"; content:"POST"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000001; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - GET request"; content:"GET"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000002; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)

Wednesday, June 11, 2014

snort rules - Pandemiya Trojan - Zeus-based Variant

 Earlier today a colleague (thanks Zuhair) made me aware of a new Zeus-based variant which was discovered. He sent me the following three links:
 
High-level Description
Detailed Technical Description

Symantec Assessment

 As a result I've developed and tested the following snort rules. I'm publishing them here in the hope that they can help someone. I will be implementing these and thought someone else may find them useful.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - POST request"; flow:to_server,established; content:"POST"; http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0"; nocase;fast_pattern;content:"aWnBrokeQxPeKunljEDkm"; nocase; Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2 ;sid:4000001)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - POST request"; flow:to_server,established; content:"POST"; http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0"; nocase;fast_pattern;content:"P4ND3M1CB00BF4C3"; nocase; Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2 ;sid:4000001)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - GET request"; flow:to_server,established; content:"GET"; http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0"; nocase;fast_pattern;content:"aWnBrokeQxPeKunljEDkm"; nocase; Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2 ;sid:4000001)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - GET request"; flow:to_server,established; content:"GET"; http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0"; nocase;fast_pattern;content:"P4ND3M1CB00BF4C3"; nocase; Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2 ;sid:4000001)


If anyone thinks these can be better modified,please feel free to drop me a line at nikalleyne at gmail dot com.

Sunday, June 8, 2014

Beginning IPv6 - Analyzing FTP Traffic

In the previous post we look at analyzing Telnet. Let's now look at the FTP protocol. Since in the post on DNS I elaborated on the fields which makes up the header of the IPv6 protocol, I will refrain from doing so again. Some information missing in this post may be found it earlier posts in this series

root@securitynik:~/securitynik#tshark -r ipv6-ftp.pcap -n -c 3

 1   0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 53024 > 21 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=303844 TSecr=0 WS=128
  2   0.001874 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 21 > 53024 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=102405 TSecr=303844
  3   0.001921 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=303845 TSecr=102405

The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different from what we would have seen in our IPv4 TCP 3-way handshake
 
  4   0.024868 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 FTP 113 Response: 220 Microsoft FTP Service
In packet 4 above we see the server at source "fd33:e581:65d4:0:a000:27ff:fe21:1a75" sending its FTP banner
 
  5   0.025134 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=28 Win=28800 Len=0 TSval=303850 TSecr=102406
In packet 5 above we see the client at "fd33:e581:65d4:0:a000:27ff:fe28:1d5" acknowledges the server's communication.

Once again, let's cut through the clutter and see what we get from the TCP stream 0
 root@securitynik:~/securitynik# tshark -r ipv6-ftp.pcap -z "follow,tcp,ascii,0" | more
 

 ===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:21
Node 1: 253.51.229.129:53024
27
220 Microsoft FTP Service

    20
USER administrator

23
331 Password required

    15
PASS Testing1

21
230 User logged in.

    6
SYST

16
215 Windows_NT

    52
EPRT |2|fd33:e581:65d4:0:a000:27ff:fe28:1d5|49829|

30
200 EPRT command successful.

    6
LIST

54
125 Data connection already open; Transfer starting.

24
226 Transfer complete.

    5
PWD

31
257 "/" is current directory.

    6
QUIT

14
221 Goodbye.

As can be seen above, the knowledge we have from analyzing FTP on IPv4 can be easily transferable to IPv6

This ends this series on beginning IPv6. If you think there is something I missed, stated incorrectly or just needed further elaboration, please feel free to leave a comment.

Beginning IPv6 - Analyzing Telnet Traffic

In the previous post we look at analyzing HTTP. Let's now look at the Telnet protocol. Since in the post on DNS I elaborated on the fields which makes up the header of the IPv6 protocol, I will refrain from doing so again. In addition, as we continue to go through these protocols, we will omit stuff which can be easily found in the previous posts in this series.

root@securitynik:~/securitynik# tshark -r ipv6-telnet.pcap -n -c 3
  1   0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 46906 > 23 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=283731 TSecr=0 WS=128
  2   0.002348 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 23 > 46906 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=94364 TSecr=283731
  3   0.002402 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 46906 > 23 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=283732 TSecr=94364

    The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different is from what we would have seen in our IPv4 TCP 3-way handshake

    4   0.004552 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TELNET 113 Telnet Data ...

In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" beginning its Telnet Session
   
    5   0.048954 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 23 > 46906 [ACK] Seq=1 Ack=28 Win=65536 Len=0 TSval=94369 TSecr=283732
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.

    Ok, let's skip through some of the clutter and follow TCP stream 0
   
root@securitynik:~/securitynik#tshark -r ipv6-telnet.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:46906
Node 1: 253.51.229.129:23
27
........... ..!.."..'.....#
    21
..%........'.........
21
..%.......P..........
    53
..... ..!.."..'.....'..SFUTLNTVER.SFUTLNTMODE.......#
    38
Welcome to Microsoft Telnet Service

34
..'..DISPLAY.securitynik:0....'...
    9

login:
password:

...... REDUCED FOR BREVITY ........

*===============================================================
Microsoft Telnet Server.
*===============================================================
C:\Users\Administrator>
1

As can be seen above, the knowledge we have from analyzing Telnet on IPv4 can be easily transferred to IPv6



   

Beginning IPv6 - Analyzing HTTP traffic

In the previous post we looked at analyzing DNS. Let's now look at the HTTP protocol. Since in the post on DNS I elaborated on the fileds which makes up the header of the IPv6 protocol, I will refrain from doing so again.

Let's use our IPv4 TCP knowledge to analyze this IPv6 communication

Let's run tshark against our capture

root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -n -c 3
1   0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 55594 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=265480 TSecr=0 WS=128
  2   0.001162 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 80 > 55594 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=87067 TSecr=265480
  3   0.001220 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 55594 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=265480 TSecr=87067

The 3 packets above represents the typical TCP 3-Way handshake. Nothing here is different from what we would have seen in our IPv4 TCP 3-way handshake
 
  4   0.001807 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 HTTP 370 GET / HTTP/1.1
In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" do a GET request for /
 
  5   0.050772 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 80 > 55594 [ACK] Seq=1 Ack=285 Win=65536 Len=0 TSval=87072 TSecr=265480
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.
 
  8   0.565480 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 HTTP 281 HTTP/1.1 200 OK  (text/html)
In packet 8, we see the server responds with a Status Code of 200
 

Ok, let's skip through some of the clutter and follow TCP stream 0
root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:55594
Node 1: 253.51.229.129:80
284
GET / HTTP/1.1
Host: websrv
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive


    1428
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Thu, 05 Jun 2014 02:42:28 GMT
Accept-Ranges: bytes
ETag: "55a1baca6780cf1:0"
Server: Microsoft-IIS/8.0
Date: Fri, 06 Jun 2014 03:09:18 GMT
Content-Length: 1398

............. reduced for brevity .........



As can be seen above, the knowledge we have from analyzing HTTP on IPv4 can be easily transferred to IPv6

Beginning IPv6 - Analyzing DNS

Now we move into the meat of the matter. All the previous posts were really preparing for this stage. It is obvious that, unless we understand the IPv6 header and the components within it, it would be extremely difficult for us to analyze any type of communication running on top of IPv6.

One of the things we will learn as we move through these next few posts is, the knowledge we have of analyzing IPv4 application layer, is easily transferable to IPv6 application layer protocols. Basically not much has change if anything in most cases.

So without further ado, let's look at the DNS protocol.

The following represents the configuration of our local DNS resolver.
root@securitynik:~/securitynik# cat /etc/resolv.conf
nameserver fd33:e581:65d4:0:a000:27ff:fe21:1a75

Now let's run tshark against our packet capture.
root@securitynik:~/securitynik#tshark -n -r ipv6-dns-success.pcap
1   0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 DNS 95 Standard query 0x537b  AAAA securitynik.lab
2   0.000613 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 DNS 123 Standard query response 0x537b  AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75


So above we see we have two packets. The first represents the DNS query over IPv6 and the second represents the DNS response.

Digging deeper - Ignoring time information!

Packet 1:
fd33:e581:65d4:0:a000:27ff:fe28:1d5 - represents the source IP or the device where the traffic originated.

fd33:e581:65d4:0:a000:27ff:fe21:1a75 - represents the destination or the device to which the traffic is being sent

DNS - Similary to IPv4 this represents the DNS protocol and would be seen in the "Next Header" portion of the IPv6 header

95 - total size of the packet
By default tshark gives us the entire packet size which in this case we see 95 bytes. However, what we should be more concerned about here is the "Payload Length". To find the "Payload Length" we subtract the length of the Ethernet header (14 bytes) and the length of the IPv6 Header (40) bytes from the total 95 bytes.
95 - (14 + 40) = 41
So it would be clear to see that our Payload length is 41 bytes

Standard query - this is a DNS Query
0x537b  - Query ID

AAAA - Record type. In IPv4. This would have more than likely been an 'A' record
securitynik.lab - this is the domain which was requested


Packet 2:
This represents the response to packet 1
fd33:e581:65d4:0:a000:27ff:fe21:1a75 - In packet 1 this was the destination to which we sent the DNS request. In packet 2, we now have the DNS server responding

fd33:e581:65d4:0:a000:27ff:fe28:1d5 - The response is now coming back to our client IP.

DNS - Next Header which represents DNS

123 - Total size of the packet
Once again, we are interested in the Payload Length. To find this value we use the same formula as we did in packet 1. Subtract the Ethernet header (14 bytes) and the IPv6 header (40) bytes from 123.
123 - (14 + 40) = 69 bytes

Standard query response - Response to our original request
0x537b - How do we know this response is for our original packet? The Query ID in both packets matches

AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75 - basically stating that our requested domain - securitynik.lab is at the address

As can be seen, there is not that much difference between the way DNS operates in IPv4 than it does it IPv6

Beginning IPv6 - Understanding the Header

As we continue to learn about IPv6, it is time to now take a look at the entire IPv6 header. Working from RFC 2460, we have the following header.

IPv6 Header Format


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
The first 4 bits of the header represents the "Version". In this case we would expect this number to be 6

Next we have the "Traffic Class" which is 8 bits. This field is "available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets."

Next up we have the 20-bit "Flow Label". "A flow is uniquely identified by the combination of a source address and a non-zero flow label.  Packets that do not belong to a flow carry a flow label of zero. ... All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. ...   There is no requirement that all, or even most, packets belong to flows"

Next we have the Payload length. This is a 16-bit field or 2 octets. This represents the length of the IPv6 payload including any additional headers.

Following the Payload Length, we see the Next header which is an 8-bit or 1 Octet value and represents the header immediately following the IPv6 header.

The next field is the Hop Limit. This field is similar to the TTL field in IPv4 and gets decremented by each host forwarding the data. Similarly to IPv4 TTL, if a value of 0 is reached, the packets gets discarded.

Next we see the source and then finally the destination addresses. Both of these addresses represents 128 bits. My two previous posts dealt with understanding these two specifically.

An important point to note is while IPv4 header is typically 20 bytes but can be a variable of up to 60 bytes, the IPv6 header is a fixed 40 bytes.

Since we have now broken down the entire IPv6 header, it is now time for us to analyze some application layer protocol running unto of IPv6.


References and Additional Readings: 
http://tools.ietf.org/html/rfc2460
http://tools.ietf.org/html/rfc4193
http://tools.ietf.org/html/rfc3513
http://www.tcpipguide.com/free/t_IPv6DatagramMainHeaderFormat.htm 



Beginning IPv6 - Understanding an IPv6 address

In this post we continue in the series of Beginning IPv6. While the previous posts dealt with understanding the 64-bit Interface ID portion of the IP address, this post focuses on the entire 128-bit, IP address. So without further ado, let's look at an IPv6 address from the perspective of RFC 4193 - Unique Local IPv6 Unicast Addresses and RFC 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture

RFC 4193 states the following:
    "These addresses are called Unique Local IPv6 Unicast Addresses...  They are not expected to be routable on the global Internet."

Let's look at the IP address format

   | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
   +--------+-+------------+-----------+----------------------------+
   | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
   +--------+-+------------+-----------+----------------------------+

Let's break this out.
Prefix
The Prefix used to identify local IPv6 address is 7-bit and equals FC in Hex or 1111 110

L
The L is 1-bit and when set (1) implies that this prefix is locally assigned.
This now means for a locally assigned prefix we should have 1111 1101. This is Hex FD while previously we used Hex FC.

Global ID
The global ID is 40-bit. It is calculated based on the formula below and MUST not be assigned sequentially or with well known numbers. There are sites which can help us to generate this which we will use later.
    1) Obtain the current time of day in 64-bit NTP format [NTP].

     2) Obtain an EUI-64 identifier from the system running this
        algorithm.  If an EUI-64 does not exist, one can be created from
        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
        cannot be obtained or created, a suitably unique identifier,
        local to the node, should be used (e.g., system serial number).

     3) Concatenate the time of day with the system-specific identifier
        in order to create a key.

     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.

     5) Use the least significant 40 bits as the Global ID.

     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
        ID to create a Local IPv6 address prefix.


Subnet ID
This is a 16-bit value used to represent the subnet(s) used within the site(s)

Interface ID
This 64-bit is generated based on the Modified EUI64 format. This was explained in the previous post.

Now that we have an understanding of the format of the IPv6 address, let's put together an address using an online tool to generate a Global ID

FD33:e581:65d4:0000:a00:27ff:fe28:17d5/48

So from the above above we see we have the following
Prefix - FD - 1111 1101
Global ID: 33:e581:65d4
Subnet ID: 0000
Interface ID: a00:27ff:fe28:17d5


Breaking it down further
Since we use /48 we now have the following:
Prefix - FD33:e581:65d4
Subnet - 0000
Interface ID: a00:27ff:fe28:17d5

Breaking it down even further.
Now that we have address FD33:e581:65d4::a00:27ff:fe28:17d5/48. RFC 3513 says we can use :: to drop consecutive 0s. Let's do that
FD33:e581:65d4::a00:27ff:fe28:17d5/48

Voila!!! We did it. We should now have a better understanding of what an IPv6 address should look like and how to interpret it.

References and additional readings:
http://tools.ietf.org/html/rfc4193
http://tools.ietf.org/html/rfc3513
https://www.ultratools.com/tools/rangeGeneratorResult?globalId=&subnetId=
https://www.sixxs.net/tools/grh/ula/
http://www.infoblox.com/downloads/resources/best-practices-for-ipv6-subnetting

Sunday, June 1, 2014

Beginning IPv6 - Understanding The Interface ID - Modified EUI64

Here is where I begin a series on understanding, configuring and analysing IPv6 protocol and communication.

This first post in this series, deals with understanding the interface ID part of the IPv6 address. The reason I choose to start with this is, I feel it is important to understand how the last 64 bits (Interface ID) is determined.
So without further ado, let's look at the IPv6 address format using RFC 4193 (Unique Local IPv6 Unicast Address)

 | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
 +--------+-+------------+-----------+----------------------------+
 | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
 +--------+-+------------+-----------+----------------------------+
As we can see from the above, the IPv6 interface ID is 64 bits.

The value which becomes the interface ID is generated from the existing MAC address on your device's interface(s).

Let's get our system's MAC address
nik@securitynik:~$ ifconfig | grep HW
eth0      Link encap:Ethernet  HWaddr 08:00:27:4d:f7:d0

OK! So our MAC is 08:00:27:4d:f7:d0

The above MAC address is 48 bits or 6 bytes. To get this to Extended Unique Identifer (EUI64) we simply insert FF:FE between the Organizational Unique Identifer (OUI) and the local portion. From the above MAC address, the OUI is represented by the first 3 bytes moving from left to right. This would mean the OUI is 08:00:27. Next the local portion of the 48 bits MAC would be the next (last) 3 bytes. Which in this case would be 4d:f7:d0. If we now insert FF:FE between these two we get the EUI64 address.
So our EUI64 address is 08:00:27:FF:FE:4d:f7:d0

However, we do not finish here. The interface uses a modified EUI64 not the actual EUI64 address.

To get to the modified EUI64 address, we modify the first byte from the left of thie EUI64 address

So the current EUI64 address is 08:00:27:FF:FE:4d:f7:d0. The first byte of the above MAC is 08. In Binary this is 0000 1000

Now that we have the binary value, let's modify the 7th bit from the left. In binary 0000 1000 the 7th bit has a value of 0 We will now change this value to 1. If the current value is a 0 we change it to one, likewsie if it is a 1 we change it to 0
Binary 0000 1000 becomes 0000 1010 which is x0a. Now we have our modified EUI64 which is 0a:00:27:FF:FE:4d:f7:d0

So if we step back a bit, our original MAC was 08:00:27:4d:f7:d0. Now our Modified EUI64 is 0a:00:27:FF:FE:4d:f7:d0

Let's verify this on our interface

nik@securitynik:~$ ifconfig eth0 | grep -E HW\|inet6
eth0      Link encap:Ethernet  HWaddr 08:00:27:4d:f7:d0 
          inet6 addr: fe80::a00:27ff:fe4d:f7d0/64 Scope:Link
         
Awewsome!!! we should now understand how the Interface ID (Modified EUI64) is determined for our IPv6 Interface


References and additional readings
http://tools.ietf.org/html/rfc4193
http://www.tcpipguide.com/free/t_IPv6InterfaceIdentifiersandPhysicalAddressMapping-2.htm
http://msdn.microsoft.com/en-ca/library/aa915616.aspx
https://supportforums.cisco.com/document/100566/understanding-ipv6-EUI64-64-bit-address
http://wiki.nil.com/IPv6_EUI64-64_interface_addressing
http://grouper.ieee.org/groups/msc/MSC200407/OnlineTutorialsD/EUI6464.htm
http://studium.vos-sps-jicin.cz/cisco/CCNA_R&S-Intro/course/module8/8.2.4.5/8.2.4.5.html
http://silmor.de/ipaddrcalc.html#ip6