DEV Community: Conner

IP spoofing: Theory and implementation

Conner — Mon, 29 Mar 2021 09:40:08 +0000

Theory

Background

When using the internet your devices are assigned a unique 32 bit (IPv4) or 128 bit (IPv6) identifier called an IP address.
You can find the IP address assigned to your network by clicking here.

Think of your IP address as the from: field one would write on an envelope, and the destination IP address as the to:.

If you wanted to pretend to be someone else when sending mail, you can easily erase your address and write a different one, this concept is referred to in this article as spoofing.

As it turns out, the internet works in the same way, on every chunk of data your network sends out conforming to the IP protocol, a header precedes your message containing the from and to fields of the internet. This header is written by your device.

The internet has its foundations in the IP protocol, but most traffic uses TCP/IP or UDP/IP protocol stacks, meaning a TCP or UDP header is included in our message. TCP is important in verifying the source IP of a message, and doesn't enable sustained IP spoofing.

Research

The IP suite is quite complex and has a long history, but overall it defines a set of rules for a software implementation, called the IP stack.

The Internet Protocol itself is used to relay datagrams consisting of a header and data payload. The header section consists of the source IP address, destination IP address, and other relevant fields needed to route and verify the packet. The data payload consists of the data being sent.

In order to view the technical information on what an IPv4 header contains, take a look at the Internetwork Protocol Specification.

In the specification, an IP header is defined on page 15 as the following:

It's a bit strange to decipher but each - character denotes 1 bit, and each field is read from starting ! to ending !

For example, Fragment Offset is 13 bits, and there are 13 - characters from its preceding ! and subsequent !

On page 16 of the specification, we find a few interesting definitions:

The source address field definition, which we intend to change, specifically the last 3 octets (24 bits).

And the checksum field description, which we will also have to change in order for our datagram to be considered valid.

Implementation Plans

Before we get started with the implementation, something important to note is that we cannot feasibly spoof an IP with a TCP/IP stack. This is not possible because TCP connections begin with a 3 way handshake between sender and receiver, and who will the receiver of our message try to complete the handshake with? Our spoofed IP and not our actual one.

However we can use a spoofed IP in the UDP/IP stack, the UDP protocol does not care about a handshake, and will accept communication in a single direction, sender to receiver.

NOTE: Spoofing an IP does not actually require TCP or UDP as a higher level protocol. But we intend to use UDP because it supports port specification, making it easier to test our program.

Now that we've done our research, we have the information needed to determine what we want to change. But how will we modify an IP header?

Before we go searching for information on how an IP header can be modified in code, let's design our program.

Program Design

Our program will use C, as it suits a low-level project like this. It will accept a single argument, the destination address.
All other configuration can be done in code and recompiled.
$ ./ipspoofer 127.0.0.1

It will use the UDP protocol in order to send data, since a 3 way handshake cannot be established under TCP IP spoofing.

API Research

During research the following libraries were found that allow us to modify IP headers:

libpcap
A packet capture library intended for the analysis of incoming and outgoing TCP/IP packets on a device, most likely a network device located in /dev/. However it doesn't seem to be intended for packet modification. The windows port is winpcap.

libnet
Libnet describes itself as "An API created to help with the contruction and injection of network packets [...]
Libnet includes packet creation at the IP layer and at the link layer as well as a host of supplementary and complementary functionality".

raw sockets (unix kernel API)
If you've ever invoked the socket() function using the socket library for a linux system, you've probably either used SOCK_STREAM or SOCK_DGRAM as they correspond to TCP and UDP respectively.
There are however a few more socket types, the one to be used in our code is SOCK_RAW. This socket type allows us to construct our protocol header manually, for protocol we will use IPPROTO_RAW.
This means we will construct the IP and UDP headers and supply them to the kernel.

To summarize the design, we are writing C code to create a program that will construct a UDP/IP datagram, then forward it to its destination IP. We will use raw sockets and syscalls provided by linux kernel as they are much simpler than utilizing a 3rd party library.

The caveat to an implementation using raw sockets is that we will have to create our IP and UDP headers manually, as opposed to simply modifying and injecting captured packets, as can be done with libpcap and libnet.

Implementation

Let's get started writing code, the full source for this project is available here. But we will go over the main bits.

NOTE: Code was tested on Linux, FreeBSD, and MacOS. It compiles on all 3 platforms but does not send datagrams on MacOS.

After including the necessary headers, we will create our socket with the following arguments:

int s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);

AF_INET means we will be using IPv4.
SOCK_RAW means we will be constructing our protocol header.
IPPROTO_RAW means we supply all headers from the IP protocol to the higher level protocols we are using.

We will use 2 predefined structs for our headers, ip_header and udp_header, included from netinet/ip.h and netinet/udp.h.

// IP header
struct ip ip_header;
ip_header.ip_hl = sizeof(struct ip) / 4; // Header length is size of header in 32bit words, always 5.
ip_header.ip_v = 4;                      // IPv4
ip_header.ip_tos = 0;                    // Type of service, See RFC for explanation.
ip_header.ip_len = htons(sizeof(struct ip) + sizeof(struct udphdr) + datalen);
ip_header.ip_id = 0;                     // Can be incremented each time by setting datagram[4] to an unsigned short.
ip_header.ip_off = 0;                    // Fragment offset, see RFC for explanation.
ip_header.ip_ttl = IPDEFTTL;             // Time to live, default 60.
ip_header.ip_p = IPPROTO_UDP;            // Using UDP protocol.
ip_header.ip_sum = 0;                    // Checksum, set by kernel.

// Source IP
struct in_addr src_ip;
src_ip.s_addr = inet_addr(src_addr);
ip_header.ip_src = src_ip;

// Destination IP
struct in_addr dst_ip;
dst_ip.s_addr = inet_addr(dest_addr);
ip_header.ip_dst = dst_ip;

// UDP Header
struct udphdr udp_header;
udp_header.uh_sport = htons(src_port);                          // Source port.
udp_header.uh_dport = htons(dest_port);                         // Destination port.
udp_header.uh_ulen = htons(sizeof(struct udphdr) + datalen);    // Length of data + udp header length.
udp_header.uh_sum = 0;                                          // udp checksum (not set by us or kernel).

To construct the datagram to be sent, we need to fill a buffer with data, starting with the IP header, then UDP header, and finally the data payload.
We can copy a struct into memory with memcpy().

// Construct datagram
int datagram_size = sizeof(struct ip) + sizeof(struct udphdr) + datalen;
unsigned char datagram[datagram_size];
memcpy(datagram, &ip_header, sizeof(struct ip));
memcpy(datagram+sizeof(struct ip), &udp_header, sizeof(struct udphdr));

Finally, we fill out a struct sockaddr_in to hold info about where we are sending this datagram, and send it repeatedly with sendto() until SIGTERM is sent via ctrl+c.

// sendto() destination
struct sockaddr_in destaddr;
destaddr.sin_family = AF_INET;
destaddr.sin_port = htons(dest_port);
destaddr.sin_addr.s_addr = inet_addr(dest_addr);

// Send until SIGTERM
for(;;) {
    sendto(s, datagram, datagram_size, 0,(struct sockaddr*)&destaddr, sizeof(destaddr));
    sleep(1);
}

Thats an overall gist of the code, there's more needed to make this work, and full explanation is inside the source code available at the github link at the top of this section.

View from the Receiver

To verify that our datagrams are being sent, we can use netcat to listen on an open port and display incoming traffic.
$ nc -lvu <port>
-l - Listen (run as a receiver).
-v - Verbose (will show incoming connection IP).
-u - Use UDP.

Run our program and we should see the following:

Connection from 1.2.3.4 2000 received!
...random data...

NOTE: MacOS has no verbose output, you will only see the data.

Wireshark Analysis

In order to verify traffic is being sent by our device, Wireshark can be used to capture and analyze outgoing packets.

If all is well, wireshark should look like this, a blue UDP protocol packet with the source being our spoofed address.

Inspecting the packet, we can see the contents above.
Everything looks good, source IP, destination IP, and ports are set. Checksum was set by kernel and is verified.

Resolving Bugs

MTU

If packet_size is set larger than the MTU, the datagrams will not be sent, and will not appear in wireshark.

A network device MTU refers to its Maximum Transmission Unit, which is the maximum amount of data that can be sent in one IP datagram without fragmenting. Typically an MTU is 1500.

You can find your network device MTU with ifconfig | grep mtu on MacOS and FreeBSD, and with ip addr | grep mtu on linux.

You can also set the MTU of a device with:
ip link set dev <interface> mtu <size> (Linux)
ifconfig <interface> mtu <size> (FreeBSD, MacOS)

MacOS

This code does not work on MacOS, Wireshark analysis implies the kernel is overwriting our source IP and removing our UDP header. The MacOS kernel also does not calculate our checksum for us, which may be the reasoning behind this.

Fetching images by location in an iOS app

Conner — Thu, 04 Mar 2021 02:44:05 +0000

This article was written as a requirement for Lambda School's Curriculum

About 4 weeks ago, I began the final section of my part-time experience at Lambda School, Lambda Labs.

Student developers are split into teams and collaborate to build a project that meets all release requirements. The first week is spent planning your approach to the project, and designing the app UI using Whimsical, a UI creation collaboration tool.

Our team was given a deadline of 4 weeks to create CitySpire, a city-searching app utilizing a data science backend to display city data to web and iOS frontends. Created to help users find the perfect city for their needs.

Finding Cityscapes to use

This article discusses how I handled a technical challenge, integrating the Google Places API into our iOS app, adding a crucial UI improvement to our app, changing all city images from a placeholder icon to pictures of their actual locations.

Acquire an API key

The first step in setting up our app to use the API is to acquire a valid API key through the Google Developer Console. This is required by Google for billing and analytics.
No need to worry though, Google's API services are free for 90 days and won't automatically charge our account once the trial ends.

Lets sign in to the Google Cloud Resource Manager and add our project.

Step 1:

Step 2:

With our project created, lets enable API services.

Step 3:

Step 4:

Locate the Places API and enable it.

Step 5:

Generate an API key.

Create Credentials and select API Key

Step 6:

We must enable billing in order for our API key to be valid, even though Google offers a free trial.

Fill out the credit/debit card information, billing address, etc.

With the API enabled and our key obtained and valid, it's time to request images from the API.

Using the API

The Google Places API documentation is very clear and concise, the first thing we need to create is our Find Place request.

A Find Place request takes a text input and returns a place. The input can be any kind of Places text data, such as a name, address, or phone number. The request must be a string. A Find Place request using non-string data such as a lat/lng coordinate or plus code generates an error.

We are using this API to request data regarding cities, so passing the name and state of a city will suffice.
Example: input="San Francisco, California"

From the documentation, we know the endpoint URL is located at https://maps.googleapis.com/maps/api/place/findplacefromtext/json, and that we are sending a POST request, setting URL parameters and receiving a response in JSON format.

The parameters our app sets to request a city are:
input=CITY, STATE
key=YOUR_API_KEY
inputtype=textquery
fields=name,photos

All in all, our request for San Francisco, California looks like this:
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=San%20Francisco,%20California&key=YOUR_API_KEY&inputtype=textquery&fields=name,photos

With a JSON response containing:

An array of candidates
a status

A candidates object contains:
name - The name of the location
An array of photos

A photos object contains:
height
width
An array of html_attributions - Credits to those who provided the photos
photo_reference

Strangely, a photos object does not contain any actual photos, but it does provide us with the ability to request them via the photo_reference property, a base64 encoded string.

Obtaining the image

In order to request an image via photo_reference, a new endpoint must be used:
https://maps.googleapis.com/maps/api/place/photo

with the following required HTTP parameters:
photoreference=YOUR_PHOTO_REFERENCE
key=YOUR_API_KEY
maxwidth=YOUR_MAX_WIDTH
maxheight=YOUR_MAX_HEIGHT

All in all, our GET request should look something like:
https://maps.googleapis.com/maps/api/place/photo?key=API_KEY&photorefernce=PHOTO_REFERENCE&maxwidth=1200&maxheight=800

And finally the response:

The End Result

After integrating this knowledge into our app using URLSession to make REST API requests, great results are seen in the collection view of our app. Google Places has brought us a picture for every city in our list!

By the end of our project it had good amount of features:

MapKit section where user can search for a city, and display it on the map.
Overlay view to display city information in the map.
Google Places integration to fetch images for each city.
Favoriting cities added to the user's profile.
Collection view alongside the map, allowing users to search and filter through cities outside of Mapkit.

Future Challenges

For the continuation of work on this project, a UI overhaul is definitely needed. Our app has mismatching fonts, a default apple color scheme, and not much color besides white and black.

There are still some technical challenges in the form of bugs too, the image caching was written hastily near a our deadline, and it can unexpectedly display the wrong photo for a cell in the collection view.

API requests for the Mapkit view controller are also made even if the cache contains and image for the requested city, because of the speed in which this image fetch was implemented, it was deemed unimportant to check the cache beforehand.

Reflections

This project provided a lot of long term experience about planning, making design choices, and brainstorming about feature implementations with others in cross-platform teams.

I thoroughly enjoyed the experience and found that I and others worked very well in this environment, I received a lot of great feedback on my Github pull requests and slack messages. This experience leaves me looking forward to working within large teams to create amazing products in the future.