I’m not especially fond of the words ‘Cyber’ or ‘Symposium’, even worse when they’re joined together. As I write this Mike Lindell is holding his CyberSymposium where he’s allegedly releasing packet captures that prove that ‘the election was stolen’. So you know where I stand: there’s yet to be a shred of evidence that even slightly indicates this. However, I was rather more interested in this supposed proof by way of a packet capture.
Firstly, he’s reportedly had this data for some time – thats interesting as if I had something I thought was this big – I’d be dropping it on Github for the world the pour over. That hasn’t happened and there’s a few problems with – well, just about everything to do with these pcaps.
When there is a computer security incident, it’s important to collect the data in a manner that ensures integrity. If we’re collecting remotely we need to be absolutely sure its come from the correct host and that our collecting machine is completely secure. How I go about this is important and I’ll need to write it all down. My documentation is absolutely key. Once I have my pcap file (or other data) I’ll need to run a sha256sum against it to get its hash, and this too will be added to my notes. This ensures that if anyone tampers with the file(s), we’d know.
We need to ensure chain of custody with any important evidence. If there’s a chance we’d need the data in the future we’ll need to commit this to WORM (Write Once Read Many-times) media. A CD or DVD will usually be acceptable media if written to correctly (i.e. the disc is closed to prevent alterations). The media then needs to be placed in a tamper-evident bag with the seals of this being noted and added to the documentation I’m keeping.
Only if I’ve conducted these steps properly is the data contained within acceptable in a court of law. Anything less than this – your evidence is worthless. My notes have to be perfect so that an expert in the field agrees they’re the right steps and reproducible. This is problem #1 for Lindell.
Here’s the second problem – and it occurs because of first one. It’s irrelevant what is contained in the pcaps because it’s so easy to forge a child could do it. Here’s an example.
I collected a few packets of me sending a ping to Google’s DNS server. This is the output in Wireshark:
You can see my virtual machine listed with the IP 192.168.229.21 sending the echo request to 8.8.8.8. What if I wanted people to think it was someone else sending those packets? Surely nobody can change a network capture, can they? Of course they can. And trivially so. Enter bbe. The command below will replace the bytes for my real IP address for one I’ve made up…
\x means that the number I’m sending is hexadecimal, the c0 that follows it is the first octet of the IP address. You can see thats followed by \xa8\xe5\x15 which is the rest of the IP making up the last 3 octets. What follows the forward-slash is my replacement. You don’t even need to know hex to understand what the replacement is. And here is what we get:
As you can see all instances of my IP have been obliterated and replaced with something else. Apparently someone with an IP of 1.1.1.1 sent the ping. Obviously we’re not limited to changing IP addresses. The limit is your imagination… and we could make this pcap say whatever we wanted!
So just because someone says they have a capture that is ‘proof’ of something, I think it’s wise to know where the data came from, how it was collected, and who’s had access to access to it from time zero.
Given the delays in handing over data that has claims surrounding it verging on the supernatural, it’s all beginning to look much more like a children’s magic show than anything grounded in reality.