Friday, October 12, 2012

Cyberspace and Cybersecurity: Archive Post 1

As of the start of this blog, I am in my second course for my Masters of Science in Cybersecurity. This is an archived posting from the first course.
In this reposting I have noticed citation errors, which have been left intact.

Topic – Vulnerabilities of Hardware and Software Components: Pick one specific hardware or software component and thoroughly discuss its cyber security vulnerabilities. From January 27, 2012

A hybrid hardware software component of particular interest to cyber security is the network stack, the operating system's implementation of the OSI model. The layered nature of the OSI model allows abstraction such that each layer can operate without concern for how or what is occurring at lower levels. This setup is highly convenient for developers because they can interface with logical constructs of sockets, ports, and sessions transparently. The vulnerability that this poses is that each level is entirely at the mercy of each lower level. TCP and UDP socket communication at the session level rides on the IP packets at the transport level for both IPv4 and IPv6 type packets. Thanks to layered networking implementing the OSI model in the network stack, the socket communication gets to its destination with no knowledge of what path it took to get there. (Ruh)

Within a single LAN, both IPv4 and IPv6 addresses are cached in a system with the associated MAC address so that the network stack can properly wrap the transport layer payload in a data link layer header. The associated transport protocol has its method for resolving a protocol address to MAC address which is used to populate the cache. IPv4 uses Address Resolution Protocol, hereafter referred to as ARP, (RFC826) and IPv6 uses Neighbor Discovery (RFC4861); both of which boil down to a host that needs to resolve an address will ask all the systems in the LAN what system uses the address. The appropriate host then responds back, essentially saying 'I have that address.' The first system records the protocol address and associated MAC address in their cache and transmits the packets it was waiting to send. Until the cache entry expires, the system will save time and send future packets destined for that same protocol address directly to the MAC from the cache. For simplicity only IPv4 will be discussed from this point on. The basic principles all apply to IPv6 though. The whole exchange is based on an assumption of trust in the network as most network stacks will record any ARP responses directly into the cache, even if the current entry was still valid.

This method of address resolution and caching creates the vulnerability that if a rogue host, 'Eve', sends an ARP response claiming to have an IP address that belongs to another host, 'Alice', to a third host, 'Bob', then Bob will update his cache. As long as the cache entry is valid, Bob will send all traffic intended for Alice to Eve. If Eve is performing IP forwarding, then she will send the traffic on to Alice. Since this all occurs at the data-link and transport layers, Alice and Bob's applications using sockets will function properly without ever knowing that Eve was receiving the traffic too. If Eve also is sending spoofed ARP responses to Alice, then all traffic will be passing through Eve, allowing that system to view, save, or even change the packets, completely transparently to the applications being run by Alice or Bob. (King)


King, Tom (Aug 4, 2002). Packet Sniffing In a Switched Environment Retrieved 27 January 2012 from: https://www.sans.org/reading_room/whitepapers/networkdevs/packet-sniffing-switched-environment_244

Ruh, Larry (2009). Open Systems Interconnection Reference Model Retrieved 27 January 2012 from: http://polaris.umuc.edu/de/csi/OSI_model_2009/OSI_Model_2009.html

RFC4861 (September 2007). Neighbor Discovery for IP version 6 (IPv6) Retrieved 27 January 2012 from: https://tools.ietf.org/html/rfc4861

RFC826 (November 1982). An Ethernet Address Resolution Protocol Retrieved 27 January 2012 from: https://tools.ietf.org/html/rfc826

No comments:

Post a Comment