Author: c0nrad

Building a physics engine

I’ve been thinking about going back to school for physics. Not as a career or anything, just as a hobby. If I’m going to spend my free time doing something, learning more about who we are, where we came from, and the universe we live in, seems like a sensible thing to spend time on.

And I learn best by doing! So here I am. And it’s just fun.

I don’t know where this will go, but as long as I’m having fun I’ll keep this going.

Demo

Figure 1: Terminal based physics simulation

What is it?

So far it’s a super bare-bones “physics” engine. It’s actually 3d, but I’m not rendering the depth, so it’s just a 2d slice (z=0).

Right now it supports AABB (axis aligned bounding boxes) (a fancy way of saying a box that can’t rotate). And spheres (point particles). The only force it knows about is gravity, and the conservation of momentum.

Where do I want to go?

Short term I’m reading Game Physics Engine Development (by Ian Millington) and watching Math for Game Developers (by Jorge Rodriguez) both have been immensely useful. I did not realize that rotations in 3d would be so complex! Never heard of a quaternion before reading/watching these resources.

Long term I want to continue programming different things I learn as I continue physics just to make sure I really understand it. I’m excited to eventually move into quantum/relativity. But first I want to make sure the basics.

I also had a couple of ideas for little games:

• A particle collider game similar to the game “Kerbel Space Program” where you build ever-increasing particle colliders to discover components of the standard model. I’d need to learn a lot more about the history of particle colliders to do this.
• I never liked Physics Lab in school. I think it would be cool to move Physics Labs to VR. It be cool to “see” the electromagnetic fields as you interact with coils and such

Anyways, thanks for reading. Toodles!

https://playdarkchess.com / https://github.com/c0nrad/darkchess

I joined a new team at work, and figured it’d be fun to build something that uses their tech stack (java jersey/react), and thus DarkChess was born.

Why DarkChess?

I love Chess, I used to play on the chess team in high school and I was president of the Chess club back in college. It’s a fun game, but it’s a perfect information game meaning everyone has the exact same amount of information. Which is good, but it’d be fun if part of the game was to learn information.

And that’s what DarkChess is. In Darkchess you can only “see” pieces if they are in your capture zone.

This brings a fun element to the game where you have to use pieces to scout where the enemy is located. It also allows you to be sneaky with assassinations, and leverage high visibility pieces and open lanes much more.

I built a little story mode with a series of challenges, give it a try:

http://playdarkchess.com/#/story/1

Tech Stack

I haven’t built a Java app in awhile, but it was fun to build one from scratch (using vscode too, no eclipse magic).

My personal opinions on the matter:

Backend

• Maven was a real life saver for managing dependencies and the build chain
• JUnit was simple enough for testing, I would of liked to learn more about cucumber, maybe next project
  • No surprise, but the chess engine I built had some interesting gotchas that were thankfully caught by unit tests
• Morphia for MongoDB was interesting, (not sure if I’m using it correctly) GameDatastore.java
  • Unfortunately there was some issues with serializing a 2-dimension array. Had to write some pre-post serialization code that was a tiny bit frustrating
• Jersey is very cool. I love using decorators for tagging function routes. Keeping the route/method/function in one spot is very nifty instead of having to declare the route<->function binding in a routes.js or something similar.

UI

• The react documentation is amazing! https://reactjs.org/docs/hello-world.html
  • It’s so simple, and a fun read. After reading the 12 different steps I felt like I knew react decently well (I have a background in angularjs)
• react-router-v4 was very confusing and frustrating for me (specially with typescript). Not being able to say “go to this state” everywhere unless it was specifically defined within the <HashRouter>. I def missed angular’s dependency injection and $state.
  • But again, I was probably just using it wrong
• ‘create-react-app’ was pretty nify for building production ready minimized builds. no more messing around with gulp files or googles minimizer.

Deployment

• I went full into AWS for my CI/CD pipeline
  • AWS CodeCommit – Git remote, kicks off the pipeline
  • AWS CodeBuild – builds and tests the code (buildspec.yml), published artifacts to s3
  • AWS CodeDeploy – deploys to my ec2 instances (appspec.yml), restarts the darkchess service and some housekeeping
• Dependencies suck, so I build fat jars (maven shader), which means they just include the dependencies.
• DNS entry through route53 to an ALIAS ALB infront of the ec2’s. (stateless thanks to MongoDB, so easy to scale).
• Logs are sent to Cloudwatch using the aws cloudlog agent. It was a little weird to setup, but it works
• The service is run in an init.d/ script with nohup
  • I’ve had 0 outages so far! (knock on wood)

Conclusion

Overall it was a very fun project. Learned a lot about fully setting up a java project.

Questions/comments/conseling/concerns? Always feel free to reach out 🙂 c0nrad@c0nrad.io

This is really just a security misconfiguration. But if you’re using CSP (Content-Security-Policy), it’s something to keep in mind.

The tl;dr is make sure object-src is ‘none’ if you’re not using it.

Using this “attack” you can reflect SVGs to get execution even in a CSP controlled environment. This is just another recipe to add to your books for bypassing CSP (insecure directives, JSONP, base offset, encoding).

I feel like this website is becoming a cookbook. As long as you have all the ingredients, you can make some tasty ‘sploits.

Ingredients

• Website with File/Image Upload (accepting SVG), pretty much any website that allows profile pictures
• Website with CSP default-src ‘self’ and/or object-src ‘self’
• An XSS injection, we still need an XSS to start the chain.

Directions

1.) Using the image upload, upload an SVG with a payload like:

2.) Using your injection, inject the following code:

3.) Profit. That wasn’t too hard?

It’s also really neat that the script-src can be ‘none’.

Thoughts

It’s pretty similar to the JSONP trick to bypass CSP, we just have another vector for content reflection.

Also it’s kind of neat how we’re getting to the point of needing to chain bugs on the web. It reminds me of people trying to find info leaks to bypass ASLR so you can get your initial bug to work.

Mitigation

Make sure that your CSP policy sets object-src to ‘none’ if you’re not using it.

Did you know multiple cookies can have the same name on a domain? Yep, cookies aren’t unique on the name, they are “unique” on the tuple of (Name,Domain,Path).

So you could have a session cookie for example.com/secret, and a different one for example.com/ with the same name. Why would you want to do that? ¯\_(ツ)_/¯

But what sorts of attacks can we do with that?

Scenario

Lets say we built a Single Sign On (SSO) solution for our enterprise. We know the pesky developers are going to want to create insecure apps for other employees to use. So we provide some facilities to make authentication of users easier by using the same corporate cookies everywhere.

We allow developers to host application on *.corp.example.com, but all traffic gets funneled through a bastille host that checks to make sure the user is logged into the corporate network first. Once a user logs in we assign a cookie corporate-username, and proxy the request to the right application.

The application can then check the cookie corporate-username to see who is accessing their site.

But, we know that cookies can be easily spoofed, so we add an extra protection and tie the corporate-username cookie to a corporate-token cookie. When a user logs in, we also generate a uuidv4 and store it in a database. So when the user tries to connect to an application, the request is proxy through the bastille host and a lookup is performed to make sure the corporate-token and corporate-username match up.

The developer applications can now trust that corporate-username is the correct username.

The Attack

This attack involves a little bit of luck on how the web servers handle cookies. It worked for me once, so hopefully it’ll work for you too. But basically we’re going to bait and switch cookies.

What if we sent two corporate-username cookies? How do servers handle multiple cookies with the same name?

Different servers handle it differently.

But if we’re lucky, the application we’re trying to attack and the bastille host do it differently from each other.

Lets say the bastille host uses the first instance of corporate-username and the corporate-token, and the application uses the last instance of the same cookie name.

We log into the bastille server, generate a valid cookie/token pair, but then add an extra cookie to our attack payload:

POST /entry/create
Host: blog.corp.example.com
Cookie: corporate-username=c0nrad corporate-username=admin corporate-token=c0nrads-token

{data: ‘I admin certify that c0nrad is the coolest’}

The bastille will see a valid username/token pair (c0nrad/c0nrads-token), so the request is forwarded, but the application on the other side accepts the second corporate-username (admin). We can now perform actions as anyone in the company!

If the bastille server uses the last cookie, just switch the order of the cookies and pray the application uses the latter cookie.

Conclusion

Basically this bug is HTTP parameter pollution but for cookies.

But, we were able to abuse the fact that you can have multiple cookies with the same name to bypass a SSO solution and perform actions as anyone in our imaginary company.

Just another tool for the toolkit.

I’ve been wondering if it’d be possible to make CSRF worms. Usually we propagate worms using XSS, but with modern frameworks and CSP it’s getting a little harder to find good injections.

But I’ve sort of pieced together a fun attack. Basically we’ll create a worm that has a bunch of layers that have to be peeled away. Each time it spreads it gets smaller and smaller, and the actual “exploit” lives at the very end.

The Setup

For example lets say Twitter was using CSP (which they are), and SameSite cookies and introduced a CSRF that when viewed, added a chosen user as a follower:

GET https://twitter.com/addFollower?user=xc0nradx

• Adds the user as a follower.

You could try pasting that URL in an image tag all over the place and try to get as many twitter users as possible to view it.

But we can do better. Lets say twitter also introduced another CSRF-able route:

GET https://twitter.com/updateProfilePicture?url= https://gravitar.com/c0nrad@c0nrad.io

• Sets the profile picture to the url parameter. This image is then displayed on the profile as an image tag.

The Exploit

We can use the updateProfilePicture route to place the addFollower payload and get a bunch of followers. But the people who see it are already our followers. Instead we want the worm to propagate by itself.

The updateProfilePicture route can be used to spread the worm. We can embed the addFollower payload in a couple of ‘setProfilePicture layers’, so when our followers see our profile picture, their profile picture becomes a smaller version of the worm. 

So we could ‘link’ a bunch of CSRFs together to make something like:

So the first time someone see’s this in an image tag, the CSRF will be executed, and their profile image will be the same URL except one ‘link’ smaller.

Anyone who then see’s this profile picture will then copy the URL and become one link smaller.

After the worm has spread for awhile the very last link in the chain will become the profile picture. So now anytime someone views the profile/feed of that user they will follow xc0nradx.

Hopefully by this time the worm has spread to a bunch of users. Now all of our friends and their friends and their friends are helping us get followers. Thanks friends!

Thoughts

The only benefit this worm really gives is a better launching point for your original addFollower.

But it doesn’t abuse HTML at all! It should work fine with CSP and XSS encoding frameworks? You might have to be careful about URL encoding and parsing.

Also the chains will probably unlink really fast. Anytime you view yourself you’ll unlink another chain yourself.

And you don’t need to include the https://twitter.com in each stage. Just use the relative URL, but it’s easier to read with the full hostname. The max length of a URL is ~2000.

Conclusion

We created a worm-able CSRF exploit that carried our original CSRF exploit to a bigger userbase. Fun stuff. Feel free to email/comment if you have any more ideas.

This weekend I decided to implement BSON.

http://bsonspec.org/

BSON is just a binary representation of JSON with some extra types and traversal speed improvements.

Traversal speed is important for rapidly scanning a group of BSON objects (called Documents) for specific pieces of information.

Lets imagine you had a list of JSON like the following, and you were searching for the information under the key value “secret”.

{ “aaaaaaaaaaaaaa…..aaaaaaaaaaaa”: “world”, “secret”: “IMPORTANT INFO” } { ‘aaaaaa’: 123, “secret”: “more important info”}

A scanner has to linearly read each character one at a time since it doesn’t know when the ‘a’s end. If that list of ‘a’ was 10 megabytes long, we’re going to waste a second or two every time we want to read the value of ‘secret’.

BSON makes this simpler by pre-pending string lengths so if you can jump throughout the Document for much quicker scanning. BSON leaves little clues about the contents of each element so you can jump around without having to scan the entire contents.

Specification

BSON is binary JSON with some extra types. The top level object in BSON is a Document. A document is a collection elements. Each element contains three things:

• The Type Identifier (byte)
• Element Name (string)
• Contents (string,date,int,subdocument)

And that’s it!

Implementation

Normally when I implement something like this, I jump write into implementing the Marshal/Unmarshal code (serialize/deserialize).

This time I decided to take a different approach and instead focus on the types.

I started with the base types, and how they should be represented in BSON.

So types like int32, int64, double, cstring, string.

type Double float64
type Int32 int32
type Int64 int64
type CString string
type String string

And for each newly defined type, I made sure they implemented the BSON interface I created:

type BSON interface {
   ToBSON() []byte
   ToString() string
}

Once I had all the base types complete, I started implementing the core of BSON, the elements. I also wanted all the elements to implement the BSON interface. This was super simple thanks to the fact that all of the children types were already implementing the BSON interface:

type Element struct {
   Identifier byte
   EName CString
   Data BSON
}

func (e Element) ToBSON() []byte {
   out := []byte{}
   out = append(out, e.Identifier)
   out = append(out, e.EName.ToBSON()...)
   out = append(out, e.Data.ToBSON()...)
   return out
}

func (e Element) ToString() string {
    return e.EName.ToString() + ": " + e.Data.ToString()
}

After that, all I had left to do was define the types that used the Elements, and make sure they also implemented the BSON interface, which was simple since all their children already knew how to represent themselves too.

type Document ElementList
type ElementList []Element

And I was done!

So now I can create new Documents, and just call ToBSON(), and the document asks all it’s children to represent themselves in BSON, which ask their children to represent themselves in BSON.

Closing Remarks

What I really like about this implementation is that now I can use this library (probably for a fuzzer), and have it generate BSON for any type in the entire stack. Every type corresponds to BSON making the library much simpler than only operating on documents.

You can check out the implementation here:

https://github.com/c0nrad/bson