[HN Gopher] Teach a man to phish and he's set for life
___________________________________________________________________
Teach a man to phish and he's set for life
Author : todsacerdoti
Score : 146 points
Date : 2023-08-04 13:51 UTC (9 hours ago)
(HTM) web link (krebsonsecurity.com)
(TXT) w3m dump (krebsonsecurity.com)
| wiz21c wrote:
| Tell a man to phish, and you can sell him phishing poles.
| jgeada wrote:
| 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.
| rocqua wrote:
| You've never had to render a name like Daniele? 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)
| skrebbel wrote:
| Yeah boo foreigners!
| zirgs wrote:
| Did you know that most emoji are implemented in Unicode?
| TacticalCoder wrote:
| > 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.
| vladvasiliu wrote:
| 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 -> 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".
| Tainnor wrote:
| German speakers would for sure riot if they couldn't use
| umlauts in file names. This discussion is so incredibly US-
| centric.
| cesarb wrote:
| > Sure, you may lose some nuance, but it's close enough.
|
| Not always. For instance, "coco" means coconut, while
| "coco" (notice the circumflex, which corresponds to a
| change on which syllabe has the stress) means fecal matter.
| That's not just "some nuance".
| jgeada wrote:
| I think you mean coco (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.
| Tainnor wrote:
| 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.
| jgeada wrote:
| 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.
| ShowalkKama wrote:
| 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.
| Tainnor wrote:
| > 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.
| DiggyJohnson wrote:
| We're all speaking English on this website though? Look I
| take both of your points, but this seems like a weak
| argument.
| brmgb wrote:
| 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.
| jgeada wrote:
| 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.
| brmgb wrote:
| I think you are missing the forest for the tree. 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.
| [deleted]
| sbuk wrote:
| 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.
| ta1243 wrote:
| 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.
| e40 wrote:
| 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.
| mistrial9 wrote:
| 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..
| anonym29 wrote:
| 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! "
|
| :^)
| chayesfss wrote:
| [dead]
| thedanbob wrote:
| > 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.
| u801e wrote:
| Give a man a fish and he'll eat for a day
|
| Teach a Nigerian to phish and he'll become a Prince!
| Modified3019 wrote:
| >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...
| nottorp wrote:
| Is Unicode turing complete now? Does anyone think it's a good
| idea?
| meepmorp wrote:
| Unicode is a great idea and the way it was before sucked ass.
| ElectricalUnion wrote:
| 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.
| tadfisher wrote:
| Do you want to go back to codepages and needing to know the
| difference between CP1252 and ISO 8859-1?
| mike_hock wrote:
| 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.
| nradov wrote:
| So Germans shouldn't be allowed to use "a" in their file
| names?
| nottorp wrote:
| 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 "a" in
| Unicode? How many different file names that look the same
| visually can you end up with?
| nottorp wrote:
| 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.
| euazOn wrote:
| I, too, was unaware of phishing with RLO characters. Video about
| it here: https://www.youtube.com/watch?v=nIcRK4V_Zvc
| miohtama wrote:
| 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...
| 13of40 wrote:
| 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.
| dave4420 wrote:
| No, this guy expects the automated scanner to detect that bidi
| overrides are being abused, and block it based on that.
| 13of40 wrote:
| 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.
| rpigab wrote:
| I love Unicode quirks that OSes and big software developers miss,
| it's so fun to send links with cyrillic 'a' 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>".
| TacticalCoder wrote:
| > 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).
| BeFlatXIII wrote:
| What should Unicode have done instead?
| derefr wrote:
| 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?
| Nextgrid wrote:
| 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).
| thaumasiotes wrote:
| > 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.
| avgcorrection wrote:
| > Unicode has problems where the same thing is
| represented several different ways.
|
| That's needed for compatibility with legacy encodings.
| derefr wrote:
| 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
| "M" codepoints exist in Unicode _isn 't_ for legacy
| reasons. It's rather because Cyrillic "M" sorts _after_
| Cyrillic "R" (and both of them come before Cyrillic
| "S"!) You can't have alternate collation orderings if
| you're using the same codepoints for both languages.
|
| The reason that both Greek "p" 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 "p" (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. "p", as a letter, doesn't create
| implicit split-boundaries on either side of it; while "",
| as a symbol, does.)
| farnsworth wrote:
| 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?
| derefr wrote:
| 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.
| carlmr wrote:
| >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 o/a/u to sort after z. For ss I guess
| it's not a concern since it never appears at the start of
| words.
| thaumasiotes wrote:
| 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.
| yorwba wrote:
| 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
| nradov wrote:
| 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?
| drbaba wrote:
| 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.)
| avgcorrection wrote:
| Good points.
| avgcorrection wrote:
| 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.
| tbrownaw wrote:
| Applying policies to restrict which `byte[]` values are
| valid index keys is not the "one thing" that a filesystem
| is supposed to do well.
| carlmr wrote:
| You're saying this as if it's self-evident. Why not?
| remus wrote:
| > 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).
| avgcorrection wrote:
| And even if you restrict yourself to the venerable US-ASCII
| you might have to check for metacharacters to avoid XSS.
| 6D794163636F756 wrote:
| 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
| ttul wrote:
| 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.
| rocqua wrote:
| 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.
| masfuerte wrote:
| If I were a phisher I wouldn't put the phishing on the site
| home page.
| kccqzy wrote:
| 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.
| [deleted]
| ShowalkKama wrote:
| or you could also render the extension separately allowing only
| ascii chars... (thus .eml would always show at the end, no
| matter what)
| greatquux wrote:
| It's true: Ever since I became a Phish fan back in '96 I've been
| set for life! :)
| soupfordummies wrote:
| just surrender to the flow ;)
| [deleted]
| CraftedByPeter wrote:
| [dead]
| NoZebra120vClip wrote:
| 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.
| r1ch wrote:
| 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?
| ivanbakel wrote:
| 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.
| rvnx wrote:
| 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
| user_7832 wrote:
| 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.
| ncann wrote:
| It's a feature, not a bug
| rvnx wrote:
| It could be that "24 hours" raises an higher score in spam
| filters
___________________________________________________________________
(page generated 2023-08-04 23:01 UTC)