Securing SSH in Azure

On a recent project I inherited an Azure IaaS setup that managed Linux VMs by connecting via SSH from public IPs. I figured while we did a vNet migration we might as well secure the SSH pipeline.

Disable SSH Arcfour and CBC Ciphers

Arcfour is compatible with RC4 encryption and has issues with weak keys, which should be avoided. See RFC 4353 for more information here.

The SSH server located on the remote host also allows cipher block chaining (CBC) ciphers to be used to establish a Secure Shell (SSH) connection, leaving encrypted content vulnerable to a plaintext recovery attack. SSH is a cryptographic network protocol that allows encrypted connections between machines to be established. These connections can be used for remote login by an end user, or to encrypt network services. SSH leverages various encryption algorithms to make these connections, including ciphers that employ cipher block chaining.

The plaintext recovery attack can return up to thirty two bits of plaintext with a probability of 2-18 or fourteen bits of plain text with a probability of 2-14. This exposure is caused by the way CBC ciphers verify the message authentication code (MAC) for a block. Each block’s MAC is created by a combination of an unencrypted sequence number and an encrypted section containing the packet length, padding length, payload, and padding. With the length of the message encrypted the receiver of the packet needs to decrypt the first block of the message in order to obtain the length of the message to know how much data to read. As the location of the message length is static among all messages, the first four bytes will always be decrypted by a recipient. An attacker can take advantage of this by submitting an encrypted block, one byte at a time, directly to a waiting recipient. The recipient will automatically decrypt the first four bytes received as it the length is required to process the message’s MAC. Bytes controlled by an attacker can then be submitted until a MAC error is encountered, which will close the connection. Note as this attack will lead to the SSH connection to be closed, iterative attacks of this nature will be difficult to carry out against a target system.

Establishing an SSH connection using CBC mode ciphers can result in the exposure of plaintext messages, which are derived from an encrypted SSH connection. Depending on the data being transmitted, an attacker may be able to recover session identifiers, passwords, and any other data passed between the client and server.

Disable Arcfour ciphers in the SSH configuration. These ciphers are now disabled by default in some OpenSSH installations. All CBC mode ciphers should also be disabled on the target SSH server. In the place of CBC, SSH connections should be created using ciphers that utilize CTR (Counter) mode or GCM (Galois/Counter Mode), which are resistant to the plaintext recovery attack.

Disable SSH Weak MAC Algorithms

The SSH server is configured to allow cipher suites that include weak message authentication code (“MAC”) algorithms. Examples of weak MAC algorithms include MD5 and other known-weak hashes, and/or the use of 96-bit or shorter keys. The SSH protocol uses a MAC to ensure message integrity by hashing the encrypted message, and then sending both the message and the output of the MAC hash function to the recipient. The recipient then generates their hash of the message and related content and compares it to the received hash value. If the values match, there is a reasonable guarantee that the message is received “as is” and has not been tampered with in transit.

If the SSH server is configured to accept weak or otherwise vulnerable MAC algorithms, an attacker may be able to crack them in a reasonable timeframe. This has two potential effects:

  • The attacker may figure out the shared secret between the client and the server thereby allowing them to read sensitive data being exchanged. 
  • The attacker may be able to tamper with the data in-transit by injecting their own packets or modifying existing packet data sent within the SSH stream.

Disable all 96-bit HMAC algorithms, MD5-based HMAC algorithms, and all CBC mode ciphers configured for SSH on the server. The sshd_config file should only contain the following options as far as supported MAC algorithms are concerned:

  • hmac-sha2-512
  • hmac-sha2-512-etm@openssh.com
  • hmac-sha2-256
  • hmac-sha2-256-etm@openssh.com
  • hmac-ripemd160-etm@openssh.com
  • umac-128-etm@openssh.com
  • umac-128-etm@openssh.com
  • hmac-ripemd160
  • umac-128@openssh.com
  • umac-128@openssh.com 

In addition, all CBC mode ciphers should be replaced with their CTR mode counterparts.

Testing

To test, run the following command:

nmap -sS -sV -p 22 –script ssh2-enum-algos [TARGET IP]

South Florida Code Camp – Azure IoT Overview

March 2nd 2019, I will be presenting Azure IoT Overview at the South Florida Code Camp in Davie, FL. You can register here – and its FREE. Here is the synopsis of the presentation:

Abstract

Keeping up to date on all the new services and features for an entire cloud portfolio could be a full-time job. In this presentation, we will look at the state of IoT in Microsoft Azure and discuss how the different services work together to implement an enterprise solution. Use this presentation to get an overview of architecture and products so that the next time you are presented with an IoT problem in Azure you know the solution.

 

 

Creating an ASP.NET Core application for Raspberry Pi

As a part of the Wren Hyperion solution, an ASP.NET Core application will run on an ARM based Linux OS (we are building a POC for the Raspberry Pi and Raspian).  Here are the steps on how you can get started with ASP.NET Core on Raspian:

  • Setup a Raspberry Pi with Raspian
  • Install .NET Core
  • Create your ASP.NET Core solution
  • Publish to the Raspberry Pi
  • Install .NET Core to the Raspberry Pi
  • Run your application on the Raspberry Pi

Setup a Raspberry Pi with Raspian

Follow the guides on the Raspberry Pi website to install Raspian on your Pi.

Install .NET Core

  1. Download and Install

    To start building .NET apps you just need to download and install the .NET SDK (Software Development Kit) for Windows.

    Download .NET SDK

    A video frame showing a Windows command prompt. Select this image to start playing the video.

    Video: Creating a Simple .NET Application on Windows

  2. Get an editor

    Visual Studio is a fully-featured integrated development environment (IDE) for developing .NET apps on Windows.

    Download Visual Studio

    Select the .NET Core cross-platform development workload during installation:

    A screenshot of the Visual Studio Installer. The Workload screen is shown, and '.NET Core cross-platform development' is selected.

  3. More info

    While you wait for Visual Studio to install, you can keep learning with the .NET Quick Starts. In the first Quick Start you’ll learn about collections.

    Quick start: Collections

    Once Visual Studio is installed, come back and build your first .NET app using Visual Studio.

Create your ASP.NET Core Solution

  1. Create a new .NET Core project.

    On macOS and Linux, open a terminal window. On Windows, open a command prompt.

    dotnet new razor -o aspnetcoreapp
  2. Run the app.Use the following commands to run the app:
    cd aspnetcoreapp
    dotnet run
    
  3. Browse to http://localhost:5000
  4. Open Pages/About.cshtml and modify the page to display the message “Hello, world! The time on the server is @DateTime.Now “:
    @page
    @model AboutModel
    @{
        ViewData["Title"] = "About";
    }
    <h2>@ViewData["Title"]</h2>
    <h3>@Model.Message</h3>
    
    <p>Hello, world! The time on the server is @DateTime.Now</p>
    
  5. Browse to http://localhost:5000/About and verify the changes.

Publish to the Raspberry Pi

On macOS and Linux, open a terminal window. On Windows, open a command prompt and run:
dotnet clean .
dotnet restore .
dotnet build .
This will rebuild the solution. Once that is complete run the following command:
dotnet publish . -r linux-arm
This will generate all the files needed for running the solution on the Raspberry Pi. After this command completes generating the needed files, the files need to be deployed to the Pi. Run the following command in Powershell from the publish folder:
& pscp.exe -r .\bin\Debug\netcoreapp2.0\ubuntu.16.04-arm\publish\* ${username}@${ip}:${destination}
Where username is the username for the Pi (default “pi”), ip is the ip address of the Pi, and destination is the folder the files will be published to.

Install .NET Core to the Raspberry Pi

This section is sourced from Dave the Engineer’s post on the Microsoft blog website.

The following commands need to be run on the Raspberry Pi whilst connected over an SSH session or via a terminal in the PIXEL desktop environment.

  • Run sudo apt-get install curl libunwind8 gettext. This will use the apt-get package manager to install three prerequiste packages.
  • Run curl -sSL -o dotnet.tar.gz https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.0.0/dotnet-runtime-latest-linux-arm.tar.gz to download the latest .NET Core Runtime for ARM32. This is refereed to as armhf on the Daily Builds page.
  • Run sudo mkdir -p /opt/dotnet && sudo tar zxf dotnet.tar.gz -C /opt/dotnet to create a destination folder and extract the downloaded package into it.
  • Run sudo ln -s /opt/dotnet/dotnet /usr/local/bin` to set up a symbolic link…a shortcut to you Windows folks 😉 to the dotnet executable.
  • Test the installation by typing dotnet –help.

  • Try to create a new .NET Core project by typing dotnet new console. Note this will prompt you to install the .NET Core SDK however this link won’t work for Raspian on ARM32. This is expected behaviour.

Run your application on the Raspberry Pi

Finally to run your application on the Raspberry Pi, navigate to the folder where the application was published and run the following command:

dotnet run

You can then navigate to the website hosted by the Raspberry Pi by navigating to http://{your IP address here}:5000.