be me

Intro

To be able to show their performance even during COVID19 lockdowns, artists Parini Secondo & magdalena öttl asked WUHEI to produce an interactive multimedia web platform

  • Stream live video of the performance to connected visitors
  • Allow visitors to interact with each other on the platform

Solution

The final result consists of a website featuring:

  • A video player live streaming the live event via RTMP
  • A custom made server that manages user avatars and their interactions with each other
Be Me online interactive dance platform for dancers
Interface built for the "be me" performance

Video streaming

At first I wanted to host a video server on the platform and get the video stream straight from the venue. However, due to constraints such as the lack of reliable broadband connection in the venues, the final product featured a video player connected to YouTube. This allowed both WUHEI and the artists to delegate the video stream backend management and focus on running the platform during the live performances.

Live video captured from the event was streamed with OBS studio to YouTube live, via RTMP.

Interaction

User mouse cursors were used as avatars for their own connection to the platform.

As users moved around the screen, their mouse arrows would get syncronized live to every other connected visitor.

On top of each avatar position, the server keeps track of text labels attached to each mouse cursor, allowing for a spatial chat interaction between users.

Be Me online interactive dance platform for dancers
Each arrow is a user, with optional text/emoji text

Attacks

On the technical side the experience was a bit surreal because I'm not facing such harsh security conditions with web platforms I build for my clients (which has been the core of most of my professional career for more than 20 years).

What made this project different compared to common web projects was the interaction between different interconnected parts, namely:

  • the public facing interactive frontend on bemestream.com
  • the panel to update and control the video stream
  • the backend server sending data (mouse position, chat, video data) back and forth all connected frontends
  • extra tech baggage due to last-minute changes (changes to handle video streaming from live event to non-live, having to handle the video streaming to all connected clients while managing the backend during performances, etc.)

These requirements enlarged the attack surface on the server beyond what is assumed as common when doing threat-analysis for a web platform, and I should have planned accordingly.

The nature of the platform (live performance streamed to different users) made it difficult to fix the problem simply by hiding it behind common anti-DDOS protections without causing lagging, and this meant having exposed ports which got tested by botnets. They continuously scan blocks of IP addresses, looking for open ports and available services; when one is found, other scripts explore the available port, looking for breach points (login shells, password forms, exposed info, API endpoints, etc.).

The thousands of connections received would halt the webserver down to a stop or crash the server that keeps video and user interactions in sync , unless they're taken care of by manually blocking them via firewall rules once the host has been recognized as an attacker and not a spectator of the performance; this banning process, together with the implementation of some extra stuff (such as tarpits) has ultimately been what made the performance bearable for the viewers during the last performance.

On top of the above I believe there is place for speculation about non-automated attacks during the performance (spam in chat, scanning of other ports on the server, login attempts on the server, and tests to produce results or crashes with crafted messages): my assumption is that once the server was started and ports were exposed, botnets caught the attention of their owners and they investigated on what the server had to offer; I presume they have found the open port leading to the web server and tried to interact with the chat to see if making it crash could lead to results or a possible breach point.

These events lead me to explore how this part of the Internet can be exploited to produce further results, and this led to the creation of gHOST IN THE sHELL