FB12 — AG IT-Sicherheit

Prof. Dr. Elmar Tischhauser

Alexander Bille

IT Security

Solution hints for

Exercise sheet 01
Python, Linux and Common Criteria
Exercise 1 (Security of the default operation system settings)
This task is primarily intended for those who are already familiar with Python and are
therefore bored during the crash course. You can examine either your existing Linux-OS
or a fresh Linux-VM. Windows or MacOS users can also examine their operating system
accordingly.

a) Which ports are open on your system? Are they deliberately open or open by default?
Which services are running there, how are they secured, and can you restrict further
the network interface you are bounded to?

b) Find out which password hashing procedure your operating system uses for logging in
and rate this choice.

c) Try running your (graphical) browser under a dedicated unprivileged user ID while the
desktop runs under your normal login. What are the advantages of this and what settings
do you need to make to be able to browse and work normally?

d) You can test your standard browser for tracking protection by running this test: https:
//panopticlick.eff.org/.

Solution. For (a) and (b) we need at least partial administrative root rights, so we must
first ensure that our user is allowed to run sudo. With Ubuntu or Gnome, the account type
can be set to “administrative” in the user administration. Otherwise (in Ubuntu) adding the
user to the ßudo”group or (in all distributions) editing the /etc/sudoers using visudo will
also do the trick. In my case, it looks like this:

# Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

elmar LOCAL = ALL

elmar LOCAL = NOPASSWD: SHUTDOWN, PKGTOOLS, NET, SYS, MISC

sudo group members and the user elmar can execute all commands (with password entry)
as root, and elmar can also execute some selected commands without (pure convenience, e.g.
includes NET netstat, iwconfig und ip).

a) Open ports and its running processes can be found as follows:

sudo netstat -tulpen

Using my laptop as an example, it currently looks like this (shortened columns):

1
 Active Internet connections (only servers)
Proto Local Address Foreign Address State User PID/Program name
tcp 0.0.0.0:22 0.0.0.0:* LISTEN 0 1060/sshd
tcp 127.0.0.1:631 0.0.0.0:* LISTEN 0 4335/cupsd
tcp6 :::22 :::* LISTEN 0 1060/sshd
tcp6 ::1:631 :::* LISTEN 0 4335/cupsd
udp 0.0.0.0:68 0.0.0.0:* 0 14942/dhclient
udp 127.0.0.1:123 0.0.0.0:* 0 1339/ntpd
udp6 ::1:123 :::* 0 1339/ntpd
udp6 fe80::8883:b97e:d67:546 :::* 0 15106/dhclient
udp6 fe80::a492:dcaf:1ae:546 :::* 0 15072/dhclient

Only the DHCP client and the SSH daemon are bound to publicly accessible network
interfaces, the rest are local (127.0.0.1 for IPv4 and ::1 for IPv6).
b) man passwd tells us that the passwords are not stored directly in /etc/passwd but in
/etc/shadow. According to man shadow, the second column is the “encrypted” pass-
word. Most of the entries are invalid indicated by ! or *. This means that these system
accounts are not available for interactive login. For real users, entries look like this for
me:

elmar:$6$9BFlHIlEP$J3mjLy30M.5r5.4i9gBKvDjQ0MF8X6yzK1SSsVRhV.\
LtztbibqKW4osnQunlGX21fDpWXZXCequTt1SI/jXhr0:17711:0:99999:7:::

The shadow man page linked by man crypt says that SHA-512 with a salt of 86 charac-
ters is used. This is the most modern that my Linux offers and also sufficiently secure.
but it is not ideal as a password hash method, as it is easy to parallelize on GPUs. A
not-so-good login password would therefore still be relatively easy to crack using brute
force - despite a very secure hash function and very long salt.
c) Running the browser under a different user account (let’s say “sandbox”) itself is
unproblematic, but mixing on an X-session operated by the main user requires so-
me work. You have to allow sandbox to connect to the X-server, for example by
xauth extract and xauth merge or (a bit overkill) by local SSH forwarding with e.g.
ssh -X sandbox@localhost firefox.
One-time access from the main user to sandbox files can be implemented e.g. with ACLs,
see man setfacl.
It is sometimes difficult with audio playback and recording, for which a separate
pulseaudio server usually has to be started.
Some advantages are:
• A compromised browser can now only read and modify files of the sandbox user.
Caution: This requires restrictive r/w rights assignment for your own home direc-
tory!
• Browser exploits are executed under a separate user ID, i.e. a local privilege esca-
lation is required to access the main user.
It should be noted that the X client-server architecture does not allow good isolation of
applications and, for example, key logging and mouse/screen grabbing still remain possi-
ble. Wayland should help here, but sometimes causes compatibility problems, especially

2
 with hardware-accelerated video playback. This problem does not change even when
using a VM!
Exercise 2 (Security Evaluation of a Watermarking Procedure, part 1)
This task is the first part of a (small) security evaluation in the style of the Common Criteria.
Our Target of Evaluation (ToE) is a simple digital watermarking procedure for a mobile chat
or photo sharing app: The manufacturer would like to offer the feature that images extracted
from the app and shared elsewhere are tagged with a visible watermark that identifies the
“traitor” (traitor tracing). Here, “extraction” refers for example to the creation of a screenshot
or a photograph of the phone screen.
The procedure consists of adding a textual watermark W on the images every time when
an image is displayed. The watermark is calculated as the base64-encoded text of the hash
value of a user ID, which can be the email address or telephone number of the app user, for
example:

W = base64(H(phone number))
An example image with the watermark rabGMIquybOrd3H5RM7IjbYtZXjWyFOUgyC5YMLSyOg=
loks like this:

(Details on hash functions are irrelevant for this first task. Hash functions have the property
that they are difficult to reverse and are collision-resistant. Specifically, the manufacturer uses
SHA-256 here.)

a) Create an attacker model by describing relevant attacker types A1, A2, . . . classified
according to the knowledge and capabilities of the respective attacker (e.g. access only
via the user interface, access to the app’s file system, . . . )

b) The assets in the ToE are quite clear (the original images), so we go directly to the
security objectives. Describe a list SO1, SO2, . . . of Security Objectives that you think
the watermarking procedure should fulfill.

c) Describe the most important threats T1, T2, . . . applying to this procedure.

d) Make sure that all threats are covered by at least one security objective (i.e. we have
not forgotten anything in the model).

The actual security analysis then comes in the next exercise.

3
Solution. There are many possible and equally suitable approaches here, so this is really
just a suggestion.

a) We distinguish between the following types of attacker:

A1 Attacker A1 only interacts with the app via the user interface and has no precise
knowledge of the watermarking method used.
A1W Attacker A1W extends attacker A1 with precise knowledge of the watermarking
method used.
A2 Attacker A2 extends A1 with access to the files used by the app.
A2W Like A2, but with additional precise knowledge of the watermarking method.

b) The following security objectives may be useful here:

SO1: Detection of data leaks Images viewed with the app or extracted from the app
and then shared are always provided with a visible watermark.
SO2: Prevention of data leaks The original images (without watermark) never leave
the device or the control area of the app.
SO3: Non-forgery of watermarks. Existing watermarks are highly likely to allow con-
clusions to be drawn about the user from whose cell phone the sharing or extraction
took place. Conversely, no one can forge watermarks from other users.
SO4: Resistance to reproduction The watermark remains intact even when (repeated)
digital or analog copies of the images are made.

c) There are many potential threats. Here are a few relevant ones:
T1: Copying images via screenshot
T2:Copying images via (external) screenshot
T3: Copying images via file system access
T4: Removing the watermark via image processing
T5: Forge the watermark of another user

d) In general, we can check this with the help of a crosstab. In this small example, a short
run-through also does the trick: T1, T2, T3 and T4 are covered by SO1, SO2 and SO4,
T5 by SO3. So if we analyze our four security objectives, we have covered all the threats
mentioned here.
Exercise (⋆ Extra homework: Creating a Linux VM)
a) Most of the experimentation and programming tasks in the exercises are best solved
in a Linux VM. Therefore, set up a virtual machine with Linux. Whether you use
VMware Player, VirtualBox or another hypervisor is up to you. If you already have a
Linux installation, you can of course use this directly, or create a lightweight VM with
kvm/qemu for separation purposes.
• The choice of Linux distribution is up to you, but we recommend Debian or Ubuntu,
as this is the best way for us to help you with any questions.
• For Debian, we recommend the latest stable version (Debian 12).

4
 • For Ubuntu, we still recommend the Ubuntu Long-Term-Support (LTS) version
22.04, or version 22.10, which will only be provided with updates until July 2023.
• In the worst case, we cannot help with problems on other systems.

b) Make sure that a Python 3 environment is installed in the VM. This should be available
on Debian/Ubuntu by default. Also install the packages build-essential (which contains
the C compiler, make, gdb and other development tools) and binutils in your VM.

c) Install an editor that you are comfortable working with. If you have no experience with vi
(vim/gvim) or emacs (GNU Emacs), you can use e.g. Scite, a simple graphical editor,
or Atom (http://atom.io), a fairly extensible editor with a focus on development.
Another (paid) option would be Sublime Text.