Everyone has at least a few games on their computer, and I would assume most of the Hackaday readership would be among the enlightened PC gamer bretheren. At this year’s DEF CON, [Tamas Szakaly] gave a talk about the data these games leak to the Internet, the data they accept from the Internet, and what you can do with that data.
[Tamas]’ talk was entirely about scripting games, like the many games that are scriptable in Lua, or Valve’s Squirrel. Developers have thought about this before and have implemented sandboxes and many anti-cheat mechanisms. However, because these sandboxes are poorly implemented, it’s easy to get outside the game and do some real damage.
[Tamas]’ first target was Crysis 2 and the CryEngine3. This game uses a Lua scripting engine and has no sandbox whatsoever. That means [Tamas] can call os.execute, and from there the entire game is over. Or it’s just begun. Either way you look at it, it’s pretty bad.
CryTek notwithstanding, [Tamas] can also use games with Lua scripting that have a real sandbox. DOTA2 has a leaky sandbox and can be used to call OS I/O routines and execute base 64 encoded executables right over the main executable.
The most impressive example of script abuse in various multiplayer games is from Garry’s Mod. This game has custom implementation of dangerous functions, restricted file IO, and a proper Lua sandbox. This was a wise decision from the developers, but the library is huge. If you create a map or mode used on a server, you can have a full HTTP proxy to the gamer’s home network. During the talk, [Tamas] used this exploit to display an image from a webcam on a Garry’s Mod server. It was on the podium right next him, but this could have been done on a server on the other side of the planet.
Continue reading “DEF CON: Abusing Scripts in Multiplayer Games”
The Intel Edison is an incredibly small and cheap x86 computing platform, and with that comes the obvious applications for robotics and wearable computing. [mz] had another idea: what if the Edison could do work that is usually done by workstations? Would it make economic sense to buy a handful of Edisons over a single quad-core Xeon system?
[mz] thought the Edison would be an ideal platform for fuzz testing, or sending random, automated data at a program or system to figure out if they’ll misbehave in interesting ways. After figuring out where to solder power and ground wires to boot an Edison without a breakout board, [mz] got to work benchmarking his fuzz testing setup.
Comparing the benchmarks of a fuzzing job running on the Edison and a few servers and workstations, calculations of cost-efficiency worked out well for this tiny x86 system on module. For parallelizable tasks, the Edison is about 8x less powerful than a reasonably modern server, but it’s also about 5-8x cheaper than a comparable desktop machine. Although renting a server is by far the more economic solution for getting a lot of computing power easily, there are a few use cases where a cluster of Edisons in your pocket would make sense.
Here’s a quick prototype from [Travis Goodspeed]. It’s a smart card built around an MSP430 microcontroller. We’ve used the MSP430 in the past because of its low power demands. He says this business card currently supports 1.8V to 3.3V, but a future design will have 5V as well. Technologies like Java Card exist for running applets on smart cards, but a familiar microcontroller like the MSP430 could certainly make development much faster. Knowing [Travis], there’s a reader somewhere about to go through some serious fuzzing.
[I)ruid] from BreakingPoint Labs has been doing quite a bit of protocol reverse engineering as part of his work. He put together a post covering some of the tools that have been useful for this task. Text-based protocols have a lot of human readable characters that can help you identify fields. Binary protocols don’t have this luxury though. He recommends the Protocol Informatics Project for tackling these situations. It applies bioinformatics algorithms to network traffic. You give it a packet dump of the protocol and it compares them to find similarities the same way genetic sequences are compared. It can be confused by protocols that waste a lot of space, but it’s still a very clever approach to reversing.
Which is a better method for finding vulnerabilities, fuzzing or static-code analysis? The question will be put to the test at next month’s Black Hat USA conference, where two experienced
hackers security researchers will be given a piece of mystery code and one hour to find all the vulnerabilities they can using one of the two methods. [Charlie Miller] from Independent Security Evaluators will use fuzzing and [Sean Fay] from Fortify Software will use static-code analysis to detect the vulnerabilities in the code. We reported on [Miller]’s fuzzing talk while at Toorcon 9.
The pair will be allowed to use their own equipment, but they won’t see the code until the moment the showdown begins. For an added bit of fun, conference attendees are welcome to join in the contest. The audience member who finds the most exploits within the hour wins a free dinner at a new Las Vegas restaurant. But you don’t have to wait until then to weigh in; go ahead and post your thoughts on fuzzing vs. static-code analysis in the comments, just be ready to back up your claims.