Is Construct 3's Multiplayer a security flaw?

Not favoritedFavorited Favorited 0 favourites
  • 3 posts
From the Asset Store
Casino? money? who knows? but the target is the same!
  • Its me again with my bizarre forum posts. This time I want to discuss a huge security flaw with construct's multiplayer object, and the potential damage that can follow if the security flaw isn't fixed.

    We all know that multiplayer can be used to send messages across different devices. That's the entire premise of the feature. However, despite its primary use being to transmit data packages across different devices to synchronize player characters and other game instances, it can also be used with malicious intent.

    Take for instance, a fake game sent to a client PC. Multiplayer connects, and the host PC can now send remote code execution to the client PC via "broadcasting multiplayer messages", which when paired up with construct's built-in Javascript feature (that can be used to execute commands on a computer and interact with it in many ways,) creates one hell of a malware program.

    Multiplayer can then be paired with other features of construct, such as geolocation and camera, making for an even more dangerous tool. With the recent addition of file transfers to the Multiplayer instance, construct can, and most likely will if placed in the wrong hands, be used for malicious intent as a remote access trojan.

    And the cherry on top is that construct programs are trusted software. Essentially, this means that no antivirus will flag or even suspect a construct-exported application to be malware.

    I dont know how this was overlooked, but it is a big, BIG security flaw that can cause severe damage to not only individual client PC's, but to the trust and reputation of Scirra. Please, take this message from a game developer and penetration tester and fix the multiplayer security flaws.

    Thank you.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • ....

    Take for instance, a fake game sent to a client PC. Multiplayer connects, and the host PC can now send remote code execution to the client PC via "broadcasting multiplayer messages", which when paired up with construct's built-in Javascript feature (that can be used to execute commands on a computer and interact with it in many ways,) creates one hell of a malware program.

    ...

    All this can be done on every popular engine, unity, godot, defold. You don't even need a game engine to do this, you can use a programming language and libraries.

    Multiplayer can then be paired with other features of construct, such as geolocation and camera, making for an even more dangerous tool. With the recent addition of file transfers to the Multiplayer instance, construct can, and most likely will if placed in the wrong hands, be used for malicious intent as a remote access trojan.

    ...

    The browser or smartphone user must provide access to microphone location or other functions.

    And once again, this can all be done with the help of many tools.

    And the cherry on top is that construct programs are trusted software. Essentially, this means that no antivirus will flag or even suspect a construct-exported application to be malware.

    ...

    Then maybe we should ban the use of kitchen knives, because they can also be used to cut.

  • Everything can be hacked but webrtc is encrypted and can only really be exploited with complex man-in-the-middle attacks where the attacker already had access to the victims device (which, as you'd know as a pen tester, is already the worst possible situation if the attacker has admin access to the victims device).

    The fake game scenario, what message could be sent that allows RCE attacks? And if an exploit was found, this would be patched by Google/other browser devs.

    Let's assume an attacker could send messages to fire "execute javascript" actions - this would be limited only to the game/tab and would behave accordingly as a browser does, e.g. The attacker tries to get geolocation, then the victim will see a popup asking to allow/deny geolocation, which they would likely deny.

    File transfer, again I would not worry: let's say someone sends a virus exe file. Victim receives this... The victim cannot run this exe through a Construct game (unless very specifically using NWJS - Open Shell action, which, I would imagine is rarely used). Even if somehow the exe could be transmitted and executed, the victims device would have windows defender/antivirus software, most of which test an exe in a sandbox, or simply delete the exe if it is potentially dangerous, so no worries there.

    But, yeah, any game engine, godot, unreal, unity, anything - can be used to make malicious software, esp with multiplayer functionality.

    It's not the company's or Scirra's fault if someone designed their game poorly where geolocation data is easily sent unwillingly sent due to an oversight from the game dev, or easy packet sniffing/sending (I presume webrtc makes resending packets not viable).

    Things like NWJS have already been used maliciously outside of Construct, to make cryptominers and such that run silently on the victims device. It's probably why antivirus software flag innocent exports of NWJS (or it relates to the exe being signed, who knows).

    All in all, I wouldn't worry about this, and would only worry about how a game dev designs their multiplayer code - hopefully not having a game that relies on geolocation to play and has multiplayer, and peers have a button that a peer can click, to get host to gather all peer's geolocation data to send back to them. That'd be foolish and that game dev would certainly have a tarnished reputation after a stunt like that!

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)