Tag Archives: security

Can a .txt file contain malware?

Posted on February 5, 2018 | Comments Off on Can a .txt file contain malware?

The Internet Crime Complaint Center reported that some email messages are impersonating it in an attempt to get malware onto target computers. That’s clearly worth knowing about, but this part of the report is odd:

The unknown actors also attached a text document (.txt) to download, complete, and return to the perpetrators. The text file contained malware which was designed to further victimize the recipient.

It really shouldn’t be possible to run malware by opening a .txt file. It should just open in a text editor, with no execution of code. There’s no further explanation.
Continue reading →

Comments Off on Can a .txt file contain malware?

Posted in commentary

Tagged

More on SVG risks

Posted on December 2, 2016 | Comments Off on More on SVG risks

SVG is a risky format in more ways than I’d realized. I’d previously mentioned the risk of cross-site scripting with embedded JavaScript, but I’ve found it gets worse.

The article “Crouching Tiger – Hidden Payload: Security Risks of Scalable Vector Graphics” covers the hazards in detail. There are two problems: (1) HTML5 requires SVG support in multiple contexts, and (2) SVG can have embedded JavaScript and CSS.

SVG is XML, and embedding it in HTML means switching between two different parsing modes. The author, Thorsten Holz at Ruhr-University Bochum, states that “SVG files must be considered fully functional, one-file web applications potentially containing HTML, JavaScript, Flash, and other interactive code structures.” I still haven’t digested all the content, but it describes lots of ways SVG could be exploited.

Websites that allow third-party posting should disallow or filter SVG content. WordPress disallows SVG uploads by default.

SVG is a designed-in danger in HTML5.

Comments Off on More on SVG risks

Posted in commentary

Tagged , ,

JavaScript risk in SVG images

Posted on November 21, 2016 | Comments Off on JavaScript risk in SVG images

Malicious SVG images sent over Facebook Messenger are being used to deliver Locky ransomware.

An SVG file can contain a <script> tag, which contains executable JavaScript as CDATA. If it’s an image on a Web page, the JavaScript can run in the browser. This is a potential XSS weakness, if users can submit images to a site.
Continue reading →

Comments Off on JavaScript risk in SVG images

Posted in commentary

Tagged , ,

Don’t hide those file extensions!

Posted on June 22, 2016 | Comments Off on Don’t hide those file extensions!

Lately I’ve ghostwritten several pieces on Internet security and how to protect yourself against malicious files. One point comes up over and over: Don’t hide file extensions! If you get a file called Evilware.pdf.exe, then Microsoft thinks you should see it as Evilware.pdf. The default setting on Windows conceals file extensions from you; you have to change a setting to view files by their actual names.

What’s this supposed to accomplish, besides making you think executable files are just documents? I keep seeing vague statements that this somehow “simplifies” things for users. If they see a file called “Document.pdf,” Microsoft’s marketing department thinks people will say, “What’s that .pdf at the end of the name? This is too bewildering and technical for me! I give up on this computer!”

They also seem to think that when people run a .exe file, not knowing it is one because the extension is hidden, and it turns out to be ransomware that encrypts all the files on the computer, that’s a reasonable price to pay for making file names look simpler. It’s always marketing departments that are to blame for this kind of stupidity; I’m sure the engineers know better.
Continue reading →

Comments Off on Don’t hide those file extensions!

Posted in commentary

Tagged , ,

Security risk in “target=_blank”

Posted on March 18, 2016 | Comments Off on Security risk in “target=_blank”

I’ve often used “target=_blank” in my posts so that people can click on a link without leaving the original page. So do many people. This turns out to be a seriously risky practice, though. When you open a window with an anchor tag specifying “target=_blank”, you give the target window control of the original window’s location object! This means that the target window can modify the content of the original window, possibly redirecting it to a phishing page.

We could also call this a security hole in the HTML DOM, or perhaps in the whole idea of allowing JavaScript in Web pages. I use NoScript with Firefox so that unfamiliar pages won’t run JavaScript, preventing them from exploiting this hole. I can’t expect everybody reading this blog to do that, though. To protect against exploits, I’d need to add “rel=noopener” for some browsers and “rel=”noreferrer” for others. That would require custom JavaScript, which wordpress.com won’t let me do, and would be a lot of work just to modify link behavior. Starting with this post, I’m not using “target=_blank” in my links. The sites I’ve linked to in the past are reputable, as far as I know, so the risk from existing links should be minimal. At least I hope so; supposedly trustworthy websites allow advertisers to include unvetted JavaScript, allowing malware attacks.

Comments Off on Security risk in “target=_blank”

Posted in News

Tagged ,

Unicode security mechanisms

Posted on January 14, 2016 | Comments Off on Unicode security mechanisms

Unicode is a great thing, but sometimes its thoroughness poses problems. Different character sets often include characters that look exactly like common ASCII characters in most fonts, and these can be used to spoof domain names. Sometimes this is called a homograph attack or script spoofing. For instance, someone might register the domain gοοgle.com, which looks a lot like “google.com,” but actually uses the Greek letter omicron instead of the Roman letter o. (Search this page in your browser for “google” if you don’t believe me.) Such tricks could lure unwary users into a phishing site. A real-life example, which didn’t even require more than ASCII, was a site called paypaI.com — that’s a capital I instead of a lower-case L, and they look the same in some fonts. That was way back in 2000.
Continue reading →

Comments Off on Unicode security mechanisms

Posted in commentary

Tagged ,

The misuses of HTML frames

Posted on November 21, 2014 | 1 comment

HTML framesets have some good uses, such as including third-party content. They also have misuses, such as disguising third-party involvement.

Recently I needed to set up domain forwarding for a subdomain registered with Godaddy. (The choice of registrar wasn’t my fault.) A couple of options were available, including one that claimed to guarantee that the subdomain would persist through navigation in the address bar. That sounded like a good thing, so I picked it.

At first it seemed to work fine; but when I tried to use the URL of an image on the site, there were weird errors. I soon found out what was going on: Godaddy was wrapping every page referenced by the subdomain in a frameset! This looks like a duck and clicks like a duck, but it isn’t one, and anything that tries to treat HTML as a JPEG file isn’t going to work very well.

Stack Overflow has several reports of people being bitten by this:

Frame wrapping is a good-enough solution for some cases, but when you aren’t told it’s happening, that’s a seriously wrong way to do it. It’s also a security concern, since your domain points at an IP address that you don’t control, and only indirectly at your own site.

This is a blog on file formats, not on irresponsible domain registrars, so the moral here is to realize that framesets aren’t a completely transparent way to provide third-party content. It’s fine to use them, but only if you’re aware that the frameset host and the frame provider are active partners.

1 Comment

Posted in commentary

Tagged ,

HTML5 security

Posted on February 25, 2011 | Comments Off on HTML5 security

Yesterday, February 24, Ming Chow gave a talk to the ABCD security group at Harvard on HTML5 security. As far as I can tell he hasn’t made any of the content publicly available online, but here are some high points:

  • HTML5 has a lot of new features, giving it a bigger “attack surface.”
  • There’s no effective security to local and session storage, so writing sensitive information there is a bad idea.
  • The database feature raises all the standard concerns about injection of malicious SQL code into fields.
  • Application caches can be written by any website. It may be possible to spoof pages this way.
  • There is now a function, XDomainRequest, in JavaScript, which allows communication between different sites. The receiver of the request must specify Access-Control-Allow-Origin to indicate whose requests are allowed. Wild-carding this allows anyone at all to send data to a page, which may be dangerous. Implementers of a receiver should always verify the sender’s identity.
  • With the audio, video, and canvas tags, the codecs can be vulnerable. Opera has been hit with a heap buffer overflow exploit in HTML5.
  • The noscript tag is no longer supported. Users who try to make themselves safer by disabling Javascript are more screwed than ever.
  • The problems are new, but the approach to safety is the same: common sense, input validation, being careful with unsecured connections, etc.

Comments Off on HTML5 security

Posted in News

Tagged , ,

SourceForge security incident and doppelgänger characters

Posted on January 29, 2011 | Comments Off on SourceForge security incident and doppelgänger characters

This morning I got an email from SourceForge saying that all passwords had been reset because of a password sniffing incident. Naturally, I’m suspicious of all email of this kind, but I do have a SourceForge account. So rather than follow any of the links in the mail, I tried to log in normally and found that passwords were in fact reset. I followed the procedure for resetting by email and my account’s working again.

I’m sure some of you reading this also have SourceForge accounts, so this bit of reassurance may be helpful, especially if your phishing filters (philters?) kept you from seeing the notice in the first place. It’s likely some fakers will set up scams to take advantage of this issue, so always go to the SourceForge website by typing in the URL or using a bookmark, rather than by following a link from email. It’s easy to mistake a near-lookalike URL on a quick glance.

Worse yet (yes, this post has something to do with formats), there are now exact lookalike URL’s, thanks to the unfortunate policy of allowing Unicode in URL’s. There are numerous cases where characters in non-English character sets normally look just like letters of the Roman alphabet. Someone could, in principle, register sourceforgе.net, which looks just like sourceforge.net — but do a local text search for “sourceforge” in your browser, and you’ll notice the first “sourceforgе.net” (and this one) are skipped over. The sixth letter isn’t the ASCII letter “e” but the Russian letter “e,” which usually looks the same or very nearly.

If your browser doesn’t have a Cyrillic font, you may be seeing a placeholder glyph instead. Or if it views the page in Latin-1 instead of UTF-8, you may see a Capital D followed by a Greek lower-case mu.

With any email that offers to correct a password issue, exercise extreme caution, even though some are legitimate.

Comments Off on SourceForge security incident and doppelgänger characters

Posted in commentary, News

Tagged ,

PDF exploit

Posted on April 6, 2010 | Comments Off on PDF exploit

A number of web sites are talking about a vulnerability in PDF. So far I haven’t found an exact description; anyone who explained it in detail would get the blame for everyone who uses it for malicious purposes. But the idea seems simple enough that anyone with the necessary technical knowledge (including me) could work it out given a little time. Apparently it’s a means by which the user can be presented with a legitimate-looking dialog and tricked into approving the launching of arbitrary executable code. The exploit can be added to an existing PDF without changing its appearance. JavaScript isn’t required. The vulnerability is in the format specification, not in a software bug. This is the really nasty kind of vulnerability that designers have nightmares about.

Here’s an article on CNET on the issue. There seems to be substantive discussion of the root of the problem here. I’ve got to get to work now. I’ll post something more later.


 
Update: OK, it’s not so bad as it sounded. Here’s the real account, which doesn’t say exactly how to do it, but gives enough clues that it’s not too hard to figure out the rest.

As you might have guessed if you know PDF, it uses the PDF Launch Action. The PDF specification actually doesn’t mandate any safety features in the Launch Action; if you implemented a PDF reader that automatically launched anything a PDF document told you to, you’d be within the spec. But Adobe Reader, exercising normal common sense, prompts the user for permission to launch. The trick is just that the text which describes the application to be launched can be modified. The user still gets a stern warning not to launch anything untrusted.

This trick will doubtless catch some people, as even simpler tricks do (just saying “don’t worry, it’s safe” in the document itself will trick a rather large number of fools). But it isn’t really anything to get hugely worried about.

Comments Off on PDF exploit

Posted in News

Tagged ,