Teach a man to phish and he’s set for life | Hacker News Reader

Teach a man to phish and he’s set for life

krebsonsecurity.com

163 pointstodsacerdoti89 comments

I love Unicode quirks that OSes and big software developers miss, it's so fun to send links with cyrillic 'а' instead of latin 'a', sometimes https:// links are protected from this, but mailto: aren't (so if the mail client doesn't report the wierd character, you can make someone send an email to the wrong hostname), and the RLO chars are so fun, name a file ann<RLO>fdp.exe, and it shows under most software as annexe.pdf, but gets executed as an exe in Windows.

Also watch what happens in GNOME desktop environement and its file explorer, like right click on it and view properties, the RLO switch extends to the whole sentence that the filename is written in, it's hilarious.

It's supposed to print "<filename> Properties", but instead the window title is "<beginning of filename>seitreporP <end of filename>".

> I love Unicode quirks that OSes and big software developers miss

It's more the development and specs of Unicode that did miss a lot of things. When Unicode came out Bruce Schneier envisioned all the attacks that'd inevitably come and he was, of course, totally right.

As he put it a quarter of century ago (2000): "Unicode is just too complex to ever be secure".

It's Unicode that did fuck up, not developers who are forced to deal with non-sensical things because somewhere a committee decided that it'd make sense to use a broken system for domain names (for example).

Isn't almost all the complexity of Unicode inherent in the problem of trying to encode documents written in every written language, though? (Esp. when including documents written in multiple languages at once — and often switching languages within a single sentence, such as when a statement in one language quotes text in another language.)

Or do you have thoughts on what a "simplified Unicode" — that accomplishes all the same goals — would look like?

Problem is that the executability of files is (at least on Windows) communicated in-band in the filename. In-band signalling was proven to be a bad idea ever since the early days of phone phreaking.

Unicode is fine for what it is - conveying text across languages and scripts. The problem is that some environments use the filename as more than what it should be (a memo field for the user and not an instruction for the machine whether to execute the file as code).

> Isn't almost all the complexity of Unicode inherent in the problem of trying to encode documents written in every written language, though? (Esp. when including documents written in multiple languages at once — and often switching languages within a single sentence, such as when a statement in one language quotes text in another language.)

What's complex about that? That's just an ordinary sequence of code points, no different than if there was only one language involved.

Unicode has problems where the same thing is represented several different ways. It's not a problem for different things to be represented in different ways.

> Unicode has problems where the same thing is represented several different ways.

That's needed for compatibility with legacy encodings.

Canonically-equivalent codepoints, yes, exist for embeddings of legacy encodings into Unicode.

But when most people — including the GGP poster — complain about this, they aren't usually thinking of canonically-equivalent codepoints, but rather of homoglyphs: codepoints that just happen to have the same conventional pictorial representation. But which have different (collation/splitting/etc) properties; or, more interestingly, different (machine-readable!) semantics.

Most often, phishing "text confusion" is done using homoglyphs. (And, in fact, in some text-processing libraries — e.g. Punycode — "text confusion" can only happen using homoglyphs, as canonically-equivalent Unicode codepoints get normalized to just one option.)

The reason that the homoglyphic Latin "M" and Cyrillic "М" codepoints exist in Unicode isn't for legacy reasons. It's rather because Cyrillic "M" sorts after Cyrillic "Р" (and both of them come before Cyrillic "С"!) You can't have alternate collation orderings if you're using the same codepoints for both languages.

The reason that both Greek "π" and mathematical "𝜋" exist in Unicode, is because one codepoint "is" a letter, and the other codepoint "is" a symbol. This "is"-ness has nothing to do with the glyphs, but rather is basically a type system inside Unicode, that user-agents besides those that render text often rely upon. "𝜋" (the symbol) can carry a particular semantic meaning in text to machine user-agents, that "π" (the letter) does not. Translation systems should treat them differently. Dictionaries should treat them differently. Filter rules for usernames should treat them differently. Etc. (And that's beside the fact that they also have different Unicode properties. "π", as a letter, doesn't create implicit split-boundaries on either side of it; while "𝜋", as a symbol, does.)

Good points.

I hadn't known that point about sort order. Wait, so suppose a language that uses the same alphabet as English used a reversed alphabet ordering. Would unicode include z-a somewhere else to support that language?

Probably, yeah. If it's got a fundamentally-different collation, then it's not the same script as the Latin alphabet per se.

However, due to how annoying it is to deal with languages with the same glyphs but a different order ("I don't know where to find things in this translation dictionary!"), languages that share a set of glyphs have tended — ever since democratized access to printing, and dictionaries to create "canonical" orderings — to gravitate toward a shared ordering for the common-denominator subsets of their alphabets.

German, for example, has an alphabet that's like the Latin alphabet but with some "extra" letters — but, however they did it way back when, the German alphabet today "embeds" the Latin alphabet in Latin order at the beginning, and then puts all the extra letters at the end. So German doesn't need another set of Unicode code-points for A-Z; it just needs codepoints for those extra letters.

>So German doesn't need another set of Unicode code-points for A-Z; it just needs codepoints for those extra letters.

The extra letters would sort differently though right? I wouldn't expect ö/ä/ü to sort after z. For ß I guess it's not a concern since it never appears at the start of words.

No, they would add new collation rules to the Common Locale Data Repository, similar to the ones that define that Y sorts between I and J in Lithuanian: https://www.unicode.org/cldr/charts/42/collation/lt.html

No, that's not a relevant concern. In the same way, Unicode sees no problem with assigning LATIN CAPITAL LETTER I (U+0049) and LATIN SMALL LETTER I (U+0069) to the glyphs of the Turkish alphabet that have those appearances, despite the fact that in Turkish they are two different letters. (And therefore capitalization has to be done by an algorithm that is aware of what language you want to do capitalization in.)

By contrast, GREEK CAPITAL LETTER A is U+0391, separate from LATIN CAPITAL LETTER A. There is no principled reason for this.

Now I'm curious about how many mathematicians have published papers using the wrong pi code point. Do journal editors check for that sort of thing?

Mathematicians usually write papers in LaTeX, which predates Unicode and doesn’t rely on it. You then just type \pi in a math context and get the right symbol. (Though here are modern LaTeX implementations that support Unicode input as well.)

Why do OSs like Linux distributions accept all characters in filenames except null and `/`? This causes problems even with ASCII (space, linefeed), and it's not like you need control characters like ACK in your filename.

Applying policies to restrict which `byte[]` values are valid index keys is not the "one thing" that a filesystem is supposed to do well.

You're saying this as if it's self-evident. Why not?

Because your filesystem is a storage layer. Its concern is storage, not display. It shouldn’t concern itself with how bytes are interpreted by your terminal, GUI, whatever. Those will also differ based on the particular program doing the interpreting.

> As he put it a quarter of century ago (2000): "Unicode is just too complex to ever be secure".

> It's Unicode that did fuck up, not developers who are forced to deal with non-sensical things because somewhere a committee decided that it'd make sense to use a broken system for domain names (for example).

I'm not sure that's unicode's fault. Their goal is to produce a standard for encoding ~all written text. It may seem like this would be something cool to support in your program of choice, but in lots of applications that flexibility leads to vulnerabilities. I think developers need to be aware of these risks and design around them (for example by limiting the allowed characters in certain contexts).

And even if you restrict yourself to the venerable US-ASCII you might have to check for metacharacters to avoid XSS.

What should Unicode have done instead?

This replacement is called a homoglyph or homograph attack and was huge a few years ago: https://en.m.wikipedia.org/wiki/IDN_homograph_attack

Meanwhile the US government is finally starting to realise the weaknesses in cybersecurity that are direct consequences of Microsoft business decisions in their products

> Oregon senator Ron Wyden wants the U.S. government to hold Microsoft responsible for what he describes as “negligent cybersecurity practices” that enabled “a successful Chinese espionage campaign against the United States government.”

https://www.securityweek.com/us-senator-wyden-accuses-micros...

> Like attaching a phishing email to a traditional, clean email message

Several people at my org had their email hacked and now I regularly receive my own years-old emails to them sent back to me with phishing links.

>One would think Microsoft would have had plenty of time by now to address this.”

Anyone that’s had the pleasure of using office 365 knows microsoft has other priorities.

I’m not even sure this was fixed yet: https://forum.level1techs.com/t/am-i-the-crazy-one-here-or-i...

The proper solution to this problem is to render the message as the user will see it and then analyze it using computer vision, running OCR to extract the text and identifying deceptive elements like brands. We built a prototype to detect brand impersonations at scale in this manner and it worked, but the GPU cost was prohibitive (on a billion messages a month) and there were lots of false positives.

If anyone is keen to learn more, reach out to me at ksimpson at mailchannels.com. We would like to open source this but don’t have the time to do it properly. If anyone is interested, please reach out to me.

or you could also render the extension separately allowing only ascii chars... (thus .eml would always show at the end, no matter what)

Might be cool to do this on domains found on certifacte transparency logs, rather than doing it on domains found on e-mail. Lets encrypt seems to issue about 3M certificates a day, so about 100 million a month. Which seems to be one order of magnitude better.

If I were a phisher I wouldn't put the phishing on the site home page.

Ah I have a friend at Google doing that. Except they downscale the image to a ridiculously low resolution to save compute costs. At that resolution OCR is no longer feasible but brand detection still works. Naturally being at Google they don't use GPUs but TPUs to do it, but the cost remains so prohibitive that they have to randomly sample messages to go through this process.

Not surprised that downscaling still works. Brands work very hard to make their messages visually distinctive, such that you’d recognize the brand even if you squint…

Krebs appears to misspell the filename here; it is not "pdf.eml Properties" but "fdp.eml" and "Properties" is the title of the Windows dialog.

It's true: Ever since I became a Phish fan back in '96 I've been set for life! :)

just surrender to the flow ;)

I, too, was unaware of phishing with RLO characters. Video about it here: https://www.youtube.com/watch?v=nIcRK4V_Zvc

Give a man a fish and he'll eat for a day

Teach a Nigerian to phish and he'll become a Prince!

Is Unicode turing complete now? Does anyone think it's a good idea?

Unicode still doesn't do loops, so no, but it's sightly less complex that human written language is, so it's very complex for sure.

Human language for sure was a awesome idea. We're finding out with Generative Large Language Multi-Modal Models that languages are a interesting building block for what we can call intelligence.

Do you want to go back to codepages and needing to know the difference between CP1252 and ISO 8859-1?

I'm pretty sure there is a more sane solution in between. Too bad the commitees went wild instead.

Just like with ipv4 and ipv6.

No, but filenames should never have supported anything other than plain ASCII. Not only filenames but anything that has semantic meaning or is otherwise relevant to the functioning of the system.

Unicode should have been confined strictly to document content and UI presentation.

So Germans shouldn't be allowed to use "ä" in their file names?

Like the hive mind is trying to make logging in ultracomplicated for security reasons, why not dissalow confusing characters in file names for security reasons?

Oh but it would make file names less complex. We can't have that.

Edit: btw, how many ways can you express an "ă" in Unicode? How many different file names that look the same visually can you end up with?

It's only English people who find "ä" confusing. The provincialism in this thread...

You don't know about the many ways to represent an Unicode character and the 4 normal forms then. Easy to wonder why I say it's enterprise complex in that case, but it is.

No true german would ever have a hard time discerning between ä and ă. That would be like mixing up p and b for an anglophone.

:) I'm not german. My language doesn't use ä but it uses ă. Thanks for noticing. My point still stands.

Yes, and Asian languages would have to use transliterations. So what? Security over convenience.

Unicode is a great idea and the way it was before sucked ass.

I find it a little bit dubious that this social engineering evasion is what caused the false negative in phish detection.

This guy expects the automated scanner to render the filename graphically, OCR it, then use the backwards result to guess the file type?

Because first of all, "foo.eml" and "[RLO]bar.eml" are both EML files to any programmatic scanner, and second they look at the content of the file to figure out what it is, not the extension.

No, this guy expects the automated scanner to detect that bidi overrides are being abused, and block it based on that.

That's the kind of heuristic rule that's going to come back and bite you when you try to scale up to half a billion attachments a day.

I think it's pretty good. No sane human uses those in casual text. Trying to carve out exceptions could become a complex biting situation, but flat-out blocking/replacing them shouldn't.

I am always dubious of Krebs since the whole Ubiquiti debacle. I acknowledge that he apologised (in a fashion), but the fact that he doubled down when he must have known that his source was the perpetrator leaves a bad taste. As someone in the security field, I treat everything he reports with a healthy amount of scepticism, double-checking any sources he provides.

I remember some original reports about ubiquiti but not the specifics, is lodged in the back of my mind as "this company is getting worse"

I never saw the apology, but even if I had the damage would still be there, the subconcious part of my mind has downgraded ubiquiti

On the flip side maybe ubiquiti deserved to be downgraded - I remember talk about new owners and new directions, and perhaps I never even saw the security claim, and this retraction will unfairly "un-downgrade" them.

It's the same problem as the tabloid press. They can spend 3 weeks hounding someone with lies on page 1, then print a retraction on page 14. Even if the retraction was on page 1 it wouldn't undo the damage.

Trust is an extremely fragile thing (he says in a pseudo-intellectual sat-on-the-sofa on-a-rainy-day kind of philosophical whimsy...)

Yeah, this bothers me a lot. I've been an Ubiquiti customer for a long time, and when this happened I was extremely nervous for a good while. I even missed the pseudo-apology, but saw the news stories about the perp later.

OK, in the entirety of my computer usage, I never have had a need to render of unicode in all of its oddities. I would love to have a setting that just turns off all of Unicode permanently. If something arrives with unicode I'd rather it didn't render than to have all this user-hostile behavior appear. I think this one setting would significantly reduce the risk surface area of computers I use.

It’s going to be great the first time an European sends you a message and nothing displays because your system can’t render the diacritic in their name.

I am European and my name and surnames would not render. Most English speakers can't even pronounce my name correctly, which bugs me slightly more than the name not rendering correctly in a computer.

But I still don't see this as a problem. Allowing arbitrary encodings, arbitrary mix in an single text stream of right-to-left and left-to-right rendering, homonyms and visually identical rendering of different byte sequences are all a problem, and in particular when any of these are being used across a web or OS interface, where recognizing the intent is quite important.

I agree there is an issue. I don’t agree about what the issue is.

The problem is not Unicode rendering. The problem is improperly mingling information of a different nature. File extensions are not a good way to tell you if a file will be executed (Unix got that right from the start). Then executing a file involuntary shouldn’t lead to significant risks for your data and your system. That’s the actual problem which needs to be solved. Mangling text rendering is not the solution.

It would be easy enough for web browsers and email programs to not output files with executable extensions. They make things executable for user convenience, and if the average user was on unix they'd probably do something similarly insecure there too.

Yeah boo foreigners!

> I would love to have a setting that just turns off all of Unicode permanently.

That'd be way too extreme but it would have been totally possible to have a filesystem configurable so that it'd enforce ASCII only filenames and ASCII only domain names.

FWIW I enforce ASCII only domain names on my system (I prevent resolving any domain name that has Unicode chars) and live is fine and well. And I'd have zero issue with ASCII-only filenames.

And localization/internationalization (l10n/i18n) can go where it should: inside resource files etc.

I'd argue most computer users, if considering the whole world, would like to use their native language for their file names.

In some cases, you can get close enough by just cutting away random symbols. Think é -> e. Sure, you may lose some nuance, but it's close enough. I wonder how well this works for languages which don't use a latin-based script, and how approachable the conversion is for a "regular person".

German speakers would for sure riot if they couldn't use umlauts in file names. This discussion is so incredibly US-centric.

> Sure, you may lose some nuance, but it's close enough.

Not always. For instance, "coco" means coconut, while "cocô" (notice the circumflex, which corresponds to a change on which syllabe has the stress) means fecal matter. That's not just "some nuance".

I think you mean cocó (Portuguese/Brazilian for shit, mostly used by little kids; adults use a different word)

I love it when people are incensed on my behalf on things I actually don't care about.

> I think you mean cocó (Portuguese/Brazilian for shit, mostly used by little kids; adults use a different word)

No, the word does have a circumflex, not an acute accent, and it's also used by adults (mostly in the expression "fazer cocô", which means to defecate). But, of course, that might be something regional to where I live (a large metropolitan area on the southeast region of Brazil).

This is such an odd comment. You can't just "turn off" Unicode (because you can't turn off a standard).

You could refuse to render any file encoded in UTF8, UTF16 etc. but that would be silly because by now, most files you're going to encounter (especially as a developer) use one of these encodings.

Or you could refuse to render anything outside of the ASCII range but then you're just assuming that the English-speaking world is all there is and that people of other language communities don't also have needs (such as having their name displayed properly). That's a pretty myopic view of the world IMHO.

yeah but I dont't speak their language and I don't interact with them.

I never installed fonts for asian characters on my pc and it hasn't affected me whatsoever. My terminal (which is what I use to manage files) also doesn't support right to left text and it has __never__ been an issue.

> yeah but I dont't speak their language and I don't interact with them.

Pretty sure you're interacting with lots of people on this website who aren't English native speakers.

> I never installed fonts for asian characters on my pc and it hasn't affected me whatsoever. My terminal (which is what I use to manage files) also doesn't support right to left text and it has __never__ been an issue.

That's not "turning off Unicode", that's just not installing fonts that deal with certain character ranges. Pretty sure whatever font you're using does support more than just bare ASCII, though.

We're all speaking English on this website though? Look I take both of your points, but this seems like a weak argument.

People in this very thread have used non-ASCII characters? If people are going to mention local issues like the name of a certain politician (or even something like mathematics, with its special characters), non-ASCII characters are going to pop up. It's really not that hard to find non-ASCII comments on this website. Should such comments just not be rendered or what's your suggestion?

For reference, my actual name and original languages cannot be spelled without some Unicode. And I am still the OP that said I'd prefer to turn Unicode off, or at very least have very tight leash on what it is allowed to do

The reasoning is that my primary computer use is in a single language. I very very rarely need to have my computer understand and present to me multiple different languages, and never languages that follow different rules. Anytime such a thing occurs:

a) it is not a language I understand, so not rendering it is fine & safe

b) someone is playing games with Unicode to try to trick me. Definitely not rendering is fine and rendering is actually dangerous

c) the most rare case: the other language is relevant. The only times this has happened (talking to my family and whatnot), it is local to a specific app and I only want that app to deal with the other languages.

The problem is that in the interest of satisfying every language group, my computers assume I care about all languages. I don't, I only speak/read 4 languages and everything else is no use being presented to me. If I'm an outlier, I'm an outlier for being fluent in more than a single language.

For most all users, having the system limited to presenting a single language would significantly reduce the attack surface.

So how should that work? Every person who uses a computer has to manually configure what kinds of characters they want rendered?

You've never had to render a name like Daniële? Never used non-breaking space on website for better text layout? Never read text that used any — em-dashes —? No currencies other than the dollar ever mentioned, and to cap it all off, never seen an emoji?

I agree that unicode is ugly and stupid. But despite all that it persists, because it is the least stupid of all encodings. It's not like the ASCII characters of: Form Feed (0C), Device Control 1 through 4 (11 through 14), group separator (1D), and most other non-printable ASCII characters are a reasonable use of byte-space, or are useful to attempt to render to the screen.

And that is before you get into hijinks that can be played with backspace and del characters if they are rendered naively. (Though I love backspace for progress bars in the terminal)

I think their main complaint is complex rendering, not merely having lots of characters.

If you just go into simple mode, ë, em-dash, symbols and emoji would be fine.

Did you know that most emoji are implemented in Unicode?

Tell a man to phish, and you can sell him phishing poles.

Tangential: The email mentioned "These messages will be deleted in _24hours_" (emphasis mine, no space) - phishing mails _still_ have typos?! I find it hilarious for right and wrong reasons.

It's a feature, not a bug

It could be that "24 hours" raises an higher score in spam filters

What's the point of this attack? If you're using a .EML to display a link to a phishing page, surely a .PDF works just as well?

The .EML file opens in the Outlook email viewer, presumably? A PDF would open in either the native PDF viewer, or some sort of Outlook PDF previewer - but either way, would be more obviously third-party content than an email in the email client.

In theory you could argue that Outlook may be the only vulnerable client, but then you could just say "I forwarded you this e-mail" and have the same result

when MSFT is called to DC over losing master keys to all emails after proven extended exfiltration of same, make sure to blast-promote a stern warning over imitating the mighty and venerable MSFT by common criminals to the commoners..

DC is just mad that MSFT let the US Government's key to the backdoor get copied by someone else. "Hey, that's our backdoor!"

:^)

Reply on news.ycombinator.com