Categories
Security

Insecurity Questions

One frequent back door installed by the web site operators themselves, is the security question.
What was your first pet?
What was your mother’s maiden name?
Where were you born?
What was your first school?
These are very often what stands between an attacker and your account. Other info is used in more “serious” contexts, such as applying for a passport, or banking, but these are given out to many agencies, and crucially, never change over your lifetime. Who would countenance a single, life-long, and simplistic, password?
Give your friends a quick quiz, and find out how much of this they know already. How much of it do you know about them? Chances are, few if any know your National Insurance number off the top of their head, but they might know where you keep your household files. How many documents could they photo whilst you are in the bathroom?
You can’t choose your own NI or Social Security number, but you can choose to give fake information in response to security questions. Of course, they’re there as a backup form of access when you’ve forgotten your password, so how can you get better security without risking being permanently locked out?
No, I’m asking.

Categories
Security

Product recall subterfuge

Here’s one that’s so simple it must be happening already.
Spam targets with emails containing an alarming, but plausible product recall notice. Receive their details, or even their product, in return.
I received an email a few days ago from a manufacturer of computing devices, and it came from a domain I didn’t recognise, making me immediately suspicious- turned out to be genuine, but it made me think of this.

Improvements

This’ll only work if people have that device, but you may be able to sharpen your spear by frequenting owner forums (especially check out .sigs where users may inform/boast of owning a particular model), or hacking product website data. Use their name or purchase date if you can.
Don’t go overboard with the fear angle, but make it something where their worry of going out-of-warranty can be used against them. Have it be a potential issue (“23% of affected models emit smoke” after 6 months). Provide a pre-paid label to download, or even offer to pick it up via courier, minimising.
Obviously, tech devices like phones and laptops are best, anything with data on, or otherwise compromisable- a smoke alarm could be fitted with a listening device.
The recall I received was for a laptop battery, which in modern laptops are usually well sealed up, and there’s certainly likely to be some where the electrical interface contains some data lines, which may be exploitable, or merely, again, somewhere we could hide a bugging device. What’s more, the option I chose was a self-install kit, really minimising our exposure to the target, and making them less likely to reject it (who wants to be without their laptop for long?).

Defence

Mainly, go to manufacturer’s site and check for product recall there, contact support.

Categories
Security

Metametadata for steganography

So.
You’d like to slip some data past some prying eyes. For whatever reason, overtly encrypting the data isn’t possible. It’s not just that the data can’t be seen, but you can’t have anyone be aware data is even moving anywhere.
It’s not unheard of to use metadata for smuggling data. That way, the ostensible file- a Word document, a JPEG file looks innocent- it can even be opened up and read -but if you know where to look, there’s the secret data.
What’s data, in contrast to metadata? That’s a matter of intention. It’s the surface purpose of the file format.
 
But not all metadata is created equal.
The data itself can be crafted or written to convey a second meaning. For example, subtext in fiction, or taking a photo of 6 sunflowers.
You can use patterns- spaces or number of syllables in text, or colours of pixels in images.
You can encode the data in such a way that it includes extra meaning- using homoglyphs, or diacritic combining characters.
But we’re talking about metadata, I thought?
All metadata has a purpose, and is going to affect the way the file is read or displayed. Different applications may expose that metadata more visibly than others. So we have to be careful not to store our payload in what turns out to be plain sight. An example being the document title, which is often going to be displayed in the application title bar. So it might look a little suspicious in the document about cakes says “The X-94 Prototype uses Jumbillium alloy”.
One option can be to find formats where we can define our own metadata, or look for the equivalent of junk DNA.
What’s junk DNA?
Noncoding DNA or Junk DNA is DNA that doesn’t do anything (sidenote- much of it probably does do things after all). It just bulks out the genome to no effect (again, probably not true). But it sits right in there with the other DNA. Where most DNA shows the body how to make a protein, ncDNA does not.
Many file formats will have an end-of-file token, and ignore anything after that. They may have a payload length in the header, and again, everything after that is ignored.
Error correction codes have been misused in the past on audio CDs, but we could use the ECC bits to store our data- quite a percentage of the audio CD is that.
But what about metametadata?
Metametadata is metadata about metadata. It’s casting metadata as the main role, then thinking about what we can say about it.

  • GPS co-ordinates (which would be the metadata) of a location which can be looked up on a map, with a name, say, London, encoding for the letter L, or number 6. Or 50, I suppose.
  • Or GPS co-ordinates where the least significant digits carry the hidden data.
  • In databases, using wide, non-sequential ID columns to encode our data. The GUID type in Microsoft Access and SQL Server is 16 bytes wide! Feed our data through a 128 bit block cipher, and we’ll have pretty random-looking data, so given unique input plaintext, we are going to get unique cyphertext out. Prepending a sequence number to our text might be needed if we know we’ll be wanting to send repeating messages, but that eats into our budget. We can expose the GUIDs in some interface, perhaps in what would look like debug messages/comments in some HTML front end.
  • TTL fields in IP headers. Now. These won’t survive end-to-end unaltered. But, over time, we can establish a baseline number of hops, interleaved with TTLs to carry our covert meaning. Sure, it’s not a lot of data, but with the right application, we can send a lot of packets in any session, or spread out over time- perhaps looking at other data leaving that network node or time of day to ensure it doesn’t look out of place. With the baseline TTL known (have to recheck periodically in case of path changes), we can monitor these transmissions from any node in the path.
  • If we’re playing around at the packet level, we can also bury stuff in the sequence number of TCP headers, although this is going to require more co-operation at the other end, a network stack that can ignore sequence numbers on a certain port, perhaps, and simply funnels the sequence numbers to a decoding utility.
  • Both of the above techniques could also be employed as a network “knock”, the idea of refusing connections to a port until a certain series of events happens, like a secret knock.
  • Many file formats have a lot, or total flexibility with regards to the ordering of the metadata, so we can use that to encode data.

Problems with embedding data in metadata is that if it gets too big, the filesize is going to look incongruous with the overt data. It would be worth looking at a sample of JPEGs, etc, to determine the average, and have a think about what heuristics might be engaged to detect meta (or metameta) data payloads. We might scrub the EXIF clean of a JPEG, or at least flag it up as likely to be suspect, not just size, but use of unusual, or rarely used EXIF tags.

Categories
Security

Classified Classifieds (steganography for command & control)

Ars Technica just ran a story about a Russian hacking group making botnets, and how they control them covertly.
There’s two parts to a successful botnet- you need the zombie (infected) hosts not to be detected too quickly, as they’ll then be cured. But you also need to be able to communicate with the bots in such a way that they don’t betray their own presence, and don’t leave a trail back to what is known as the C&C (Command & Control).
That middle bit is still very tricky, since by definition, you want to have an effect- perhaps a DDOS on a target, spamming, or distribution of more malware. If a DDOS, by definition, that’s going to be very noticeable by all concerned. But going from that to alerting the owner of the specific computer (or perhaps router, or printer) is slow. ISPs aren’t known for rapid action.
Even when you do get a message to the zombie’s owner, that’s one machine.
To really knock out the botnet, you need to get at the C&C. So where is it?
Sometimes, the code of the malware will give it away. It was that that allowed the recent Wannacry attack to be mitigated.
In this case, there was no URL, but there was a co-infection with a browser extension, which gathered the URL (via bit.ly shortened URL) by scanning comments matching certain features on an Instagram post. The article doesn’t make it clear if visits to that particular post were forced, non-browser requests but I have to assume so.
I liked how this reminded my of the old-fashioned (but still in use, no doubt) posting of a coded, surface-innocent message in the newspaper classifieds. No-one looks suspicious for purchasing a copy of a newspaper.
Using bit.ly made that initial URL less suspicious, and using a URL shortening service makes sense, to keep the hidden data requirement low. Downside was that it was possible to view the statistics on visits to, ultimately, the C&C.
If you aren’t too fussy about who you infect, you can simply use comment systems (or, riskier, adverts) with this kind of steganography, on very popular websites. It might not guarantee that you get a specific visitor, unless you know about their browsing habits, but it’ll get you plenty. That way, you needed force the browser to visit anywhere. Anytime you can let the target do all the work for you, you’re minimising the subterfuge you have to engage in as an attacker, and the fewer fingerprints/smoking guns you’re leaving on their system.
Could that data be, not a direct URL, but instead, something like a BitTorrent magnet link, pointing at a distributed, decentralised C&C system using a DHT? How about a tor .onion address? There are JavaScript tor client implementations after all…