4 ms·
I didn’t quite understand the need for an injection attack. Once you had bought the domain and could respond to the devices‘ API calls, weren’t you in the drivi
by schubart 4y ago
I didn’t quite understand the need for an injection attack. Once you had bought the domain and could respond to the devices‘ API calls, weren’t you in the driving seat already?
- tyingq 4y agoA guess, but... "At boot time, the Config Server will pull the latest configuration from an HTTP server. In addition, the Config Server will connect to an AWS IoT Core endpoint to receive real time config updates from an MQTT server." So, perhaps to bootstrap information they didn't have, like the current configuration? It sounds like they sold different types of signs with different resolutions, and also whatever train station setup config there was. Maybe a one-time exploit to upload that info from the sign itself.
- ColdHeat 4y agoYes the exploit removes the AWS IoT connection so that updates can come from the recreated API. There was only one type of sign but it did come in various different cases.
- karmanyaahm 4y agoThe author couldn't have accessed the original AWS account, which is what managed configuration updates.
- ColdHeat 4y agoI actually had written more about the exploit & vulnerability in my original drafts but I cut it out because it was a bit boring to read. You are correct that with domain control I am able to serve content to any sign but the content will only be loaded once at boot time. Any future updates would have needed to come from their defunct AWS IoT connection (ignoring full restarts). Using the exploit I remove the connection to AWS IoT and update some of the code to better connect it to the recreated API so users can update their signs in mostly real time.
- wferrell 4y agoWould you mind posting that content somewhere? I would find it very interesting!