Ggthjy

Editors, and common libraries used by editors, may have vulnerabilities like buffer overflows. Your attacker would need to know (or guess) what editor you use and craft an exploit specifically for that editor (different editors are unlikely to have the same vulnerabilities unless the vulnerability resides in a library they have in common). An attack may be aimed at a popular editor and send out to as many people as possible, essentially turning it into a "spray-n-pray" attack.

Attack Surface

A very simple editor like Microsoft's Notepad has a smaller attack surface than a more advanced editor (like Visual Studio Code). More code generally means more potential vulnerabilities.

Mitigations

Certain mitigation techniques like Address Space Layout Randomization (ASLR), Data Execution Prevention and having an anti-virus with an "exploit blocker" (these are generally capable of recognizing basic overflow attacks, among others) may help to render certain attacks useless.

Software Updates

All of these techniques are of course no substitute to keeping your software (ALL your software I might add) up-to-date. Keeping your software updated is the best security strategy one can have. This is sometimes overlooked or trivialized due to its lack of feedback. An anti-virus yelling at you that "You are protected!" sends out a much stronger signal than a software update that silently patches vulnerabilities in the background. I tend to compare an anti-virus program with a person sticking their fingers in the holes of a dike to prevent the water coming through. It does its best to keep the flood out but chances are it's not going to have enough fingers to fill all the holes (or miss a few altogether). Software patches fixes those holes.

Bottom Line

You can never be sure you aren't going to have a bad day by opening any type of file in any type of program. However, some programs (like editors) are much harder to attack due to their small footprint or secure design and therefore are less likely to be targeted for mass attacks (especially because an attacker is likely to assume their evil .html file is going to be opened in a browser, not in an editor).

Oh, these answers are way too sophisticated for your situation. It's highly unlikely that your IT department would be using some fancy workaround assuming they know what editor you're using, their point is not to actually mess up your systems. Notepad isn't going to be doing anything with any image or attachment, no matter what, and the text you saw certainly didn't do anything reprehensible to your system. Nor would it have been likely to, even if it had been a real attack, as editors are very personal tools and there are lots and lots of them that'd have to be covered for anything like this to have any sort of detectable effect.

Tell your coworkers to get off your back, and to be more careful themselves. Let me just point out that you dug yourself into this hole though, and achieved the opposite of what was intended…. If you hadn't announced that you looked and what you saw, people who clearly don't know a thing about IT security wouldn't be harassing you and feeling superior about it. Instead, some of them would have opened the attachment and seen the message, and gotten a bit chastened themselves. So you've messed up IT's test all the way down the line, emphasizing the Dunning-Kruger effect which is no doubt the cause of sending out these tests. Stop it!

Okay, so, technically, you're never 100% safe. Yes, there could be attempted attacks on your text editor/ASCII viewer. Yes, someone could have somehow magically snuck a DLL into your temporary directory in order to mess with MS Notepad delay loading.

But in practice, when you receive an HTML file in a phishing email, it's going to contain some malicious JavaScript or more likely redirect you to a website online that tries to persuade you to hand over your credit card details / logins.

So, in practice, examining such a file in Notepad++ is a perfectly reasonable way to see what's been sent to you. The reaction of your colleagues seems unfair, unless you are working in a nuclear silo … and if your job is really that mission/safety critical, why are there emails at all? Why would there be internet access? And, if there isn't, why would you need phishing audits/tests/honeypots? Someone somewhere is being overly paranoid.

We can try to reduce our risk to zero but the only way to achieve that is to not use a computer.

All that being said, though, you will always have to deal with silly people so perhaps keep this activity to yourself next time. ;)

In general it's not safe because if you get a suspicious or unexpected email, whatever the attachment is, it shouldn't be opened. That's the safest thing to do. Especially if you are on Windows, which is notorious for executing stuff when it should not, and which is the most targeted OS by attackers, running the most targeted applications.

But if you want to open it anyway, maybe because you are an INFOSEC enthusiast or you think you are (or want to be) smarter than the average user, here's some advice:

• Consider reading the source code of the email, instead of opening it. You might be able to do so directly from the webmail interface, or by reading the text files on your server, etc.


• Consider downloading the attachment from the source, by copying and pasting its base64 representation. This will just be simple ASCII text. You can then convert it back to binary with some tools.


• Consider renaming the file, saving it as potentially-malicious.txt instead of .html or whatever name and extension it has.


• Consider opening the txt file with very basic text editors, or even hex-editors, or even with very simple basic tools available on the command line that will only display ASCII characters. An example could be cat file.txt | less on Linux. (Note: why cat before less? Because I noticed that less parses and converts some stuff by default sometimes, like converting PDFs to TXTs. So just be careful, better check what the commands do by default on your system anyway).


• Consider opening the file in virtual machine, which should be up-to-date and also disconnected from the network.


• Consider doing most of this at home and never tell your boss or your colleagues about it. They might see it as dangerous behavior, a violation of the security policy, or something that might cause you trouble anyway.

Its situations like this, where risk for particular objects is an unknown quantity, that a strongly compartmentalized OS like Qubes excels. Qubes uses a hardened bare-metal hypervisor to keep risky stuff isolated from sensitive areas (like personal files and the core OS). It even isolates risky devices. This isolation is expressed and controlled through the GUI in a fairly user-friendly fashion:

In the above example, right-clicking on an html file in KDE Dolphin lets you choose options like "Edit In DisposableVM" and "View In DisposableVM". Clicking on either one of these will automatically instantiate a disposable virtual machine (dispvm), then send the file to the dispvm and load it in the associated app. This takes only seconds. When you're done with the editing app, the edited version will be returned to the calling VM and the dispvm will be instantly destroyed. Note, however, this process by itself does not make an untrusted file into a trusted file.

For certain file types (currently images and pdfs) there is also a menu option for converting a file to a trusted state... i.e. a dispvm is used to process an untrusted pdf and construct a sanitized version that is loaded back and can be used without risk to your regular VMs where you normally work. This is possible because the originating sanitizing tool accepts only the most predictable representation of the requested data back from the dispvm, such as uncompressed bitmaps of exactly an expected number of pixels and bytes; once the raw sanitized version is received back, it is then re-compressed into the expected format.

Its worth noting that you could emulate the type of security described above using more familiar tools like VirtualBox and VMware, but the degree and quality of the isolation is unlikely to match the levels attained by a dedicated system like Qubes.

While others are pointing out flaws, I would say you did the right thing.

While your other colleagues took the route of assuming its bad, you used your skill set to analyse the situation and verify its malicious intent.

You had an understanding that you should not allow the browser to open the file, but instead use something that it was not intended for it be opened with by the recipient. You analysed the code, and you were able to verify that it had malicious intent ( in this case, only a warning by your IT team ).

If you are skilfull enough to analyse the files and make the correct judgement call, I would find that more ensuring that you have a good understanding of protecting yourself against malicious users and using your skillset to ensure your safety.

How ever if you do not have the skill to verify the HTML and JavaScript code is not malicious, you should just not open it and assume it is malicious as you can not guarantee its safety even if you opened it in notepad.

Only attempt to analyse a situation in which you have the appropriate skill set to analyse, and only analyse the situation if you expecting the email or it is from a known source.

Yes, breaches could occur upon downloading the file and then opening it in Notepad / other basic widely-used text editor, because payloads can be specifically crafted to interact upon such editors as Notepad.

Example: Notepad.exe, like many of the Windows programs, uses system libraries. One of those system libraries loads shdocvw.dll (Internet Explorer related component). shdocvw.dll has a delay-load dependency on a library called 'ieshims.dll'.

This .dll could be searched in the current directory and loaded from there. So if an attacker would deploy it along with the .txt file, it could use this setup as an exploit to load its .dll and then go from there.

The solution to this: use your own text editor/viewer that is not dependent on any Windows components / libraries. Mine is just called Edit.ExE, 100% independent of any external resources and 100% safe regarding processed content (reads everything directly as ASCII / text with no content detection). You don't have one; use a very obscure one no one would bother to exploit.

If you're a paranoid nuclear scientist working in a secret base in Antarctica, maybe. Otherwise, nobody is going to spend the time to implement buffer overflows, etc.

The first thing that comes to most people's minds when they see an HTML file is probably to open it with a browser. If they wanted to "trick" you into editing it with Notepad++ or similar, it would likely be a text file, JSON file, etc.

So no, you probably aren't at risk, but yes, you could be.