Category: Tech

Posted on

Man In The Middle in SCADA network

The SCADA acronym stands for supervisory control and data acquisition. A SCADA system, is a collection of different software and hardware components that are connected through a network. The system includes inputs and sensors, PLCS and Remote terminal units and different human machine interfaces.

A SCADA system can use communication systems over TCP, for example the IEC 104 protocol. That protocol like DNP3 does not come with the authentication and packet verification batteries included. This means it’s probably vulnerable to man in the middle attacks (hint: it is).

How would a man in the middle attack look like in such a network? We are mostly familiar with such attacks for web communications like for example we know about man in the middle attacks when a user logs into their bank web admin using an untrusted network. A man in the middle attack works similarly for SCADA systems.

Let’s suppose we have an electrical grid which uses some remote transfer units. Now let’s suppose one of these RTUs detects a faulty condition and wants to communicate the condition back to the main SCADA servers. This communication is vulnerable when it’s being done over MODBUS, DNP3 or IEC 104. An attacker with enough domain knowledge will intercept the communication and will be able to modify crucial data.

For example if the communication is over TCP with IEC 104, an attacker can intercept 104 packets, modify the SPI (status) field of one packet and then route it back to the SCADA servers. This can lead to hiding the problem from the engineers and could lead eventually to economical loss or damage to the company’s image.

Posted on

tshark and tcpdump

Occasionally we work with interesting network bugs or we want to learn more about how our service behaves outside of the application layer. Two tools that help me in those occasions are tshark and tcpdump.

Installation

Let’s assume we work on a unix system. Then to install tcpdump we simple execute:

$ apt install tcpdump

Installing tshark is simple too:

$ apt install libcap2-bin tshark

Example API

As a demonstration, we are going to utilize a clean and small Sinatra server. For this example a working Ruby installation is required. See the official docs on how to install Ruby properly on a local machine: https://www.ruby-lang.org/en/documentation/installation/

Going back to our example, first, create the repo:

$ mkdir booklist && cd booklist

Install sinatra:

$ gem install sinatra

Create the example API:

$ cat server.rb

require 'sinatra'
require 'json'

get '/' do
["pragmatic programmer", "clean code"].to_json
end

Fire up the server:

$ ruby server.rb

== Sinatra (v2.0.4) has taken the stage on 4567 for development with backup from Puma
Puma starting in single mode...
* Version 3.12.0 (ruby 2.4.0-p0), codename: Llamas in Pajamas
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:4567
Use Ctrl-C to stop

It works:

$ curl -X GET localhost:4567 | jq .

[
"pragmatic programmer",
"clean code"
]

tcpdump

tcpdump is available on most unix systems, so we can use it on a small remote sever where tshark would be most probably an overkill. It provides decoding so we can investigate how our services interact with the network.

We will work with the lo interface for this example:

$ tcpdump -D

Execute:

$ sudo tcpdump -i lo -A

Hit the service:

$ curl -X GET localhost:4567

Now notice that tcpdump has captured the traffic:

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 37

["pragmatic programmer","clean code"]

tshark

tshark is a powerful sniffer with many filters which can decode traffic and provides tools for running more complex analysis on it.

tshark can behave exactly like tcpdump:

$ tshark -i lo --color

Depending on the problem, the best solution may be to combine the powers of these tools. A usual case is to create a file with captured decoded traffic with tcpdump and then run analysis on the file with tshark. Or just do both with tshark.

Let’s explore how to do this on the previous example.

Capture the traffic to a packet capture(pcap) file:

$ touch dump
$ tshark -i lo -w dump.pcap

Analyze it:

$ tshark -r dump.pcap

For example, HTTP analysis:

$ tshark -r dump.pcap -Y http.request -T fields -e http.host -e http.user_agent | sort | uniq -c | sort -n

We could also use wireshark for the last step which provides a nice GUI.

Outro

Learning more about these tools has helped me analyze and research solutions on more complicated problems, which in turn help me grow as an engineer and problem solver. Some good references for learning more about these tools are:

1) tutorial: https://danielmiessler.com/study/tcpdump/
2) how tcp works: https://medium.com/@eranda/analyze-tcp-dumps-a089c2644f19
3) book: https://www.goodreads.com/book/show/505564.The_TCP_IP_Guide

Posted on

Git bisect debugging

Git is being used primarily for version control but it also provides some generic tools for debugging. In this article, we will
explore how git bisect can help us firstly spot a commit that introduced a but in our codebase and secondly track it throughout
it’s lifespan.

What is git bisect

From the official docs:

The bisect command does a binary search through your commit history to help you identify as quickly as possible which commit
introduced an issue.

Read more at https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git.

The gist is that git bisect provides feedback about where and when the bug was introduced.

Example

First of all, we start by running:

$ git bisect start

A binary search is being initialized and we have to answer yes or no, which usually means answer whether the commit
was error free or not.

We do this by marking commits as bad or good:

$ git bisect bad
$ git bisect good

We also get some feedback along the way:

# => Bisecting: 6 revisions left to test after this

When we are done with our research we can easily get back to a working state:

$ git bisect reset
Posted on

Ruby Blocks

In this article we will discuss how default arguments work and analyze a situation where they can be useful.

The Ruby block

Ruby blocks are code that can be run by other code. All methods can accept blocks, but it’s up to them whether they do something with them or not.

3.times { puts 'hello world' }
3.times do
  puts 'hello world'
end

Blocks can take parameters

Ruby blocks accept parameters and can also initialize them with default values.

def call_block(&block)
  block.call
end

call_block do |greeting = "hi"|
  puts "Block value: '#{greeting}'"
end

In the example above, we initialize the local block variable greeting with the value “hi”.

The behavior can be demonstrated more easily if we use procs:

is_even_proc = Proc.new {|n=1| n%2 == 0 }

is_even_proc(2) # => true
is_even_proc()  # => false, which is the default behavior

Usefulness

For a real example let’s consider the shared examples feature from RSpec, the well know gem for behavior driven development inside the Ruby ecosystem. So, when we use shared_examples we can define a default value and thus avoid code duplication.

# pseudocode

shared_example success |cost=0|
  it "processes the order" do
    expect_any_instance_of(Product).to receive(cost)
  end
end

# Can be used with or without cost

it_behaves_like :success, 1
it_behaves_like :success

Conclusion

To sum up, Ruby allows blocks to receive parameters and enables its initialization with default values. This is applicable is some real world scenarios, such as DRYing up our RSpec suite.