Secure Systems and Networks

On the first lab we wil cover introduction to the labs, setup, and sniffing/spoofing (topics are listed below with more detail). We may use computers which are available in the lab, but bring your own laptop too, so you can setup it properly for the remote labs that will follow.

1. Download the SEED Ubuntu 16.04 Virtualsystem image either from our site at Wroclaw University of Technology or directly from SEED Labs. Download SEED Ubuntu 16.04 32-bit zip file and unpack it in some final destination on your local or external disk.
   The ZIP file itself is around 3.5 GB and after unpacking you need around 14-16 GB of space -- you may do it on external USB disk or a pendrive.
2. Set up the virtual system according to the SEED Labs manual. Important highlights: in the general setup of VirtualBox (not related to any virtual system) setup first a "NAT Network" in the networking section, then proceed with configuring SEED Ubuntu system, as described in the docs. In network config, use Nat Network as type of network, or even better - configure two network adapters - one as "NAT Network", another as simple "NAT".
3. We will need this setup for labs 2-4, and we can use it for lab 1 too, but if you have problems configuring and running VirtualBox with SEED Ubuntu, an alternative for just the first lab on Oct 15th will be to have just any Linux system either in VirtualBox or native. If you have no access to such a system and you are running MacOS or MS Windows -- make sure that you have installed a GPG program (Gnu Privacy Guard).

If you use the computers in the lab, the native Linux installed there may default to the Polish language. In order to change it to English (in a terminal window), type the following:

  export LANG=en_US.UTF-8
  export LANGUAGE=en_US.UTF-8

Lecture

Final test

Free books from Packt Pub

Lab topics

• Introduction

  Introduction to lab environment, accounts setup, working with virtual systems in the lab, review of the Linux system basics

  Setup of the virtual system:

  • copy files from lab computers, from directory "VirtualBox VMs". Only the ones starting with SEED*, you do not need Kali Linux which is also there
  • You may copy this SEED Ubuntu 16.04 Virtualsystem image either from our site at Wroclaw University of Technology (faster) or directly directly from SEED Labs: SEED Labs. Download SEED Ubuntu 16.04 32-bit zip file and unpack it in some final destination on your local or external disk.
  • Set up the virtual system according to the SEED Labs manual

  ---

• network sniffing

  Group 2 (B): Thursday 14.11.2024,
  Group 1 (A): Monday 18.11.2024,
  Group 3 (C): Monday 25.11.2024
  

  Preparation for lab:

  Students should find what programs in unix/linux system can be used for monitoring network traffic and sniffing packets off the network.

  Tasks to do during the lab:
  

  Part 1 -- Sniffing

  Using network sniffers you should capture packets allowing you to see how ping, traceroute and mtr programs work.
  Make screenshots, create report, explain how it works, show examples.

  Detailed tasks:

  • Check ping, traceroute, mtr -- find answers to the following questions (and ashow the results/answers in your report):
    • what kind of packets do they send to discover the intermediate routers?
    • Is it ICMP, TCP, UDP?
    • What features they use to find routers?
  • Log in to some FTP site, for example ftp.icm.edu.pl or ftp.pwr.wroc.pl using "anonymous" acount (provide your email or some random data for the password) -- find out how this password information is sent over the network, use wireshark filters to get just the interesting packets, not all the rubbish that you can listen to on the network

    Use some filters in wireshark to limit the number of packets you see and focus on the important stuff. For FTP with ftp.icm.edu.pl you may use something like:

    • ip.addr == 193.219.28.2
    • tcp.port == 21
    • tcp.stream eq 1
    • tcp.port == 21 or udp.port == 21

  • Access a password protected WWW site: http://dream.ict.pwr.wroc.pl/ssn/secure/ -- use username "ssn" and password "secure". You may of course use a different password and see it fail. Observe how this user/pass information is sent from the web browser to the server.

  Make sure that you are using the right network interface for sniffing. Make screenshots of interesting screens where you have required information. Also -- at the end of wireshark session save data to a pcap file, so if you miss something for the final report, you will be able to read the captured data again and find information that you missed.

  Part 2 -- sniffing and spoofing with Scapy

  If you are using SEED Labs virtual system, Scapy should be already installed there. Also -- to construct your own ICMP packets or do network sniffing you need root access, so make sure you run the programs with appropriate privileges. Install Scapy for Python: https://scapy.readthedocs.io/en/latest/installation.html, (The "pip install" method should work without any problems). Do also a "pip install ipython" to have a better interactive python interface for running scapy. Create a script for capturing packets. Customize this script to show only selected packets. Make sure that you run this script with root privilleges (e.g. after "sudo bash"). Choose packets based on:

  • ip address (put some address of remote site and create traffic for it)
  • protocol (e.g. FTP or SMTP)

  Modify the display filter to show the interesting information, -- e.g. the contents of FTP control channel where passwords can be seen.

  Construct an ICMP PING packet (icmp type 8) with spoofed source address and send it (you should be able to see the sent packet and the response in wireshark). Start with doing this in interactive scapy/ipython, then write it also as the python script that can be run from thw shell. Observe the packet in wireshark (and make a screenshot of it) and in scapy sniffing program.

  scapy scripts (taken from Edu Portal):

  In interactive scapy:

    conf.color_theme=BrightTheme()
    explore()
        # use IPv4 layers
    pkt=IP(proto="udp")
    pkt.show()
    u=UDP()
    pkt2=pkt/u
    pkt2.show()
    pkt2.dport=53
    pkt2.dst="156.17.1.1"
    ...
    send(pkt2)
  

  Scapy basic program for packet sniffing:

      #!/usr/bin/python
      from scapy.all import *
      print("SNIFFING PACKETS.........")
      def print_pkt(pkt):
           print("Source IP:", pkt[IP].src)
           print("Destination IP:", pkt[IP].dst)
           print("Protocol:", pkt[IP].proto)
           print("\n")
  
      pkt = sniff(iface=["enp0s3","enp0s8"],filter='ip',prn=print_pkt)
  

  Some links to see: https://gaia.cs.umass.edu/kurose_ross/wireshark.php

  https://scapy.readthedocs.io/en/latest/usage.html

  ---

• GPG keys

  Group 1 (A): Monday 2.12.2024
  Group 2 (B): Thursday 23.11.2024
  Group 3 (C): Monday 9.12.2024
  

  Tasks to do:

  • Generate your own GPG key (and sign it)
  • Export your public key to ASCII format so you can share it with other people
  • Import GPG keys of other users (including teacher's key)
  • Sign keys of other people, acquire other people signatures for your own key
  • Import your own GPG key signed by other people (i.e. import signatures)

  • Sign a message with your GPG key
  • Sign and encrypt a message for the teacher
  • Sign and encrypt a message addressed for several (2-3) people at once
  • Optional: Sign/encrypt message directly in the email program (use mutt for that purpose).

  After the lab, write a report showing the tasks you have performed (and put it in the ePortal task). Include as separate files:

  • your own GPG key signed by other people (at least 2 other signatures), exported in ASCII format
  • a signed message (preferably - in cleartext form, i.e. created with --clearsign -a options)
  • an encrypted message for at least 2-3 people (including the teacher)
  • (optionally) - teacher's key with your signature

  Upload these files just after or during the lab (remember NOT TO click on the "final" version). Then write the report after the lab in the PDF format. You have one week after the lab to do so. Tick the "final" version when you upload the report (you may still update the already sent files until this final tick).

  Public key of the teacher can be downloaded from here.
  If you want to properly test if this is the correct key, check it's fingerprint. It should be this:

      Key fingerprint = 63FC 8412 8830 28C8 3C47  0F7D AE49 6244 4239 1952
  

  You may also test if the key has been imported correctly by verifying a signature of this message or this.

  ---

• SSL and certificates

  Group 1 (A): Monday 16.12.2024
  Group 2 (B): Thursday 12.12.2024
  Group 3 (C): Monday 20.01.2025
  

  SSL resources
  

  Lecture slides
  

  Lab preparation:

  Make sure that your working environment is clean (not affected by previous work of other people).

  Create CA, create server certificate, sign it with CA,install apache to use this certificate

  Create user certificates, configure server to use them to allow access to some directories based on identity of a client, checked by the client certificate. Provide also some common directory for all clients signing with certificates issued by your CA.

  Tasks from the whiteboard

  ---

• Reverse engineering

  Group 1 (A): Monday 13.01.2025
  Group 2 (B): Thursday 23.01.2025
  Group 3 (C): Monday 31.01.2025
  

  Download a zip file from this directory and unpack it inside a virtual system. If necessary, you may need to add execution bit (chmod a+x keygen-en) for binary programs that have been unpacked in order to run them.

  There are two subdirectories there, and two tasks to do

  1. subdirectory "buffer"

  This one is just for a warm-up and should be quite easy (no more than 30 minutes).

  There are three programs: buffer1, buffer2 and buffer3 - all very similar, but for the first one you have also the source code in C and assembly-level source in buffer1.s (generated automatically through gcc -- see Makefile how to do it), fot buffer2 you have only .s file, the third one is just binary

  Your task is to find and report two numbers for programs 2 and 3:

  • what is the allocated size of the buffer
  • what is the length of string you have to provide in order to overwrite buffer with just 1 character

  These 2 values are not equal for programs 2 and 3. For program 1 the buffer size is 80 characters (you can see it clearly in the source code) and if you run the program with an argument which is exactly 80 characters long, the null-terminating '\0' character at the end of string (at position 81) will not fit into the buffer and overwrite the next variable. Add 5 more characters and you will get Segmentation Violation as you overwrite stored EBP value that messes up the main() function after return.

  2. subdirectory "reverse"

  Run program keygen-eng-1. It asks for a user number and a password. If you give user number "0" and password "12345678" it will say that "you passed". If user number is other than zero, the password is not so simple :-)

  Your task is to find out what password should be entered if you give your student ID number as user ID.

  Use the gnu debugger (gdb) or other tools (maybe some code de-compilers?) to find out what this program does, how the password is generated. The program does not have a symbol table, so in order to start it under the debugger, set breakpoint to:

  	break __libc_start_main
  

  then

  	run
  

  to start the program and catch it when it enters the main function. Another useful gdb command to use:

  	set disassemble-next-line on
  

  This will automatically disassemble few next lines every time the gdb stops program. At any time you may also issue disassemble command to see disassembled code of the sorrounding area, and use commands such as si (step instruction) or ni (next instruction) to do step-by-step program execution to find how it works.

  Also, remember about the p or print commands to inspect variables and registers, and x command to inspect the memory at a given address.

  Some basic gdb commands that may be useful:

  command	shortcut	description
  nexti	ni	execute one assembly-level instruction, going over function calls
  stepi	si	execute one assembly-level instruction, step into functions
  run		run the program from the beginning. If you need to pass parameters to the program, do it here, i.e. "run abcdef" will pass "abcdef" as argv[1] to the started process
  break	br	set breakpoint at some location (function name or *0x0000abcd for a memory address -- note the star sign at the beginning of the address)
  continue	c	continue execution until next breakpoint
  print	p	print some value. Examples: $register_name, *$esi, *(int*) $esi; *(char*) $esi, print/x for hex value
  info		info registers (all CPU registers); info breakpoints (all breakpoints)
  backtrace	bt	show current function frame - and stack contents
  disassemble	disas	disassemble current function, or another function: disassemble main or a range of memory addresses: disassemble 0xadd0,0xadd1
  x		dump memory. Examples: x $esi, x/32 $esi, x/16c 0x123456, x/s 0x456789 (/s - treat it as STRING, /c - as char*, /32 - dump 32 values, etc.)
  ENTER		pressing ENTER key repeats the last command, e.g. if you type ni first, then pressing ENTER several times repeats ni commands

  The gdb which is installed in the SEED virtual system comes with ~/.gdbinit file, which contains the following line:

      source /home/seed/source/gsbpeda/peda.py
  

  This loads an overlay to GDB which is much nicer to work with, as it gives you persistent display of current code, memory and registers. However - if the debugged program prints something on the screen, it may get messy, as PEDA redraws the whole screen with its output. So it may be actually desirable to run GDB sometimes without PEDA extensions - you can do it by commenting out this "source" line with the hash sign (#). And if you start gdb without PEDA, you can always switch it on at any moment, by just executing this source command (just paste it in the GDB input).

  Also, you may run the program by itself (without gdb) in one window, then in another window - type "gdb keygen-eng-1", but instead of starting the program with the "run" command - attach to an already running process - type "attach PID", where PID is the process ID of the running program (find it with the ps command), so, for example:

  1. In window 1 run "./keygen-eng-1". The program will start, but pause on "USER:" prompt, waiting for input data
  2. In window 2, try "ps auxww | grep keygen" and find its process ID, lets say it is 1234
  3. In window 2 (or another one) start gdb: "gdb ./keygen-eng-1"
  4. Instead of doing "run", type "attach 1234" (or the appropriate ID) to attach to the running process
  5. GDB will show you, that the program is somewhere in _vfscanf() function. To regain control in more familiar territory, do "disassemble main", then find a place where there is a call to scanf() and set a breakpoint just after that function. Or use "bt" (backtrace) to see the stack, look for "main" and break at the address shown there (the return address into the main function after the scanf call). Then type "c" or "continue" and regain the control at the next breakpoint.
  6. Once the debugger catches your breakpoint again, proceed as usual -- using "ni" or setting breakpoints, but now with your program running in a separate window.