[tw5] I Think I Hacked TiddlyWiki

Google Group (Read Only)
#7

Mark,

The scenario I had in mind was: Person A (attacker), adds malicious code to his TW instance, which is accessible via the web through GitHub pages, or something similar. He then shares his wiki link with Person B, who unknowingly goes to take a look at Person A’s wiki. On doing this, Person B then has this malicious JS execute on his end, thereby hacking/infecting him.

With JS, this exploit could be crafted in a variety of ways, as stated, there is already pure-JS ransomware, which, combined with some creativity, could trick the user into allowing the wiki to access the local filesystem. There is also ways of installing damaging malware to the users system (see Drive-by download - Wikipedia), purely from vulnerabilities like this.

So this exploit can reach beyond the scope of there being someone who “can sit down at your desk and insert code.”

#8

I’m still confused about this scenario. If we’re not talking about inserting the code into someone else’s wiki via XSS or something, how does TiddlyWiki allow anything here that an arbitrary website wouldn’t? If a malicious user can post a page on the web and make the target go to it, then surely anything that a browser allows is fair game, and if there’s fault here it should lie with the web browser, not TiddlyWiki. Because even if TW changed to disallow this, surely the malicious user could just revert that change in their own fork of TiddlyWiki and build their malicious wiki on that TW edition?

I’d be more concerned about people being tricked into importing a tiddler that contained code like this.

#9

I’d be more concerned about people being tricked into importing a tiddler that contained code like this.

#10

In my test, the code didn’t do anything. So it’s hard to evaluate. What exactly could the code do? Unless it could write to the file system (which is really hard in JS), or if it could send the keystrokes back to a server-based entity, it would not be able to accomplish anything. What browser are you testing with?

I think the WP article is talking about abilities that existed before modern browsers. Modern browsers, as we have found out to our chagrin, tell you that they are doing a download. They can only download to one place, which is usually the download directory. They know nothing about the file system, and can’t even tell you the path of an image that has been loaded (also to our chagrin). Once a file is downloaded, it can only be executed by a deliberate action. On Linux, most file managers won’t execute from the GUI anymore, so no accidental clicking. On Windows, Windows pops up a message warning you that you are about to run a potentially dangerous file. So it’s not easy to get your code executed even if it is downloaded.

If a person deliberately puts code on their page that does malicious things, it doesn’t matter how it is inserted.

So basically, you’re just saying that TW uses Javascript and somebody could insert additional JS. But that is a weakness/strength of all AJAX pages. It’s not like I could go to an existing TW site and add my own malicious code. It would have to be running a special server based version of TW (node, Bob, ) to make that possible – not the standalone.

In terms of self-protection, the best away to avoid malicious code would be to only use code/plugins that are WikiText based (after reviewing that it doesn’t create JS tiddlers), or only using plugins from sources that you really, really trust (e.g. Eric S.)

#11

That was one of the concerns with TWederation. You could import from someone you trusted who imported from someone they trusted who … actually couldn’t be trusted. It’s kind of a hard problem.

#12

Mark S. wrote:

… Modern browsers, as we have found out to our chagrin, tell you that they are doing a download. They can only download to one place, which is usually the download directory. They know nothing about the file system, and can’t even tell you the path of an image that has been loaded (also to our chagrin). Once a file is downloaded, it can only be executed by a deliberate action. On Linux, most file managers won’t execute from the GUI anymore, so no accidental clicking. On Windows, Windows pops up a message warning you that you are about to run a potentially dangerous file. So it’s not easy to get your code executed even if it is downloaded.

Ciao Mark. I enjoyed this for both it’s accuracy and it’s acknowledgment of ongoing CHAGRIN.

As it happens I am still on Timimi previous to latest on Firefox (i.e. the Saver & LAUNCHER) that lets you launch apps directly (with a bit la-di-dah) from TiddlyWiki.

So, if that is insecurity, I’d like more of it.

I think it insane to force web pages to be stupid when they can be really clever.
TW, in particular, is really great when you also can control the computer from it.

Regarding the OP. The tech part of it is above my tech level, but I can’t see any real issue that differs from the normal caveats about switching on a computer.

Best wishes
TT

#13

Mark S. wrote:

That was one of the concerns with TWederation. You could import from someone you trusted who imported from someone they trusted who … actually couldn’t be trusted. It’s kind of a hard problem.

Right! It IS an interesting issue. But maybe as much an anthropological issue as a technical one.
Suddenly tech switches into “HOW CAN I TRUST?” mode.
Despite the fact most everyone, well everyone, here (you, reading this) is completely trust-worthy.
I think its a basic sociological fact that much of the internet is NOW premised on the idea you can’t trust anyone.
It has led to a kind of “authentication gymnastics” that makes doing some things very convoluted.

Just rambles
TT

#14

I am currently playing with “real-time multiplayer” capabilities for TW5, so this is an interesting security vulnerability to be aware of.

My primary concern was “what if a malicious user connected a MIS-IDENTIFIED wiki to a real-time server. It has a bunch of malicious tiddlers, and it DOES NOT have a bunch of tiddlers that exist in the server copy.”

The real-time sync, once authenticated and authorized, would just absoloutely wreck the server-copy of the wiki in this instance.

Similarly, being able to some-how sync malicious javascript code, hidden in a data-uri to the server, which will sync it to all connected users is a concern…

Best,
Joshua Fontany

#15

TW wasn’t built from the ground-up for mult-user, and it’s definitely not how most people are using it. I’m sure products built as server-side entities (e.g. WikiMedia) have all sorts of protection against injected code.

Anyone who can write and save a tiddler can make a javascript tiddler, or a widget, or overwrite a javascript filte operator, or maybe header scripts, or maybe in-frame code. I guess you would have to think of all the ways that code could be injected and then neutralize everything that matched. But you’d have to do it before the tiddlers got written to the common pool, and you’d have to either block legitimate uses of the iframe, or figure out some way to detect that the frame doesn’t contain js source code.

#16

Mark et al

You said TW wasn’t built from the ground-up for mult-user, and it’s definitely not how most people are using it. I’m sure products built as server-side entities (e.g. WikiMedia) have all sorts of protection against injected code.

I agree, yet we have Bob which makes this plausible at least where people who access the wiki are trusted such as in a team. Perhaps not secure on the internet where anyone can get to it.

  • I think this may be a self fulfilling prophesy, we don’t have secure methods to share online or run in a multi-user mode, so no one does.
  • Because we don’t have multi-user solutions on the internet people come to expect all the control they want on their own local wikis, I don’t want the security tail wagging the dog, if I want to iframe sites I use, or use it to drag and drop patches between wikis, I would not like this being locked down.
  • Despite me calling for this mulit-user functionality, see Check in and out critical to the use of tiddlywiki #5919 with the simplest form serial editing using a check out and in facility I can’t seem to get any traction on this.
    Given the discussion in this thread, perhaps we need a way to harden tiddlywiki for the internet, but I hope we don’t harden it for the sole or LAN users or teams. It seems we may need to “bifurcate” to the risky and less risky environments, another possibility is being able to run a vulnerability check on a wiki.

The best security will give us our cake and we can eat it too, the wrong security will mean we can’t eat the cake, or look at it in the security of our own room.

In closing of great importance are the many possible ways tiddlywiki can be made use of, but we need to maintain flexibility even when attempting to secure it the the “great unwashed internet”, because it often has little or nothing to do with the internet.

Regards
Tones

#17

Well, what I see is this:

If you use TW, you use JavaScript. And if you use JavaScript code from unknown / unsafe sources, you will run the risk of the code doing things that it shouldn’t be doing. That should actually be clear to everyone. But that’s not a problem for TW, but in principle for every website that takes full advantage of the possibilities of HTML5. And at last, it’s the problem of all data: You have to trust in it.

A particular security problem of TW is, of course, that TW has all the tools to integrate new (dangerous) code in the simplest possible way, without the user always being aware of what he is doing. The special thing about it is not only that it is so easy to do. It is also particularly difficult to understand and keep track of, because the file is constantly being changed and saved.

Of course, you can take the trouble to review the code you are adopting and also ensure that no one else can insert their own code. But honestly, who does it? We usually trust what we find - at least on the sites we know. And what we are inserting is not always obvious. The example code above, for example. In plain language it reads:

Which of you deciphered it before trying it out?

#18

Excellent points John. Most users will indeed not review the full text of every single tiddler they import. I’m now thinking that pointing out which ones should indeed be reviewed more explicitly would be both easy and worthwhile.

At the tm-import-tiddlers widget level, any JS that’s being imported could be flagged, with a simple highlight inviting the user to review the code before confirming the import when standard declared JS is detected, and a more insistent alert when the code is hidden or obfuscated (as in Finn’s Base64 example). A simple exhaustive filter search should be able to cover all or most cases, including content-type=application/javascript, , ,

I feel (at my very modest level of understanding) that this would add a significant extra layer of security when drag-and-dropping as users could react when seeing JavaScript being imported where none was expected — when simply importing a random content tiddler for instance.

Given that new JS is only executable after rebooting the TW instance, even if the potentially malicious code is executed while parsing the imports, it shouldn’t prove too much of an issue as the user with sudden doubts could immediately delete the imports and avoid any potential issues and would be invited to then share any concern with the TW community to understand if anything is wrong and nip the problem in the bud.

Best,
R²

#19

I never got the alert. I’m curious why some people are reporting that it worked. Also, “alert” is very public and generally pretty harmless. Possibly it could be used as part of a phishing scheme. It’s not clear to me that you could create code that could modify anything outside the iframe sandbox. The suggestion was made that it could download something. Is there a demo for that?

#20

Really, it gets back to trust and reputation.

A TW coder could write a tiddler that contains no javascript tiddlers, but that, when run, creates a javascript tiddler that will later get run. So you would never see javascript code during import. The core TW is already pretty huge. Adding patch after patch for each imagined scenario eventually renders TW less and less useful.

Also, it hasn’t been demonstrated what harm could be done even if your standalone code was infiltrated. Could keystrokes be sent back to a server? Could file blocks be written anywhere other than the download directory? Of course on node or especially on any multi-user platform things become more hazardous. In theory any server-based solution (e.g. node) could write to your file system and possibly invoke code. In practice, I found it very difficult to set up even when I wanted something like that.

#21

I agree that there are a lot of possible open “attack vectors”, and keeping track of every one is not feasable.

Good conversation so far. I think the primarily concern is that TW will run obfuscated javascript without a refresh required. That should have an option to “Sandbox” that behaviour somehow, and let superusers unlock it.

Thanks for the discussion!

Best,
Joshua Fontany

#22

Thanks all for considering this;

I think the best way to limit risks is to provide plugins in trusted libraries, from trusted sources. then people could also install these in an empty html and run a vulnerability test using a plugin designed to highlight risks. As soon as a library contains something doggy the community can react.

To facilitate this I would like an easy way to collect and publish a library from a single file wiki, then the well known and trusted people can publish libraries that they themself can check or anyone in the community. Libraries contain plugins frozen in a moment of time, Only libraries so tested would be listed publicly. With all other sources the designer can run a (latest) vulnerability test published on tiddlywiki.com and if we must we can blacklist or whitelist plugins or “signatures” in this vulnerability tester.

In another discussion I am also calling for a hash tool which although not invulnerable would add another layer of testing, mostly to see which system tiddlers have being modified, and this would just make cheating more difficult.

The power we have on our side is the community and the ability to collect and centralise data in a way that “outsiders” have more work to do before they can compromise anyone to a large extent, ie make it harder and cause diminishing returns. We can also ensure we have trusted sources and be able to test them. In this light we may even benefit from people hacking, because we can identify the vectors and respond.

But finally I want to reinforce in many wiki editions or personal on my desktop/mobile only, I do not want features crippled, diminished or destroyed for when the wiki may be placed on an internet facing editable platform. This is why I think the vulnerability test tool has the greatest value. Horses for courses.

Regards
Tones

2 Likes
#23

Just to make sure I’m understanding correctly: That particular attack wouldn’t yield much fruit, would it? The attacker would have an encrypted version of TiddlyWiki only xe could access, but the original user would still have the version xe opened on xir local hard drive or the Web site xe loaded the page from in the first place. All that would be encrypted for ransom would be the session-specific instance of that file, not the source file (which the browser can’t encrypt and save over on the fly).

Or am I misunderstanding?

#24

@Scott,

With a bit of creativity, practically anything is possible! You’re right in that the JS could not have DIRECT access to the user’s file system, but as explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/, one could simply use JS to connect to a server to install a malicious exe, which it could then run.
Essentially, the JS could easily apply a cipher to the file to thus “encrypt it”, and use the exe to rewrite the file content with this encrypted text.
The exe could also handle deletion of backups, or pretty much anything else needed.

#25

Super-interesting stuff! Thanks for the background.

There’s a bit of consolation in there, though: It sounds like the RAA attack relies on getting the user to execute JS in the WSH rather than within the browser. TiddlyWiki on Node or running through Bob.exe or in TiddlyDesktop might be a more vulnerable vector of infection than a TiddlyWiki running the latest version of a Chromium-based browser. I’m not sure how those platforms compare to browsers when it comes to sandboxing the environment where scripts are executed.

The novel path of attack (sharing a .JS via tiddler with another TiddlyWiki user) is certainly worth considering as a potential vulnerability — but, as Tony said above, the balance between usability and security is often more nuanced than just locking down everything to prevent any possibility of infection.

This could be a great opportunity for some security-minded TiddlyWizards to come up with a script-vetting plugin to throw up red flags during the import of outside content. Maybe there’d even be a way to leverage malware databases via API to keep it up to date on current threats. That’s all way above my head, though, and maybe be as great a can of worms as trying to lock down TiddlyWiki to protect it from rogue JS.

#26

With a bit of creativity, practically anything is possible! You’re right in that the JS could not have DIRECT access to the user’s file system, but as explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/, one could simply use JS to connect to a server to install a malicious exe, which it could then run.
Essentially, the JS could easily apply a cipher to the file to thus “encrypt it”, and use the exe to rewrite the file content with this encrypted text.
The exe could also handle deletion of backups, or pretty much anything else needed.

Hmm that article is about tricking users into double-clicking on .JS files so that they run under the Windows Scripting Host, and doesn’t really cover the situation of TiddlyWiki.

Best wishes

Jeremy