It's most likely a virus: I got it from a local chicken shop website, asking me to update Firefox as it was apparently out of date. Which it wasn't, but okay. I clicked the thing because why not, and it downloaded a .JS file.
The file itself is seemingly a pile of gibberish, here's the first line:
(function(wyfdysu){var iwtquom="arwob"["c"+("H","q","n","o")+["U","n","H","H"][(-
So yeah, aside from a VM, is there any way I can safely inspect this?
Typically malicious websites use so-called Drive-by Downloads to get you to download their exploits onto your system. From there on they often use remote code execution to read and write data from your PC. This may be the case with you.
Inspecting the file
As it only downloaded a .JS file, you can safely inspect it with a text editor on your current system. You can also try to find an exploit that used the same technique on Exploit-DB or searching the code in question on Google. Best bet though would be to hexdump it on a VM and try to reverse engineer your way to see what it does if you can't find any more information on the code.
Take aways
Never grant a malicious website access to files and privileges that they could exploit
Never allow a malicious website to download a file for you.
Related
I was wondering if it would be possible to create a JavaScript function to check a condition, and if that is True then I deny access to the code? Right now I am checking the user agent, and if it doesn't meet given criteria then I delete the HTML tag. However, if they go to the network tab then they can still see the GET requests and responses for my code.
This is a website running on localhost because it's an Electron app by the way.
I thought maybe I could issue a 403 error but I'm not sure if that's possible via JS.
Thanks
In an Electron app, your code is still JavaScript source code. You can obfuscate it and/or put it in a ASAR archive to make it harder to read and fine, but the code is still there and accessible to anyone who wants to go to the effort. (For instance, if you use VS Code, you can see the source in resources/app/out directory and its subdirectories.)
You can make it even harder to find and understand the source if you're willing to put in more work. V8, the JavaScript engine Node.js uses, has a feature called startup snapshots: You run V8 and have it load your script (your obfuscated code), take a heap snapshot (after GC), and write it to a file. Then you specify the heap snapshot when loading V8, and it just hauls in the snapshot instead of reading and parsing code. The Atom team have done this on top of Electron. In their case the motivation was startup performance, not hiding the source code, but it has the effect of making your code even harder to find.
Note I said harder, not impossible. At the end of the day, if you want the code to execute on the end-user's computer, that code is going to be accessible to the end user. This is true even of compiled applications, although of course in that case a lot of organizational information that helps a human understand the code is lost in compilation, which happens less with obfuscated code. (But a good obfuscator makes code extremely opaque to human beings.)
Let me preface by saying I have no idea of what I'm doing. I've inherited a system from a contractor that we hired to do a job. I'm not significantly familiar with web development, and I have no idea how the magic voodoo was configured or really works. If you're going to reply, be patient, and assume I don't know jack about what you're telling me - please don't leave anything "for the reader to figure out." I'm embedded by trade and would rather bang bits than develop back end code for a website.
Server is running on an embedded Linux platform (basis is OpenWRT). The core is Lua/Luci, but there's a plethora of HTM files that utilize both HTML and JavaScript.
What I want to do seems really, really straight forward, but I can't seem to make it work: There is a file in /etc that I want to be able to download from the server to the local machine. Needs to work with IE, Firefox, and Chrome.
I would have loved something like:
download
But it doesn't work for files outside the subdirectory area that lua/luci knows about (i.e. I can't "../../../etc/file")
I've tried several different things, but the biggest issue is I can't seem to get the lua/luci stuff to recognize anything new in the same directory that contains some of the htm files, nor anything from the server's root directory (e.g. /etc/file). Usually what I do goes back to the home page or displays:
No page is registered at '/admin/talon/file'.
If this url belongs to an extension, make sure it is properly installed.
If the extension was recently installed, try removing the /tmp/luci-indexcache file.
(And yes, I clear the cache before I reload the page).
I'm OK with creating a symlink to the /etc/, but that hasn't been fruitful, either - mainly because I really don't know what kind of magic the lua service is doing to find the existing files.
I'd prefer for the solution to be in just HTML and JavaScript.
Yes, I've looked around for a basic solution, but either the questions want to do more than just download, or there's not enough information for me to figure out what is supposed to be done.
Please post a full solution, not just snippets.
I was able to figure it out based on some other code within that same source. It worked on one page, but not another. Not sure why - just more sorcery. Had to work within the LUA scripting language to get to the file I wanted; HTML was straight forward. If I knew what the magic thing was to make it work, I'd post the actual solution, but I think the solution is somewhat unique to how the original developer put things together, so it wouldn't be useful to anyone else.
Is it possible to not allow people view one of my website's JS file?
Demo:
http://js.maxmind.com/js/geoip.js
If you copy the URl and paste it in the browser, it will say "Unauthorized". But if you put it inside the HTML, it will do it's work.
Can I do that with my code.js file?
JavaScript is an interpreted computer programming language. It's not being compiled and it runs on the client's browser/computer, therefore, the client must see the script in order to execute it. That's why you cannot hide the code.
You can define in your server folders as restricted and that means the user can not access them directly, but when the browser loads the page it have to load all the components such as images, css files, js files etc...
If the browser can load them, it means the user can see them as well.
For example, you can also define that users are not authorized to see any .jpg files but they can easily save any image. Actually the browsers usually saves the images anyway on your local computer and cache them, so next time you load the page, it won't have to download files that weren't changed again.
As others already mentioned, trying to hide a js code is very bad practice and you need to avoid it. If you want the make the life hard for other developers that wants to copy your code you can use this site to obfuscate your js code, but remmeber, it only makes it harder to read by humans, it does not provide you any security.
First, let me explain loud and clear: that is the worst security I can imagine for what it is trying to do. It is just shouting, "HEY NOBODY LOOK AT THIS INSECURE FILE."
Your question has been viewed 41 times so far. That means up to 41 people are wondering what that mysterious does and probably half of them can find easily out. In short, don't do this.
There is no client side security. I refer you to this answer, for instance.
As for how to implement the situation, as noted in comment it's probably done by checking the referrer header. To find out fully check the request headers in the dev tools in your browser and compare to the request headers used by curl (e.g. by using a post bin).
It is not possible to not allow people to view one of your website's JS files.
To be more precise, if someone can execute your JS file, they can view it.
Although you cannot prevent a user from being able to look at your javascript you can make it extremely difficult for them to understand what they are looking at through obfuscation or minification, for the latter there are many services that will do this for you; look at this for example. As for obfuscation I don't know of any way to do it automatically but it would be a similar approach.
If you have information in the javascript that you truly cannot allow a user to see, then I would suggest moving it into the server side code and only pass to the javascript the absolute minimum. As I am not sure what you are using on the server side I cannot give you a specific example; however in the past when using MVC I achieved this by passing the values I needed either to a hidden input ( if the value needed to be posted back with a form) or through jQuery.Data
In my .NET web applications I usually have a Scripts folder that contains all of my JavaScript files - jQuery mostly these days, with the occasional JavaScript library of some sort or another.
I'm running vulnerability scans against one of my websites through a scanner called Nexpose, and it informed me that the Scripts folder is open to the world - meaning unauthenticated users can download the JavaScript files contained in the folder and that this is a critical vulnerability. According to Nexpose, the Scripts folder should be restricted to only allow authenticated users to access it. Which leads me to my first question.
How do I restrict the Scripts folder to only authenticated users? I tried placing a web.config file into the Scripts folder and denying access to all unauthenticated users that way, but it didn't work. I was able to determine this myself but going to my website's login page, but not logging in, and then typing https://mywebsite/scripts/menubar.js and sure enough it allowed me to download the menubar.js file.
Second question - Why is this considered a vulnerability? I've tried to reason my way through the possibilities here, but I've failed to come up with much at all. Is it a vulnerability simply because Joe the l33t h4x0r could figure out the various libraries that I'm using and then maybe use known exploits against them?
Update
Overwhelmingly the answer seems to be that in no way should a vulnerability exist just because a .js file can be opened and read on the client's browser. The only vulnerability that might exist would be if the developer were using the .js file in an insecure fashion of some sort (which I'm not).
Logically, you wouldn't want to actually disallow access to the actual files because then you couldn't use them in your webpage. The webserver makes no distinction between a browser requesting a file as part of the process of rendering a webpage versus someone just manually downloading the file.
As a result, the answer to your first question is: you can't and wouldn't want to. If you don't want users to access take it out of the web folder. If it's required to render your site, then you want anyone to have access to it so your site can render properly.
As to why it's considered a vulnerabiliy, who's saying it is? I can go pull any JavaScript Facebook uses right now. Or, more to the point, I could go to Bank of America or Chase's website and start looking through their JavaScript. If I had an account, I could even take a look at the JavaScript used once the user is logged in.
The only thing that you might need to worry about is the same thing you always need to worry about: exposing details that shouldn't be exposed. I'm not sure why you would, but it obviously wouldn't be a good idea to put your database password in a JavaScript file, for example. Other than things like that, there's nothing to worry about.
In most cases it's not a vulnerability. Consider all of the massive public sites with anonymous traffic and/or where it's very easy to become an authenticated user (Google, eBay, Amazon, etc.) These sites also have some of the most elaborate scripts.
The more subtle thing to watch out for are other files which you DO want protected. For example, if users must login to your site and purchase a document, video, image, etc. before viewing it, it certainly should not be in a publicly accessible folder.
Yes. You should keep most of your processing to be done server-side, as most (if not all) client-side scripts can be edited, and such. Most sites use Javascript, so simply using it isn't dangerous, you just have to be careful about what you do with it.
Also, to answer your first question, don't protect them if unauthenticated users need them too.
Sounds like some security suite has an itchy trigger finger. The only two problems I could see is that you could end up loaning your server out as a CDN if someone chooses to point to your jQuery or your -insert library name here- OR (now this is a real security risk) if you are also serving any kind of dynamic .js files out of there that could pose a potential threat. The only other thing I can think of is if you have your "custom" app js in the mix with all the libraries someone could potentially discover your endpoints (web services and such) and try and see if they're secure... but that's it! nothing more... (unless you did something really dumb like hard code a password or something in there... lol)
So the attack isn't that people can edit the script the attack is getting the web server to arbitrarily write to a directory. What you need to do is make sure they are read-only files. chmod 400 or windows read. In terms of Defense in Depth (DiD) you want to make sure the web server is a non-privileged user that cannot log into the system. Further what needs to occur is that you are doing all data sanitization on the server, irrespective of what you are doing on client side, because you do not control the client side. Typically this involves making sure that you cleanse all data coming from the web as well as the database before it gets served. One of my favorite things to do is insert arbitrary javascript into the database and watch it do things in the UI because the development team assumed everything would be fine since they already cleaned it once.
I can provide more details around securing the system if it is warranted.
We recently got a call from one of our clients, complaining that their site has some "strange looking code" at the bottom of the page. We checked out the source code, and discovered that about 800 bytes of malicious javascript code had been appended to the templates/master file, after the </html> tag. I won't post said code because it looked particularly nasty.
As far as I can tell, there would be no way for this file to be edited in any way, unless someone had direct access to the server and/or FTP login details. The actual file itself has been modified, so that rules out any kind of SQL attack. Besides a person physically gaining credentials and hand-modifying this file, would there be any other logical explaination for what happened? Has anyone else had experience with something like this happening?
The places I'd check are:
File modification times (to see when it happened)
HTTP server logs for signs of funny-looking GET params (eg, ?foo=exec('...'))
FTP server logs
SSH logs (something similar happened to me once, and it was because someone gave out their password)
Also, I'd immediately restrict write access to all the site's files, just to be safe from the same attack (of course, the vector is still open, but it's better than nothing).
If the attacker doesn't have other file access, it's likely that there is an exploit in the code somewhere that allows the user to execute arbitrary code. Use of passthru(), exec() and eval() are common problems here. If there is FTP running on the same machine, that's typically a strong attack vector as well.
I'm not sure that I would categorically rule out a SQL attack (especially a reflected one combined with the above exploits), but it's not clear that it would be one, either.
To your question, it could be either automated or personally targeted, it's hard to say with the level of detail given. As others have said, switch out as many passwords as you can, restrict access to the server, and then start inspecting logs to see where things went wrong. That will be more successful than ripping apart the app itself.
You don't specify, but if you are you shouldn't be using FTP on a production server anyway because it's inherently unsafe (among other things it transmits credentials in plaintext, making you easily prey to a sniffing attack). Always use SFTP.
If you are using plain FTP this is most likely the attack vector, particularly as modifying the files is all that as happened. If your machine has been completely penetrated I'd have expected to see more than that.
Almost certainly compromised credentials allowing someone to alter the code remotely. Is the server located on site?
Here is how I see it.
Using an FTP program? Your ftp log files storing passwords, paths ect.. gets grabbed. The passwords get decoded.
Try not to store FTP passwords in the FTP client. Or do like above, use SFTP.
We had a similar issue and seems to have come from one computer with a set of FTP logins. Also as this computer had many previous odd issues with it. Javascript would not work right, odd session timeouts or simply removed. Which to me indicates this computer had something on it.
Do make sure to find and remove any suspicious files in your website. If they had access to FTP, most likely they left a backdoor script somewhere which would enable them to upload/modify files on your website via a specific URL even after you change your FTP password or switch to using SFTP.
Try running the script found here if you're using PHP.
To detect a existing malicious code, I recommend that you use a good anti-malware scan engine on the server to detect malicious code on the website´s files.
Many times, the server isn't vulnerable, but the website is! To prevent this, use a Web Application Firewall that can take a look on every request to detect and block a attack attempt.