Hawkheart's personal site Zola 2018-09-19T20:29:33-04:00 https://hawkhe.art/atom.xml 2018-09-19T20:29:33-04:00 2018-09-19T20:29:33-04:00 Unknown https://hawkhe.art/writeups/not-protobuf/ <blockquote> <p>I'm in this company's network and I've MITM'd this weird protocol between a dev client and server, but I can't figure out how it works. Connect to reversing.chal.csaw.io:9002 and I'll send the client traffic to you. Forward it on to the dev server at reversing.chal.csaw.io:9001 to figure out what's going on. Once you're ready, hit up the prod server at reversing.chal.csaw.io:9000 which should have a flag for you.</p> </blockquote> <p><em>Solved with <a rel="external" href="https://twitter.com/jack7764">jack2</a> and <a rel="external" href="https://twitter.com/Plailect">Plailect</a>!</em></p> <p>This was an interesting reverse engineering challenge we solved during the qualification round for CSAW CTF this year. Only one other team, REdefined Behavior, solved the challenge during the 48 hours given. We are given a number of endpoints to connect to – one which provides a "development client", and two which provide "development/production" versions of the server this client is intended to talk to. The challenge description implies that our final goal is to reverse engineer the network protocol well enough to communicate with the prod service.</p> <p>We began exploring the activity of the service by writing a script that would connect the development services and record a conversation between them (acting as a man-in-the-middle). Simply looking at this traffic doesn't reveal much information, though – we can see two plaintext messages (a hello message, and an acknowledgement) before the client initiates TLS.</p> <p>The one thing we are able to gather from these messages is a bit of the message structure. It appears that each message sent begins with 4 random bytes, and then ends with those same random bytes. For example, the hello message (<code>0x41ca</code>) could be sent as <code>0x0102030441ca04030201</code> and the acknowledgement message (<code>0x0aca</code>) could be encoded <code>0x414243440aca44434241</code>.</p> <p>We then modified our script to man-in-the-middle the TLS traffic. This was fairly easy to do, as the client/servers do not require a valid certificate to function. Using this enhanced script, we captured a number of conversations between the client and the servers.</p> <p>Forensing of the now-decrypted message traffic allowed us to determine the flow of the application traffic:</p> <ol> <li>The client connects to the server and sends a "hello" message.</li> <li>The server responds with an acknowledgement.</li> <li>TLS is initiated on the connection between the client/server.</li> <li>The server sends a "hello message."</li> <li>The client responds with an acknowledgement.</li> <li>The client sends a message that appears to contain a username/password pair.</li> <li>The server responds with an acknowledgement on success, or an error message on failure.</li> <li>The client sends some sort of request.</li> <li>The server sends a response which is a single null byte followed by some portion of the end of the request.</li> <li>Repeat ⁸⁄₉ until the client has finished.</li> <li>The client sends a message <code>0xbbca</code> and disconnects.</li> </ol> <p>Further investigation of the traffic (and modification of traffic between server/client) allowed us to serialize our own messages.</p> <p>Each message begins with a one-byte message type. The official client uses the following message types:</p> <ul> <li>0x00: Value at location</li> <li>0x0a: Acknowledgement</li> <li>0x20: Login request</li> <li>0x41: Hello</li> <li>0x78: Set value location</li> <li>0xbb: "Bye-bye"</li> <li>0xee: Sent by the server on error.</li> </ul> <p>The acknowledgement, hello, and goodbye messages all take no arguments, which is serialized as <code>0xca</code>. We found that strings are serialized as a space (<code>0x20</code>) followed by a two byte length prefix, followed by the string itself. Any integers are serialized with a type code of '0' followed by a <a rel="external" href="https://developers.google.com/protocol-buffers/docs/encoding#varints">Base 128 varint encoding</a> of the integer.</p> <p>Most interestingly, though, are the list/tuple tuples (beginning with <code>0x00</code> and <code>0x01</code> respectively). These types are serialized with their type code, followed by a series of bytes for the length for the serialized form of each list element. A null byte is used to indicate the end of the list. Following this are the serialized forms of each element in order.</p> <p>For example, the steps to serialize the tuple <code>("Hello", "serialization!")</code> would be:</p> <ol> <li>Serialize the first element of the tuple (<code>0x20000548656c6c6f</code>)</li> <li>Serialize the second element of the tuple (<code>0x20000e73657269616c697a6174696f6e21</code>)</li> <li>Serialize the tuple header (<code>0x01081100</code>)</li> <li>Append the serialized elements to the end of the header to produce the final serialized value.</li> </ol> <p>Now that we are able to serialize our own messages, we need to figure out what we need to send the server. Trying all 256 possible message types finds us an interesting message type ('f') which tells us to repeat the request with the value at a given coordinate pair, which is randomized on each connection to the server.</p> <p>At this point, we were stuck until the third hint was released:</p> <blockquote> <p>hint 3: "for the final stage, the server's prompt is just trying to confirm that the client has the data that an official client would have. It is referring to what the client sends."</p> </blockquote> <p>With this hint, we figured out that each time the dev client connected to the server, it would set the value of 10 different coordinates. We then wrote a script to gather the values sent by the client for each location on the grid. After gathering a large enough set of values, we retried sending a flag request until the server requested the value of a location we knew the value of. The server then responded with a message containing the flag!</p> 2017-11-06T00:00:00+00:00 2017-11-06T00:00:00+00:00 Unknown https://hawkhe.art/writeups/footbook/ <blockquote> <p>Don't like Facebook? Try our brand-new social networking service!</p> </blockquote> <h2 id="tl-dr">tl;dr</h2> <p>Proxy requests from 127.0.0.1:3000 to the remote server: <code>socat TCP-LISTEN:3000,fork TCP:13.114.238.13:80</code></p> <p>Register a Dropbox account with email address <code>admin+something@footbook.meh</code></p> <p>Log in to site at 127.0.0.1:3000 using Dropbox OAuth</p> <p>Get flag!</p> <h2 id="explanation">explanation</h2> <p>We are presented with a very simple social media website that allows registered users to make public posts and send messages to other registered users (via their email address).</p> <p>Email addresses for users who log-in directly via username/password are given email addresses of the form <code>username@user.footbook.meh</code>.</p> <p>An admin user (<code>admin@footbook.meh</code>) can be found by visiting profile ID 1... and they have a post:</p> <blockquote> <p>Only I can see the flag ^_&lt;</p> </blockquote> <p>So we have our target.</p> <p>There doesn't appear to be anything interesting to do in the actual site, so we return to the login page.</p> <p>Each of the OAuth login options is disabled (client-side) because our host isn't <code>127.0.0.1:3000</code>. Ignoring that, and visiting the Twitter OAuth login page, we can log-in via Twitter and our user email will be the email on the Twitter account. Unfortunately, Twitter will only allow us to create/log-in with email addresses we control (and we do not control <code>admin@footbook.meh</code>)</p> <p>The other two OAuth providers (GitHub and Dropbox) reject our login for having a different callback URI than expected, and using plain HTTP for a callback URI on a domain/IP other than localhost, respectively. However, if we proxy requests from 127.0.0.1:3000 to the remote server and access the website using it, both of these login systems begin working.</p> <p>Examining GitHub and Dropbox, we find that Dropbox does not require you verify control of an email address before using it for OAuth authentication. Unfortunately, the email address <code>admin@footbook.meh</code> is already taken on Dropbox, so we will have to find another way.</p> <p>Rereading the JavaScript code for the message-sending code, we see that it only uses data before the first <code>+</code> character in the email username (so sending a message to <code>user+something@user.footbook.meh</code> sends a message to <code>user@user.footbook.meh</code>). We surmise that the OAuth registration code on the server is doing the same thing (otherwise, no messages can be sent to users with <code>+</code> in their email address) and register a Dropbox account with an email address like <code>admin+something@footbook.meh</code>.</p> <p>We are able to successfully log-in to the site, and at the top of the page is a box with the flag!</p> <p><code>hitcon{mom_said_i_can_trust_oauth_T_T}</code></p>