[{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":null,"content":"Provable fairness is one of the building blocks of modern online gambling. Many Bitcoin casinos have popped up that use “provably fair” number generation algorithms. These algorithms guarantee that the numbers generated have not been influenced by either party in a way that is favorable for them. For a more detailed explanation of these systems, read this blog post. Recently, I have been introduced to the Counter-Strike: Global Offensive gambling scene. These online casinos have sprouted up from a legal loophole. Apparently, gambling with virtual items (CS:GO skins) that hold value on a market is not illegal. However, these items can be quickly traded for cash.\nMany of these CS:GO gambling sites claim to be provably fair. I will be auditing these claims. In this post, I will provide a description of the provable fairness algorithm this website uses and some possible attacks that either the server or client could use. If this website had vulnerabilities that the client could exploit, the impact would be astronomical. Clients could predict the results of their rolls before they happened and use that information to only make rolls that have a favorable outcome for the client. Attacks that can be used by the server could allow the website operator to scam users and cause them to lose more than normal.\nCSGOWild.com CSGOWild has two games, I will be looking at both.\nCoin Flip CSGOWild’s coin flip game mode allows you to flip a coin against another user. Their provably fair page describes their algorithm as follows.\nThe server generates a “salt” (this is an incorrect use of the word salt) and a “winning percentage.” The “salt” and “winning percentage” are concatenated with a : and hashed. This is the “round hash.” The “round hash” is shared with both users taking place in the game. After the game is over, the round hash and the winning percentage are shared with both users. There are several problems with this process. The most blatant one being that the server does not take any input from the clients while creating the round hash or generating the winning percentage. The server knows which player bet on each side of the coin before it decides the winning percentage, so the server can choose which player will win before the coin is flipped. If this manipulation was combined with fake players that were playing for the house, CSGOWild could make those players win all of the bets that they made.\nRoulette CSGOWild’s roulette game does not have an entry on their Provable Fairness description page. I looked at the messages being sent over the WebSocket that the client uses to communicate with the server and found that there are no precautions being taken against the server influencing results. The server can choose any result at any time. This game mode is not provably fair at all.\n","date":"2016-06-24T04:48:37Z","site":"https://vanderpot.com/","tags":null,"title":"Auditing A CS:GO Betting Site for Provable Fairness","uri":"https://vanderpot.com/2016/06/auditing-csgo-betting-sites-for-provable-fairness-part-1/"},{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":null,"content":"This post is a basic primer on how provably fair betting websites and number generation algorithms work. It contains helpful background information for some of my future posts.\nWords to Know Provably fair number generation algorithms are built around cryptographic hashes. Provably fair systems rely on these hash functions taking input data (the plaintext or message) and outputting a representation of that data that can not be reversed, but is the same every time (the hash or message digest). These hash functions can be broken by brute force if the plaintext is is short enough. Therefore, in order for a hash to be secure, the plaintext must be long enough and complex enough so that the hash can not be broken by brute force.\nTwo other terms that are commonly used in describing a provably fair number generation algorithm are the server and the client. The server is the digital equivalent of the “house” or casino. The client is the gambler or you.\nMost Provably Fair Algorithms Most provably fair number generation algorithms work similarly to the steps below.\nThe server generates a server seed. The server seed is usually a random string of numbers and letters that is long enough to be considered cryptographically secure. The server hashes the server seed and sends it to the client. The client saves this information so that the round can be verified later. The client generates a client seed and sends it to the server. This is another string of numbers and letters. However, this string does not have to be cryptographically secure because it is never used in an important hash function. The server concatenates the plaintext of the server seed, the client seed, and a counter value. The server converts this value into a number and uses that as the roll result. The server increments the counter value and repeats step 4 for each subsequent roll. The client seed is also regenerated. When the game is over, the server sends the plaintext of the server seed to the client. Why does this work? This algorithm guarantees that neither the client nor server can influence the results of the numbers generated. Because the client knows the hash of the server seed before the roll, the client can verify that the server seed was not changed during the game. Therefore, the client can verify all of the inputs to the number generation algorithm before the game starts, but is unable to determine the outcomes of the number generation algorithm until after the game.\nThe procedure for turning this concatenated string into a number mentioned in step 4 must also be publicly known. Provably Fair betting sites usually publish a page that explains exactly how they concatenate the inputs and how they turn those inputs into a number. The page includes enough detail to allow anyone to reproduce the algorithm and independently verify that the results were not manipulated. These pages usually also include a calculator that allows the user to verify game results using the hash of the server seed, the plaintext of the server seed, and the client seed.\nCaveats The algorithm described above only works for singleplayer games.\n","date":"2016-06-24T04:16:54Z","site":"https://vanderpot.com/","tags":null,"title":"Basics of Provable Fairness","uri":"https://vanderpot.com/2016/06/basics-of-provable-fairness/"},{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":null,"content":"A determined hacker can expose the origin IP address of a website behind a reverse proxy service using many methods. One of the methods I have seen used against me is scanning the entire IPv4 address space and making an HTTP request to every IP address with the Host header set to my domain. If the origin server responds to this request with the same page that is served over CloudFlare, the attacker will know that they have found the correct origin server.\nI wrote this script to generate an NGINX configuration file that will only allow access to a website from CloudFlare IP addresses. Although using the configuration that this script generates will make it harder to find your site’s origin IP address, attackers can still use methods like e-mail origin headers, WordPress pingbacks, and social engineering to find it. This script should not be the only method you are using to protect your website.\n","date":"2016-06-18T16:38:55Z","site":"https://vanderpot.com/","tags":null,"title":"Securing NGINX with CloudFlare","uri":"https://vanderpot.com/2016/06/configuring-nginx-to-work-with-cloudflare/"},{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":["Amazon Echo"],"content":"Filesystem Information While searching through the partial filesystem I extracted from the package updates, I found /etc/dev.tar which appears to be a skeleton of the dev filesystem. We can infer several things about the partition layout on the internal MMC with this information.\nBuilding the SD Card Partitioning the SD Card It appears that uBoot will only attempt to use the partition named main-A as the root filesystem. I created a small partition named _ because there is a bug with get_partition_num that will cause it to occasionally be unable to find the first partition on the disk.\nInstalling the TI SDK We’ll need the files from the TI SDK to supplement what isn’t available in the Amazon packages. We will extract the filesystem provided by TI for this CPU, then extract the Amazon provided files over it.\n","date":"2016-06-18T15:53:37Z","site":"https://vanderpot.com/","tags":["Amazon Echo"],"title":"Amazon Echo Rooting: Part 2","uri":"https://vanderpot.com/2016/06/amazon-echo-rooting-part-2/"},{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":["Amazon Echo"],"content":"Update: You can view Ike Clinton’s paper that is mentioned in this article here. It is the basis for most of this research so far. There is also a Slack channel and wiki about this subject. The PCBs I ordered came in but I haven’t had time to solder the components on or test it out. A few people in the Slack channel have gotten their own code running on the Echo, so it is possible!\nIntroduction I’ve been tentatively looking around for a root exploit or method for the Amazon Echo (not a referral link) since I got mine exactly a year ago. I love what it does and that it’s skills are being expanded every day by the Alexa Skills Kit, but I want to dig deeper into the code running on the device and possibly develop some lower level applications than what is allowed by the Alexa Skills Kit or add more music providers (I’m a Google Play Music user). A side effect of my endeavor into the Amazon Echo is being able to audit it for privacy. A few years ago, nobody would have been on board with putting a device specifically designed to listen to you 24/7 from a company like Amazon into their home. Now, the Echo is making appearances in homes across the country. I don’t personally believe the theories that Amazon is always listening (Wireshark strongly implies that they’re not), but I will be able to audit the software to make sure they aren’t.\nI’ve come up with several possible ways to gain access to the Echo:\nExploit vulnerable service: Embedded devices are notorious for running out of date software with serious security flaws. However, the Echo has very strict firewall rules that prevent access to most services that are running. Command injection: The primary user input of the Amazon Echo is the user’s voice. The Echo just uploads the audio data it records to Amazon and gets a response to relay, so it is extremely unlikely that we will be able to gain access to the Echo this way. Hardware: The Amazon echo has several debug pads on the bottom of the device that had an unknown function until recently. This is probably the most viable way to gain access to the device. I plan to use this method first, then look around inside the device for any other vulnerabilities. Gathering Information After connecting the Echo to my network and observing it’s traffic, I noticed that it downloaded updates in the clear. The Echo uses a modified version of the Debian Package file format with added support for signing of packages. I assume that the echo will not install packages that are not signed by the correct keys. The Echo downloads a package that contains a “manifest” from amzdigitaldownloads.edgesuite.net. The manifest is a list of all available packages.\nWhile looking through the filesystem, I noticed a static network configuration for a USB Ethernet adapter. This is probably for internal testing at Amazon. We have seen this testing cradle with Ethernet connector in public during a demo of its integration with Vivint security. There are several other interesting bits of information like several references to the project’s original codename “doppler” and voice model data for using the word “Echo” as a wake word instead of “Alexa” or “Amazon.” There is also a firewall setup script that allows us to see which ports are open during normal operation and setup.\nThanks to a research project by Ike Clinton and an anonymous source, we now know the pinout of this test header. The Ethernet port was likely connected using SDIO on the SD card pins. There is also a UART console available on UART TX/UART RX at 115200 baud, but it does not accept any user input during the boot process. Attempts to halt or interrupt the U-Boot process were unsuccessful.\nAnalysis of the Echo’s bootloader code shows that it will attempt to boot from an SD card if one is connected to the pins on the debug header. The pads on this header are slightly smaller than 1x1mm square with a 2mm pitch. To avoid tearing pads off my Echo if I made a mistake and to make the process of connecting an SD card and UART header to an unmodified Echo easier, I attempted to create a 4×5 block with 2mm pin headers. I spent a few hours fiddling with melting the cheap plastic on the headers I had and decided to try to design my first breakout board to use with pogo pins.\nThe breakout board takes the 4×5 2mm header on the bottom of the Echo and converts it to a MicroSD socket and .1inch header that exposes UART TX, UART RX, GND, and +15V for power. I ordered 10 of these PCBs. When they come I’ll solder on all the components and write another post on creating a SD card that the Echo will boot off of. Hopefully from there I can edit some scripts on the Echo to enable a telnet server and punch a hole in the firewall to allow access to the running system.\n","date":"2016-06-17T20:50:54Z","site":"https://vanderpot.com/","tags":["Amazon Echo"],"title":"Amazon Echo Rooting: Part 1","uri":"https://vanderpot.com/2016/06/amazon-echo-rooting-part-1/"},{"author":{"domain":"vanderpot.com","image":"https://avatars.githubusercontent.com/u/553597","name":"Alex Vanderpot"},"categories":null,"content":"Recently, a close friend sent me a link to this blog post. The blog post goes over some details about exporting package relationships for Ubuntu in a format that can be read by graph generating software. The blog post was made in early 2013, so I decided to try it myself and add a few things. I made some slight modifications to his code, which can be found below.\nThe original blog post only contained image renderings. I imported the data into Gephi and produced several SVG renderings of the graph. I then overlayed the vector graphics onto a blank map using the Google Maps API. There are a few renderings with different graph parameters to choose from. The big dot at the center of the graph is libc6, which makes vulnerabilities like CVE-2015-7547 seem very scary.\nClick the image below to load the map visualization. Be forewarned, the SVG file is 3mb and can slow down some browsers.\nA note about this code: Apparently the approach used in this snippet only shows a subset of packages that are in the apt repos. Thomi Richards did a follow up post explaining this. I may redo the map with the updated dataset, but I belive that this is sufficient for now. Also, I don’t want to run Gephi’s placement algorithm for another 4 hours. Thomi’s original code, slightly edited and reformatted, is reposted below.\n","date":"2016-05-06T19:29:14Z","site":"https://vanderpot.com/","tags":null,"title":"Debian Package Visualization","uri":"https://vanderpot.com/2016/05/debian-package-visualization/"}]