InformAction Forums

1. Noscript just updated to V. 2.9.0.4, so I assume V. 2.9.0.3 was active yesterday when I had this trouble.

2. Some malware is launching a window who's address bar starts "data:text/htlm;base64," followed by obfuscated code to launch the payload.

• Getting the address bar contents, as I was busy closing the window, was not possible. Session manager has it in its history, but I can't copy and paste. I suppose I could do a screen capture and look for some sort of OCR... But the problem here isn't the payload itself as much as the method of delivery.

3. I don't know exactly how the window was launched, and if XSS can see it. I also don't know how to add site "data:text/html" to a black list as I drive Noscript via its menus. I'm not even sure it's considered a site, and therefore being monitored. (adblockplus can't stop it.)

4. I'm 99% sure this malware requires running a script in order to launch the attack. If it's wort it, I could set up a sandbox and see if I can watch what is coming from the poisoned site, though I would expect the malicious script is associated part of the site, which implies that being safe means "just don't go there".

Still, I didn't know the site was poison until after I visited. Would sure be nice to generically stop a future attack that uses the same method should I visit a different poisoned site.

Can I expect Noscript to stop this sort of attack?

How would I configure it?

Thanks!

NoScript cannot be expected to protect against a malware infection, it only has the privileges of your browser and is designed only to stop threats from the Internet.
nvm, I misunderstood what you're saying please disregard this post

see General Troubleshooting Instructions #2 for some suggestions for removing malware

Can you please post the URL of the poisoned site (in code tags please, so that it's not a live link)?
What domains, if any, did you Allow in NoScript on the poisoned site? (Do you have Allow Scripts Globally or Temporarily allow top-level sites by default enabled?)

How or why would ["inline"] "data:text/htlm;base64" be any different from any other type of URI?

So if something is being "launched" (a window opened) it is (should be) no different from any other window being opened, & should be treated appropriately based upon settings in NoScript.

No?


(Unless there is an error in NoScript coding.)

I really hate this... frown

Got the sandbox setup and went to the tumbler page with the problem. Could not reproduce.

Inspecting the source page showed only imported scripts from tumblr com and googleapis com. The embedded ones did some iframes, but again only referencing tumblr.

1. Perhaps tumblr discovered something in the user's page and cleaned it up.

2. Perhaps the newest version of NoScript caught an XSS or referral, but I didn't see a message bar.

3. ???

I also did some malware scanning and they didn't find anything other than a couple of PUPs I already knew about. My system itself seems normal, no adds popping up, no unexpected windows. It would not surprise me to find that even though the payload executed, it wasn't allowed to do anything damaging.

If the site were script-blocked then NoScript would not load the data: URI at all.
If the site were script-allowed then the data: URI would have run its scripts.

(Confirmed this by tested clicking on link to data: URI.)

Here's a harmless base64-encoded text/html data: URI (containing script) to play with

Are you typing that into the Location bar or do you have that as part of the code of a web page (html)?

What I did for testing was use Firebug to alter the href of an existing link in some webpage to point to that data: URI.

Tried a cut and paste and got this nice message box:
https://drive.google.com/file/d/0B0tbUZ ... sp=sharing
which says NoScript caught a data: URI, and developers could set an option...

This is what I expected two days ago, but didn't get. I'm hoping the Tumblr page (malicious URI) got cleaned up, and someone hasn't found a way around NoScript checking. If it happens again, I'll immediately look for the source before it can disappear.

As far as the page itself, as I reported earlier, there was no URI on the page itself. I did not follow to the inner scripts on the assumption that Tumblr and Google analytics/tags were clean.

PS: To answer the other question, I never run with "'Allow All", which defeats the purpose of Noscript.

That message only occurs if data: URI is typed or pasted in the address bar.
Since you didn't Allow any scripts on whatever site this was, it's expected that the data: URI was silently blocked.

I've spent more time researching, and I believe the community is in the midst of a plague of data URIs containing malware payloads.

Support for data URIs took off in 2015, and they are growing more and more popular as delivery vectors.

This means Noscript needs to start checking them.

<script src=... tags are an obvious target for Noscript.

data:text/html;base64,PCFkb22N0eXB... should also be an obvious target, when one decodes the first few characters and sees <!doctype html><script>

So my question:

• Should Noscript decode and scan all this embedded content?
  
  Or would just suppressing some varieties of data URIs be sufficient?

@JMThomas Remember to log in so that you can use your chosen username and don't need to solve the CAPTCHA each time. (I've fixed your latest post here.)

You are expressing concern over malicious usage of data: URIs but still not providing us with concrete evidence that NoScript's current protection is insufficient. As such, it looks like baseless paranoia, and your question cannot be answered.
Please provide a URL or testcase (by PM if needed per viewtopic.php?f=7&t=20215).

JMThomas wrote:Still, I didn't know the site was poison until after I visited.

But you had whitelisted the site, right?

By doing that, you've told NoScript that you trust the site. There are many ways for sites to abuse that trust, so you should only tell NoScript to trust sites that you actually have reason to trust.

Thrawn wrote:

JMThomas wrote:Still, I didn't know the site was poison until after I visited.

But you had whitelisted the site, right?

By doing that, you've told NoScript that you trust the site. There are many ways for sites to abuse that trust, so you should only tell NoScript to trust sites that you actually have reason to trust.

Sorry, the wasn't white listed. The bullet didn't leave the revolver, nor was the revolver aimed at my extremity.