Two guest lectures at Ulm University
Guest lectures at Ulm University
Ulm University logo 
SCHUTZWERK has long-lasting connections to Hochschule Furtwangen, Hochschule Aalen and Ulm University in order to cooperate in research and teaching topics with security focus. This includes lectures, security CTFs, master and bachelor thesis as well as research projects (e.g., the ongoing BMBF project SecForCARs in which a recent master thesis was conducted together with Ulm University). Furthermore SCHUTZWERK regularly conducts one-day hands-on events, so-called Capture-the-flags (CTF), in which students can test their cybersecurity skills in form of a practical competition (e.g. Hack2Improve).
Thus, students interested in the field of IT security are given the chance to write their thesis (Bachelor/Master) with us but can also become part of the SCHUTZWERK team as a working student. This will allow working students to gain insights into professional life, gain hands-on experience with IT security, and finance their studies. Further possibilities like an internship (with a minimum duration of 6 month) complete the practical opportunities for students at SCHUTZWERK. Most internal projects of working students like the development of new hardware and software solutions directly contribute to our daily business. The results are often used in upcoming assessments. In the long term, we want to keep good students by offering attractive job opportunities. Some former working students are now fully employed after completing their studies.
On the teaching level SCHUTZWERK gives security lectures (e.g., Penetration Testing and Computer Forensic at Hochschule Aalen) or guest talks and guest lectures providing practical examples and insights into applied IT security. For example, the following two guest lectures were recently given by SCHUTZWERK at Ulm University focusing on the basics in web security and on social engineering attacks.
Guest Lecture - Web Security
The Web Engineering lecture at Ulm University gives a general overview over web technologies including historical development and technical basics. The lecture is accompanied by an exercise. In this exercise, students apply their knowledge in a practical manner to strengthen and deepen the understanding of what has been learnt.
In the field of web engineering, where technologies are changing very frequently, the requirements and best practices regarding security are constantly changing, too. To keep up with these changes goes beyond the scope of this lecture. However, a basic understanding of web security and security best practices is desperately needed by any web engineer.
To give students an insight into the latest web security mechanisms, Tobias Arnold held a guest lecture on January 31st. In the introduction of the guest lecture, the general procedure of a penetration test was first outlined: 1. collecting information, 2. scanning for vulnerabilities and 3. exploiting vulnerabilities. If an exploit is successful, the process starts from the beginning since new information may be available.
With the general understanding of the procedure, the lecture continued with the introduction of OWASP. The Open Web Application Security Project (OWASP) is a worldwide not-for-profit organization focused on improving the security of software. One of the OWASP projects is the Top Ten Project in which the ten most common security vulnerabilities in web applications are described. This project serves as a reference for both, web engineers and penetration testers. Due to limited time, the lecture focused on four of the top ten vulnerabilities: injection, broken authentication, broken access control, and cross-site scripting.
INJECTION - Two examples of injections were presented: command injections and SQL injections. To exploit a command injection, an attacker has to find a vulnerability first. An example is a php function stored and executed on a web server. This function receives a file name as a parameter from a client to delete it. This file name is directly used in a system command without any sanitization. The code snippet can be seen below:
<?php $file=$_GET['filename']; system("rm $file"); print("File deleted successfully"); ?>
If the provided file name is doc1.pdf, the executed command is
rm doc1.pdf. Provided that the file exists in the appropriate place it is deleted. However, since the file name is not sanitized on server side, a second command could be attached to the file name. The “file name” doc1.pdf;id results in the following executed command
rm doc1.pdf;id. In fact, those are two commands separated by a semicolon. The first
rm doc1.pdf deletes the file as described before.
The second command
id returns information about the current user. Both commands are executed in the user context of the web server. An injection like this can be used to compromise the web server directly.
The second example presented at the guest lecture was an SQL injection. This vulnerability results also from the use of unsanitized user input. An attacker can use an SQL injection access or modify information stored in a database. In some cases it is also possible to execute system commands by using databases functions.
BROKEN AUTHENTICATION - This OWASP class of vulnerabilities covers anything related to the session management, from login to logout. This includes the use of default credentials, allowing weak passwords (further information about proper password strength can be found at the QWASP Authentication Cheat Sheet), missing session timeout, missing brute force protection, and more.
BROKEN ACCESS CONTROL - Most web applications provide sensitive information such as addresses and bank account information. This information must not be accessed by a third party. Therefore, an effective access control needs to be established. It is not sufficient to assume that links or ids leading to confidential data or documents could not be guessed by an attacker. Every access to a resource must be approved by the web server by checking access legitimacy.
Furthermore, two types of cross-site scripting were demonstrated with examples: stored cross-site scripting and reflected cross-site scripting. In a stored cross-site scripting, an attacker is able to place his script code on the website persistently (e.g. in a comment field) and the code is delivered to any user visiting this site this. In a reflected cross-site scripting, malicious code embedded in a request is returned by the web server without being stored persistently. This non permanent cross-site scripting is called reflected. To exploit this kind of reflected cross-site scripting, an attacker must convince a user to click on a malicious link, e.g., in a mail.
A countermeasure to avoid cross-site scripting is the escaping of characters like
/. Those characters are needed to surround the script code with script tags
<script>...</script> to get the browser to interpret the script code as such.
The main take away message of the guest lecture was the following:
All explicit and implicit user input is a potential security risk!
Web engineers should be sensitized and aware about potential security risks. This is the only way to establish appropriate countermeasures and develop future web applications according to best practices. The students attending this lecture have come a step closer to this goal.
Guest Lecture - Social Engineering
The second guest lecture Social Engineering - Man as the weakest link in the chain was given by Dr. Bastian Könings in early February as part of the lecture Sicherheit in IT-Systemen (Security in IT systems). Social engineering is an act of interpersonal influence designed to cause certain behaviors. Goals can be the disclosure of passwords, access to secure areas or the execution of certain actions. Based on human attributes like trust, helpfulness, respect, helplessness, curiosity, comfort, fear, shame, etc. an attacker can use social engineering to bypass potential strong technical security measures. Social engineering attacks are usually very successful. The lecture presented different types of social engineering attacks: active (direct interaction) vs passive (no direct interaction like eavesdropping) and human based (without the use of technical aids) vs computer based (with the use of technical aids).
The second part of the lecture presented several practical examples of real-world social engineering assessments conducted by SCHUTZWERK. The three steps to conduct a social engineering attack are: 1. collecting information, 2. searching for weaknesses and 3. exploiting vulnerabilities.
- The first step is the collection of information about the target. For this, direct observation or publicly available information such as map services can be used. Useful information are among other things: which area is under video surveillance, access control systems, working and break times, dress code, usage of badges, regular events, behavior, and much more.
- In a second step, the collected information is evaluated and searched for weak spots such as an unguarded rear entrance. Based on an identified vulnerability, an attack scenario can be developed. The third step is the execution. Thereby, an attacker must blend in with the surroundings to go undetected. Attributes like quick-wittedness, spontaneity, adaptability and calmness are essential. An attack scenario could be the maintenance of smoke detectors.
- To increase credibility, the attacker must dress up as a technician (e.g. with a boilersuit, proper technical tools and a badge). If the staff behaves correctly the attacker will not be able to move freely. However, he could be able to place a bug (microphone or camera) in a smoke detector. The bug can be used to get further insights or even sensitive information like passwords or confidential data.
To minimize the possible attack vectors, several measures were presented at the guest lecture. An important point is the training of employees. Only if employees are aware of the threat of social engineering, they can behave appropriate, e.g. report incidents and not disclose sensitive information.
This second guest lecture demonstrated that man itself could be the weakest part. Using social engineering technical measures can be bypassed rather easily. Especially for students, most focusing only on technical security, this lecture broadened their horizons allowing them to see the bigger picture of IT security.