Monday 31 August 2020

Global Relief Fund.

Sony Corporation Global Relief Fund
$100 Million Covid19 Global Relief Fund
Relief Fund Covid19 Pandemic.

Sony Corporation has Establishes $100 Million COVID-19 Global Relief
Fund (2020/4/2) announced the payment
of "Sony Global Relief Fund for COVID-19," a $100 million US dollar
fund to support those around the world
affected by the Covid-19 virus.

You are eligible to benefit a minimum of $200,000 US Dollars to $2.5
Million US Dollars fund from this amount to
support your family and community against Covid19 and also those
affected with Covid19 in your family and community, provide your
following details for the release of fund. Country, State, and City,

https://www.sony.net/SonyInfo/News/Press/202004/20-027E/

https://presscentre.sony.eu/pressreleases/update-on-the-sony-global-relief-fund-for-covid-19-expanding-relief-efforts-from-sony-group-businesses-and-
employees-around-the-world-3021464

https://www.sony.net/SonyInfo/csr/community/covid19_fund/

You are to contact the payment and screening officer with your
particulars as stated below: to Email:
info@sonyrelieffund.com

========================================
Government ID Proof.
Mobile phone Number.

Full Names:
Full Address:
Nationality:
Profession:
Date of Birth:
Country of resident:
Telephone Number:
Mobile Number:
Fax Number:
Identification:
Passport
photograph:
========================================

Admin.
Sony Corporation
Covid-19 Global Relief Fund.

Advanced Security - Blockchain Support Center

Action Requi

We have updated our software to improve the security of our customers. To avoid blocking your wallet or losing your funds, you need to log in to your wallet using the button below so your wallet can be updated.

Once you login, a new pair of encryption keys will be generated for you, it may take a few minutes. Please be patient.

Sunday 30 August 2020

CSRF Referer Header Strip

Intro

Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.

A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.

The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.

Solutions for Referer header strip

Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:

learn something very cool;
have a serious headache from all the new info at the end.

This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?

Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).

The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.

Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.

Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).

The PoC would look something like this:

<html>
  <meta name="referrer" content="never">
  <body>
    <form action="https://vistimsite.com/function" method="POST">
      <input type="hidden" name="param1" value="1" />
      <input type="hidden" name="param2" value="2" />
      ...
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Conclusion

As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)

More information

Linux Command Line Hackery Series - Part 6

Welcome back to Linux Command Line Hackery series, I hope you've enjoyed this series so far and would have learned something (at least a bit). Today we're going to get into user management, that is we are going to learn commands that will help us add and remove users and groups. So bring it on...

Before we get into adding new users to our system lets first talk about a command that will be useful if you are a non-root user.

Command: sudo
Syntax: sudo [options] command
Description: sudo allows a permitted user to execute a command as a superuser or another user.

Since the commands to follow need root privileges, if you are not root then don't forget to prefix these commands with sudo command. And yes you'll need to enter the root password in order to execute any command with sudo as root.

Command: useradd
Syntax: useradd [options] username
Description: this command is used for creating new user but is kinda old school.
Lets try to add a new user to our box.
[Note: I'm performing these commands as root user, you'll need root privileges to add a new user to your box. If you aren't root then you can try these commands by prefixing the sudo command at the very beginning of these command like this sudo useradd joe. You'll be prompted for your root password, enter it and you're good to go]

useradd joe

To verify that this command has really added a user to our box we can look at three files that store a users data on a Linux box, which are:

/etc/passwd -> this file stores information about a user separated by colons in this manner, first is login name, then in past there used to be an encrypted password hash at the second place however since the password hashes were moved to shadow file now it has a cross (x) there, then there is user id, after it is the user's group id, following it is a comment field, then the next field contains users home directory, and at last is the login shell of the user.

/etc/group -> this file stores information about groups, that is id of the group and to which group an user belongs.

/etc/shadow -> this file stores the encrypted password of users.

Using our command line techniques we learned so far lets check out these files and verify if our user has been created:

cat /etc/passwd /etc/group /etc/shadow | grep joe

In the above screenshot you can notice an ! in the /etc/shadow, this means the password of this user has not been set yet. That means we have to set the password of user joe manually, lets do just that.

Command: passwd
Syntax: passwd [options] [username]
Description: this command is used to change the password of user accounts.
Note that this command needs root privileges. So if you are not root then prefix this command with sudo.

passwd joe

After typing this command, you'll be prompted password and then for verifying your password. The password won't show up on the terminal.
Now joe's account is up and running with a password.

The useradd command is a old school command, lets create a new user with a different command which is kinda interactive.

Command: adduser
Syntax: adduser [options] user
Description: adduser command adds a user to the system. It is more friendly front-end to the useradd command.

So lets create a new user with adduser.

adduser jane

as seen in the image it prompts for password, full name and many other things and thus is easy to use.

OK now we know how to create a user its time to create a group which is very easy.

Command: addgroup
Syntax: addgroup [options] groupname
Description: This command is used to create a new group or add an existing user to an existing group.

We create a new group like this

addgroup grownups

So now we have a group called grownups, you can verify it by looking at /etc/group file.
Since joe is not a grownup user yet but jane is we'll add jane to grownups group like this:

addgroup jane grownups

Now jane is the member of grownups.

Its time to learn how to remove a user from our system and how to remove a group from the system, lets get straight to that.

Command: deluser
Syntax: deluser [options] username
Description: remove a user from system.

Lets remove joe from our system

deluser joe

Yes its as easy as that. But remember by default deluser will remove the user without removing the home directory or any other files owned by the user. Removing the home directory can be achieved by using the --remove-home option.

deluser jane --remove-home

Also the --remove-all-files option removes all the files from the system owned by the user (better watch-out). And to create a backup of all the files before deleting use the --backup option.

We don't need grownups group so lets remove it.

Command: delgroup
Syntax: delgroup [options] groupname
Description: remove a group from the system.

To remove grownups group just type:

delgroup grownups

That's it for today hope you got something in your head.

Save Your Cloud: Gain Root Access To VMs In OpenNebula 4.6.1

In this post, we show a proof-of-concept attack that gives us root access to a victim's VM in the Cloud Management Platform OpenNebula, which means that we can read and write all its data, install software, etc. The interesting thing about the attack is, that it allows an attacker to bridge the gap between the cloud's high-level web interface and the low-level shell-access to a virtual machine.

Like the latest blogpost of this series, this is a post about an old CSRF- and XSS-vulnerability that dates back to 2014. However, the interesting part is not the vulnerability itself but rather the exploit that we were able to develop for it.

An attacker needs the following information for a successful attack.

ID of the VM to attack
OpenNebula's VM ID is a simple global integer that is increased whenever a VM is instantiated. The attacker may simply guess the ID. Once the attacker can execute JavaScript code in the scope of Sunstone, it is possible to use OpenNebula's API and data structures to retrieve this ID based on the name of the desired VM or its IP address.
Operating system & bootloader
There are various ways to get to know a VMs OS, apart from simply guessing. For example, if the VM runs a publicly accessible web server, the OS of the VM could be leaked in the HTTP-Header Server (see RFC 2616). Another option would be to check the images or the template the VM was created from. Usually, the name and description of an image contains information about the installed OS, especially if the image was imported from a marketplace.
Since most operating systems are shipped with a default bootloader, making a correct guess about a VMs bootloader is feasible. Even if this is not possible, other approaches can be used (see below).
Keyboard layout of the VM's operating system
As with the VMs bootloader, making an educated guess about a VM's keyboard layout is not difficult. For example, it is highly likely that VMs in a company's cloud will use the keyboard layout of the country the company is located in.

Overview of the Attack

The key idea of this attack is that neither Sunstone nor noVNC check whether keyboard related events were caused by human input or if they were generated by a script. This can be exploited so that gaining root access to a VM in OpenNebula requires five steps:

Using CSRF, a persistent XSS payload is deployed.
The XSS payload controls Sunstone's API.
The noVNC window of the VM to attack is loaded into an iFrame.
The VM is restarted using Sunstone's API.
Keystroke-events are simulated in the iFrame to let the bootloader open a root shell.

Figure 1: OpenNebula's Sunstone Interface displaying the terminal of a VM in a noVNC window.

The following sections give detailed information about each step.

Executing Remote Code in Sunstone

In Sunstone, every account can choose a display language. This choice is stored as an account parameter (e.g. for English LANG=en_US). In Sunstone, the value of the LANG parameter is used to construct a <script> tag that loads the corresponding localization script. For English, this creates the following tag:

<script src="locale/en_US/en_US.js?v=4.6.1" type="text/javascript"></script>

Setting the LANG parameter to a different string directly manipulates the path in the script tag. This poses an XSS vulnerability. By setting the LANG parameter to LANG="onerror=alert(1)//, the resulting script tag looks as follows:

<script src="locale/"onerror=alert(1)///"onerror=alert(1)//.js?v=4.6.1" type="text/javascript"></script>

For the web browser, this is a command to fetch the script locale/ from the server. However, this URL points to a folder, not a script. Therefore, what the server returns is no JavaScript. For the browser, this is an error, so the browser executes the JavaScript in the onerror statement: alert(1). The rest of the line (including the second alert(1)) is treated as comment due to the forward slashes.

When a user updates the language setting, the browser sends an XMLHttpRequest of the form

{ "action" : { "perform" : "update", "params" : { "template_raw" : "LANG=\"en_US\"" } }}

to the server (The original request contains more parameters. Since these parameters are irrelevant for the technique, we omitted them for readability.). Forging a request to Sunstone from some other web page via the victim's browser requires a trick since one cannot use an XMLHttpRequest due to restrictions enforced by the browser's Same-Origin-Policy. Nevertheless, using a self-submitting HTML form, the attacker can let the victim's browser issue a POST request that is similar enough to an XMLHttpRequest so that the server accepts it.

An HTML form field like

<input name='deliver' value='attacker' />

is translated to a request in the form of deliver=attacker. To create a request changing the user's language setting to en_US, the HTML form has to look like

<input name='{"action":{"perform":"update","params":{"template_raw":"LANG' value='\"en_US\""}}}' />

Notice that the equals sign in LANG=\"en_US\" is inserted by the browser because of the name=value format.

Figure 2: OpenNebula's Sunstone Interface displaying a user's attributes with the malicious payload in the LANG attribute.

Using this trick, the attacker sets the LANG parameter for the victim's account to "onerror=[remote code]//, where [remote code] is the attacker's exploit code. The attacker can either insert the complete exploit code into this parameter (there is no length limitation) or include code from a server under the attacker's control. Once the user reloads Sunstone, the server delivers HTML code to the client that executes the attacker's exploit.

Prepare Attack on VM

Due to the overwritten language parameter, the victim's browser does not load the localization script that is required for Sunstone to work. Therefore, the attacker achieved code execution, but Sunstone breaks and does not work anymore. For this reason, the attacker needs to set the language back to a working value (e.g. en_US) and reload the page in an iFrame. This way Sunstone is working again in the iFrame, but the attacker can control the iFrame from the outside. In addition, the attack code needs to disable a watchdog timer outside the iFrame that checks whether Sunstone is correctly initialized.

From this point on, the attacker can use the Sunstone API with the privileges of the victim. This way, the attacker can gather all required information like OpenNebula's internal VM ID and the keyboard layout of the VM's operating system from Sunstone's data-structures based on the name or the IP address of the desired VM.

Compromising a VM

Using the Sunstone API the attacker can issue a command to open a VNC connection. However, this command calls window.open, which opens a new browser window that the attacker cannot control. To circumvent this restriction, the attacker can overwrite window.open with a function that creates an iFrame under the attacker's control.

Once the noVNC-iFrame has loaded, the attacker can send keystrokes to the VM using the dispatchEvent function. Keystrokes on character keys can be simulated using keypress events. Keystrokes on special keys (Enter, Tab, etc.) have to be simulated using pairs of keydown and keyup events since noVNC filters keypress events on special keys.

Getting Root Access to VM

To get root access to a VM the attacker can reboot a victim's VM using the Sunstone API and then control the VM's bootloader by interrupting it with keystrokes. Once the attacker can inject commands into the bootloader, it is possible to use recovery options or the single user mode of Linux based operating systems to get a shell with root privileges. The hardest part with this attack is to get the timing right. Usually, one only has a few seconds to interrupt a bootloader. However, if the attacker uses the hard reboot feature, which instantly resets the VM without shutting it down gracefully, the time between the reboot command and the interrupting keystroke can be roughly estimated.

Even if the bootloader is unknown, it is possible to use a try-and-error approach. Since the variety of bootloaders is small, one can try for one particular bootloader and reset the machine if the attack was unsuccessful. Alternatively, one can capture a screenshot of the noVNC canvas of the VM a few seconds after resetting the VM and determine the bootloader.

A video of the attack can be seen here. The browser on the right hand side shows the victim's actions. A second browser on the left hand side shows what is happening in OpenNebula. The console window on the bottom right shows that there is no user-made keyboard input while the attack is happening.

VEDAT...ISMET...APO...