For intrusion detection, tripwire, using crypto hash integrity checking - what can be expected?

Typically default installations of host based IDS products like Tripwire, will come with a database/list of files protected.  This will usually focus on things like configuration files and system binaries which change infrequently and not on things like application log files which do change frequently.

If you need precise data for that product I'd recommend looking at the vendors web site as they'll have more exact data for each OS that they work with.


How does DHCP starvation work? How to prevent it?

Well Wifi or 802.11 is a protocol used at layers 1 and 2. DHCP works on layer 7 and uses a broadcast message to the whole network to which any DHCP server will/may reply to. So it's not only related to wifi it's, as Rory mentioned, applicable to any network using DHCP.

It's indeed the same as DHCP exhaustion. You as an attacker, will be sending tons of DHCP requests with spoofed MAC addresses to the DHCP server as to deplete the pool available IP addresses.


It's a good idea to make sure the system runs in a controlled environment until it is fully updated.  Make sure that the system is not running any services that accept incoming connections, and that the system does not make any outgoing connections to any servers (except the update servers), until the system is updated.  Even better, if the system is behind a hardware firewall that prevents any incoming connections from external hosts from reaching the system.  With such a controlled environment, the window of opportunity is very small for an attacker who is trying to exploit a vulnerability in the yet-to-be updated system.

There are actually Windows XP systems that have been running for years in similar controlled environments, without being compromised, even through Windows XP has been end of life since 2014.


Is it secure to handle the OAuth 2 Authorization callback from a CDN?

First - as you wrote the third-party authorization server requires client secret known only to The first-party API - so only your back-end can actually exchange authorization code for access token - nothing wrong here.

Second - you should be using HTTPS for your redirection endpoint so make sure your CDN support it. Otherwise somebody can eavesdrop the exchange, submit the access code first and take-over user session.

Third - make sure You are using OpenID Connect provider or something similar if you want SSO. Plain OAuth is not designed for authentication (OAuth Authorization vs Authentication)

Last - unrelated to OAuth - you have to asses how putting you index page on CDN affect your application security. It probably improve your DOS protection but introduces element outside your direct control.


MD5 should be considered completely compromised for password use, and has been "deprecated" for passwords for a long time.  It doesn't even have to involve preimage attacks or explicit vulnerabilities.  It is as simple as the fact that the hash rate for modern GPU stacks against MD5 is so fast that you can feasibly brute force nearly any password (okay, I exaggerate slightly)

This is an extreme setup, but it can run through almost 200 billion hashes per second.  That means it can guess about 200 billion passwords every second if they are hashed as MD5.  I don't have an exact translation but as you can imagine, being able to try 200 billion password guesses every second means that even strong passwords can get easily cracked.  The article suggests that it can crack a 14 character windows XP password (which is slightly weaker, and has roughly double the hash rate as for MD5) in just 7 minutes.

More realistic hashing setups might hash passwords at roughly a tenth of that rate, but even still it is quite possible to brute force any realistic password that is hashed with MD5.

Edit to address the second half of your question

Is this an immediate threat?  Yes and no.  In practical terms it is a theoretical threat, as your passwords will only be vulnerable in the event that this internal system is breached.  However, the more you read about the very involved kind of hacks that criminals go through when they want something, the more you realize how important it is to have thorough security at every level of the system.  I personally believe that internal systems should be as secure as external systems.  Here is a good example of a time that bad security lead to expensive breaches:

https://gizmodo.com/hackers-found-a-new-way-to-rip-off-atms-1818859798

Moreover, the other issue is that MD5 has been "out-of-fashion" for password storage for quite a long while now.  I would be very concerned that the rest of their security is equally out-of-date, and that this internal system of yours is full of security holes.

Another edit

An important thought to keep in mind: with these things an important consideration is the potential damage done in the event of a breach.  I don't know what this internal system does, but there is one important bit of sensitive information it definitely stores: your user's passwords.  Even if that is all it stores, it is potentially dangerous.  Here is a very plausible worse-case scenario.  What are the odds that you have an administrator that has a user account on this internal system?  If so, what are the odds that that person used the same password for the internal system as the did for the password to administer, say, your company-wide email system?  If so it is a short hop, skip, and jump from cracking an MD5 password to taking control of your email system, and from there to probably any aspect of your company that is web-facing.

While you try to work things out with the people who manage your internal system, you can think through this thought process yourself and take appropriate steps: "If a malicious user managed to get a hold of the password to email account X, how much trouble could they cause?".  You would be surprised how many companies out there have effectively their entire system dependent upon the security of a single email account, and that without any 2FA.  If that is the case for your company you should fix that, regardless of what this third-party vendor says.  Otherwise your worst-case-scenario is very bad, and this internal system is just one of many ways in which a malicious attacker may be able to cripple your company.


What FOSS software do you like to use to build intrusion detection stacks?


Do cloud-based password managers invalidate even the most secure architecture?

LastPass is "safe" for most use cases. I suspect that Edward Snowden and Julian Assange do not use it however. (If you're not familiar with these guys, they're both on the run from the US government for releasing classified data).

An important feature of the LastPass design is that their cloud systems never see your passwords. All your passwords are encrypted on your device, using your master password. The LastPass servers only ever see the encrypted passwords. That is a major technical mitigation and makes me happy to use LastPass.

Safe does not mean zero risk. A colleague of mine found a Chrome zero-day that allowed any web site you visited to steal passwords from your LastPass vault. But all web browsers have had a number of similar vulnerabilities, and despite this, they are generally considered "safe" for typical uses.


What you are describing is 2 factor authentication, whether it's the most secure of 2 factor authentication is a question for a security expert though.

Wikipedia does offer a great example of what 2FA is and i believe the step you mentioned would be classed as two 2FA.

  an automated teller machine (ATM) typically requires two-factor verification. To prove that users are who they claim to be, the system requires two items: an ATM smartcard (application of the possession factor) and the personal identification number (PIN) (application of the knowledge factor). In the case of a lost ATM card, the user's accounts are still safe; anyone who finds the card cannot withdraw money as they do not know the PIN. The same is true if the attacker has only knowledge of the PIN and does not have the card.
  From Wikipedia

In fact what you're proposing is very similar to how Steam authenticate users on new machines.

You login using your username and password
A verification email is sent to an already verified email address to confirm you want to allow access to your account from that machine.

Without access to both the knowledge factor (your username and password) and the possession factor (access to the email address) you cannot login on a new machine.

2FA isn't for everyone though so by default i think this should be turned off and you should encourage the user to activate the feature themselves.

Some users may not want the extra friction which comes with 2FA and some users may simply not value the security of their account higher than ease of login.

Edit: To answer your question...
It's not a bad experience IF they're not forced into 2FA and it depends entirely on their value for security over ease of login.


Firebug appears to be decrypting SSL traffic: is it the correct behaviour?

Sounds like there is some confusion over the protections that different parts of your system provide.

HSTS enforces HTTPS for users who have previously visited the site over HTTPS, for a given period. If a user has never visited the HTTPS version of a site, and the site is also available over HTTP (without a redirect to HTTPS), it will do nothing - the traffic will be unencrypted.

Firebug accesses data after decryption - it's a debugging tool. If the browser can see it in clear, Firebug can see it in clear. This is not a vulnerability, unless the website is sending data which shouldn't be sent (e.g. passwords from server), in which case the vulnerability lies with the website, not with Firebug.

If you are sending passwords from the server to the client, you have a problem - this should never be required. Passwords should be considered as a one way thing - users type them in, and they are checked on server side. This minimises the chance of any passwords being discovered without a larger server compromise.


Brutalized VPS recovery data now available. Considerations?

I'll start with what to do with your current system:

Get in and make a backup of everything.
Unless you can demonstrate major losses ($10k+), I wouldn't even begin to think about involving law enforcement.  They have their hands full, and given the current patterns on the internet, it's highly likely that your culprit is in a different country than you are.  Nobody is going to do an extradition process for hacked Wordpress sites.  (Sorry, I know it's hard to hear, but it's the reality.)
Burn the current server to the ground.
Consider every password on your old server compromised.

Now, how do you build a new server to avoid this happening again?  I'm going to make a few assumptions based on what you wrote in your post:

Multiple Wordpress installs.
mod_php on Apache
CPanel/WHM

Here's a few recommendations:

Get your new server.
Do a fresh installation of your applications, and setup strong passwords/credentials that have nothing to do with your old ones.
Configure SELinux to limit the exposure of each site as much as possible.
Be careful what wordpress plugins you install.  They have a much worse security track record than wordpress core.
Ensure that directories that are writable by the webserver are never interpreting files as PHP.
Use 2-factor authentication for everything you can.

CPanel
SSH

Without being able to do digital forensics on your system, it's hard to know for sure, but I'm going to go out on a limb and guess what happened:

Attacker runs scanner looking for vulnerable Wordpress installs.
Attacker finds vulnerable Wordpress on your server.  Gets RCE as webserver.
Dumps password hashes for wordpress databases.
Cracks password hashes, one of them matches a WHM/CPanel password.
Gets into CPanel.  Maybe as an admin, or maybe the version of CPanel had a bug that allows privilege escalation to admin.

You talk about fear of retaliation and the attacker coming after you again and again.  Unless this is personal (a vendetta of some sort), I wouldn't worry about that.  Attackers like this will just move on to their next compromised host.  Just don't give them another chance.


Mac OSX: What is the safest way to access an unknown USB storage?

So you've got yourself a hot agent and want to examine it? This is going to be fun!

First, do not simply plug it in and look around. Even if you were to create a 'sandbox' finder, that would not protect you from potential malware. So how do you actually see the goods? Well you need to perform a forensic examination! Here's what you'll need:

A Virtual Machine is crucial so you do not infect your machine. Make sure you configure it so that the VM does not have network access.
A forensic imager. I use helix or autopsy suite. FTK imager works well if you have a windows VM.
A Write Blocker to protect the integrity of the usb device being examined. This means preventing all writes to the target usb. This keeps a pristine record of the target but also prevents some types of malware from altering themselves on the target usb. Personally I say to use a hardware write blocker because they are more reliable (just go to amazon and find one).

Configure your VM with preferably a linux distro (like helix). Now, you simply attach the write blocker to your pc and set that up. Open your imager program and finally plug in your hot usb stick.

You now take a forensic image of this drive - either directly into RAM (if you have the capacity) or onto another (non-OS) drive. It may take a while depending on how large target is. Once you have the image, you can look through it in any number of ways using that same imager program (FTK makes it super simple).

The whole concept is called incident response and SANS has many good documents on what to do. Here is one. Also, I used this book to learn a lot about forensics. I know a guy taking his CISSP and he also just finished it so it is still relevant.

Good luck and have fun!

In response to your comment, malware can indeed spread without you knowing it once you connect an infected device. The best way to protect against that is to run the examination in a VM with a different OS than the target. The different OS helps in disallowing the malware to run and the VM acts as damage control should the malware break out and run anyway.

The most common and easiest way malware can spread like this would be the 'autoplay' feature but if you actually consider what is happening behind that feature you can see that there are certain things from that external media being loaded into RAM and written to your pc's harddrive (in the form of metadata/logs/etc). All* an attacker has to do is leverage that threat vector. * this is no small feat however :)

It's not all gloom and doom though. All you have to do is toss up a properly configured VM and you've essentially stopped 99.99% of that particular threat.


Bad torrent experience: How can I punish a miner owner?

First off, you shouldn't be using pirated software. I would suggest running an antivirus scan and see what it finds, and can remove.  If you can't get rid of the bitcoin miner, either with antivirus, manually deleting it, or another way, you will probably have to re-install your computer.  As other posters have commented, there is very low likelihood that the police would take the case.  It would be like someone going to the police saying the drug dealer cheated me (e.g. you would possibly be in trouble too).

Probably the best way to punish the miner owner is to clean up your computer, and not use torrent sites in the future.  Also encourage others not to use torrent sites.  People are usually in it for profit, so if they are giving you free software, what else are they giving you?  Probably malware to get access to your banking info, in this case a bitcoin miner, etc...  If enough people listen, and stop using torrent sites, then business will probably dry up for the crooks!


Defense-In-Depth With Common Security Controls

would defense-in-depth still be achieved even though all three security controls have at least one common attack surface?

No, you can see it very well with anti-virus software for instance: they look like defense in depth as they put protection systems at several layers (network firewall, browser plugin, process monitoring, file analyzing, etc.), however an attacker just has to defeat a single thing, the anti-virus software itself, to make the whole protection system to collapse.

As you correctly notice, the Linux kernel does not implement its authorization checks in a monolithic way, instead it uses a modular way where security modules (called LSM, see here and there for more information) can come from different providers and complete each other (hence the in-kernel DAC system can be completed with capabilities and a MAC system both coming as modules).

This offer several advantages, both in terms of freedom which is at the core of the GNU/Linux philosophy and security:

More freedom because a security module being not tightly integrated to the kernel, this allows a user (or more likely a distribution maintainer) to select the LSM better matching their needs (which, at the end, brings more security to the end-user). For instance some prefer AppArmor's security model, some prefer SELinux's one, etc.: the choice is not enforced by the Linux kernel development team. This is explicitly stated in the Wikipedia page previously linked:

  Linus Torvalds rejected SELinux at that time, because he observed that there are many different security projects in development, and since they all differ, the security community has not yet formed consensus on the ultimate security model. Instead, Linus charged the security community to "make it a module".

Security because of two reasons, which both end-up as being benefits from code isolation:

A correction made on one security feature should not cause any issue on another one. An update on SELinux for instance should not affect DAC or capabilities authorization systems as each one uses distinct code and data structures. This would not be the case if all this would be implemented as a single, monolithic piece of software.
A vulnerability affecting one security feature should not endanger the other ones. In case of vulnerability affecting SELinux for instance, such vulnerability will not void DAC and capabilities security systems as in the anti-virus example shown above where a vulnerability in the anti-virus software will most likely cancel all its security benefits.

Defense in depth should not be conceived as having simply several layers of security controls, instead it should merely be seen as having several layers of security systems. It is in fact the isolation between each systems which will bring you a good guaranty that it will take time for an attacker to defeat your security infrastructure.


Understanding an attempt to exploit a webserver

This seems to be useless since the output will be printed to stdout and not returned as a server response?

It depends on the vulnerability being exploited. Sometimes, an attacker can determine if a system is vulnerable to an attack based on the HTTP status code or the time it takes for the response to be returned. If the attacker can send an attack and learn that the system is vulnerable, they may send follow up attacks but if it didn't work, move on to try a different exploit.

There is no technical reason why a server couldn't process GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0 as executing the cmd.exe file and passing '/c dir' as arguments, capturing the output and sending it as a response to the user. It all depends on the design of the server that is being interacted with. In hindsight, this design is silly, as it allows attackers to take advantage of a system, but in the early years of the web, allowing this kind of access could have been desirable.

  Also, why is it even possible to request files outside of the www directory? Should this not be forbidden per default?

Web servers are complicated and engineers make mistakes. Keep in mind that this type of attack is characteristic of the web in its infancy.

  What are the user privileges such an attacker has when he issues those commands in a self created shell? I guess the privileges of the running server.

If an attacker could leverage such an exploit, it is probable that the attacker would get the privilege of the running server. But, the execution is going to happen according to however the program was written. Its also possible that the server could lower privileges before passing off the execution. That's not likely, but the point is that it always depends on the context of the system being exploited.

  Could a firewall prevent this attack and if not, are there other measures which could have prevented this?

Yes and no. Firewall is a bit of an oversubscribed term, so some firewalls will have this capability and others will not. Some firewalls only focus on network traffic in the sense of source IP:port, destination ip:port, and don't look at the actual message being sent. Other firewalls include an Intrusion Prevention System or IPS. This is an application that compares the traffic to signatures of known bad traffic. So if the firewall has an IPS, and there is a rule for this traffic, it would be blocked.


Hardening charity volunteers' access to a web server

Are end-user devices provided to the volunteers by the charity? If not, are you really sure that you want to personally take in charge the hardening and ensuring support of all volunteers' devices of all kind?

Unless you are in a corporate-like environment where devices are provided and managed by the company, you would rather consider that end-user devices management is up to the end-users themselves. This does not prevent you from giving useful advises, but nothing formal and nothing engaging you to provide some kind of universal support service to the end-users.

On your side however, if required you can try to detect suspicious activities on the server side and prepare an action-plan in case such alert would be raised. For instance, you can tell the users some example of activities assimilated as suspicious (it can be the same user connecting suddenly from a different country, posting advertisements / offensive / unusual messages, manifestly trying to penetrate unauthorized areas, etc.) and explain what would follow (revocation of the VPN access, user contacted by phone / mail / whatever, etc.).

I talked about a VPN because you mentioned, but if all you want to provide access to is a website, client-side certificates may be a lighter and more appropriate option than a full-fledged VPN.


is the evil twin attack considered sniffing?

The act of setting up an evil twin is not sniffing, but the generally accepted definition (CISSP) is that the purpose of the evil twin attack is to harvest credentials, etc.

It might also be argued that the evil twin attack is not strictly a sniffing attack if the attacker only uses it to DoS the people on the network.


X-Webkit-CSP Security header in the browser

This is a deprecated HTTP header and it is being replaced by the
Content Security Policy header.  This will prevent prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.

All the X-* policy headers are non standard headers and following headers are also deprecated and replaced by the CSP.

X-Frame-Options

X-XSS-Protection

X-Content-Security-Policy

Ref : https://content-security-policy.com/

https://developers.google.com/web/fundamentals/security/csp/


server with eth0 promisc-mode vulnerable to attacks outside firewall?

Yes.

There have been known vulnerabilities in the snort code that allow specially crafted packets to cause remote code execution and DoS. The problem for the attacker is knowing that snort is running, and which vulnerable version is running, but you still need to design your IDS to defend against such a possibility.


The answer will of course depend on which browser you're using. Here are the two that I have available:

Chrome

This is easy to get; open Developer Tools (F12) > Security tab.

I can see that my browser negotiated curve X25519 (which if you look upis a 256-bit curve offering 128-bits of security) when I connect to security.stackexchange.com:

Good question whether the key length for traditional DHE would show here also, I don't know of a site that's still using DHE on which I could test...

Firefox

The Dev Tools (F12) doesn't have a Security tab, and clicking More Information on the green lock tells me the cipher suite was negotiated, but not which curve:

A few minutes of googling did not find me a way to get the (EC)DHE info. I'm actually surprised that I can't find a firefox add-on to do it either. You've got me stumped there.

Other browsers

You'll have to play around in the dev tools and see if it's exposed.

The upcoming TLS1.3 is trying to simplify cipher suited by moving more information out of the cipher suite string and into extensions field the same way the size of elliptic curve is negotiated today. So I expect that once Firefox starts using TLS1.3 by default, they will have to add some sort of viewer for this data.


Anyone can identify tool used to perform this attack?

It is a vulnerability scanner called Jorgee. The log actually tells you this because it is displaying the user-agent for each request. A quick search on the user-agent reveals a whole host of information about Jorgee.
There's a couple of steps you can take, you could setup something like Fail2Ban. If you didn't want to setup anything too complicated then you have a few configuration options you can do. They won't stop everything, you would need to do a lot more if you were trying to defend against anything other than an automated bot.
Firstly, you could look for any user-agents which you don't want, for example in this case, you can look for any user-agents which show Jorgee and you can drop those requests.
Secondly, you can setup rules to block unwanted host headers. This is fairly trivial to do, and you can create rules to only allow host headers that you want specifically and drop any host-headers that are either numeric or not in your list.
As I said, you would need to do a lot more than this to stop anyone even remotely serious but this is a start.


How is this site forcing page reloads with JavaScript disabled?

The page refreshes periodically because of this tag:
<meta http-equiv="refresh" content="105">

That asks the browser to refresh, without needing JavaScript.


How can I implement DVD copy protection?

If your DVD can be read by a standard DVD player then it can be read by a standard DVD player. This implies that it can use only that which is supported by standard DVD players, i.e. CSS, which is hopelessly weak.

You would have better luck with AACS as used in Blu-ray disks. What AACS tries to achieve is still "impossible" in theory, but in practice copying a Blu-ray disk or extracting its contents requires some hardware which costs more than 40$ at the nearest electronics shop. If the contents of your disk are interesting in some way, there will come a time when some people will find it fit to invest some effort in extracting them, but you might hope for a few weeks or even months of respite before this event.


What features would you use to detect a backdoor or a bot installation?

In general security systems that use a machine learning approach are based on features, metrics or characteristics. Depending on the area (Anti-Virus, Anti-spam, NIDS) the characteristics are different. For example: In the area of Spam the subject will be a key characteristic as well as if the message have an attachment and the attachment could contain another file (zip, tar files). On the other hand, in the area of Anti-virus some of the characteristics could be the file type, some specific strings inside the binary, syscalls used and so on. And as you can guest for a NIDS the features could be completely different, packets up, TCP push, HTTP messages, URI content, and so on.

In general that type of articles are very dependent of the data-set used, so is easy for the authors fiddle a bit the results on them. Bear in mind that when this systems have false positives they need to find another characteristics that could differentiate with the false positive and this sometimes is hard to do it.

In the case of the back-doors you need to study the characteristics and the behavior of some of them and create your own characteristics, probably a network traffic features in combination of normal malware could be a good approach for start.


Strange Chrome notification on Android 8.0

My guess is that the website is using the HTML5 notification mechanism to send a notification (in this case ads) to the browser.  And you probably accepted that the site can send you notifications. See this support document on how to manage which site can send you notifications.


I would recreate the content found here but there really is no need because it is formatted so nicely. Basically, because the password is stored with the document, you can find the password hash pretty easily in a hex editor. From there, you can simply brute force it.


Secure Implementation of Password Database

The current general best practices for authentication are in the NIST SP 800-63-3 Digital Identity Guidelines standards, especially in SP-63B Authentication and Lifecycle Management.

These NIST standards are an easy read for developers, and besides telling you what to do, it also talks about why you want to do certain things.  (If you want more details than the NIST standards give, we're happy to help.)

That said, let's look over your current authentication system and address your concerns:

  The user is prompted for username and password on registration page

The registration page?

This is probably mistyped and you meant a login page, but if there is a registration page that anyone on your network can access, then you need to explicitly define a seperate authorization system.  For example, anyone can register for an account on any online store, but this account doesn't give you access to the part of their site that lets admins change the prices on their products.

  The server hashes the password using SHA256 to create hashes of equal-length

This step doesn't add any security, or improve system performance in any meaningful way, especially since you're using bcrypt, which will discard any part of the password past the first 72 characters anyways.

It is unlikely, but this step could reduce entropy.  The reduction in entropy is insignificant in the grand scheme of things, and requires users to already be using long and randomly generated passwords, but since this is an extra step that doesn't improve security, I suggest leaving it out.

  A random salt is generated using a reasonable work-factor.

I'll admit that I was very confused seeing this step at first.  If this were about car maintenance, it would make as much sense to me as "Added synthetic oil with a reasonable octane rating."  However, in the comments it was revealed that the specific bcrypt library being used is the bcrypt library hosted by PyPI.

I can't find the source code (and am allergic to languages that use whitespace to delineate scope), but based on the documentation, it appears that the library's function call to generate the bcrypt's parameters is named bcrypt.gensalt(workfactor), and this method itself takes a work factor as its parameter...  Extending the car maintenance metaphor, it would be as if there were a function named vehicle.refuel(viscosity), or vehicle.changeoil(octane).

A salt, in authentication and cryptography jargon, is a random value that is added to a plaintext, to make it infeasible to pre-calculate the output of a cryptographic hash function or key derivation function.  The salt itself is not a secret; its only strength is that it's not known beforehand.

A salt's value is measured in how long it is, also called its entropy. (Entropy in cryptography is a nuanced topic, that depends on more than just length, but for any reasonable library that creates a salt, the longer the salt, the more entropy it has.)

A work-factor, on the other hand, is jargon that is specific to key-stretching algorithms, such as this bcrypt KDF. The work factor defines how much work the CPU (or GPU, FPGA, or ASIC when you're the attacker) needs to do, and its main feature is that it takes longer to calculate the output, using steps that can't be bypassed, guessed, or ignored.  This may seem counterintuitive; you want your application to run as fast as possible, right?

Well, the general risk is that your database of passwords will be leaked.  Top retailers leak passwords all the time, and you don't have the millions of dollars to spend securing applications like top retailers do, so assume that your database of passwords might eventually be leaked, too.

The tradeoff here is, when logging in, your user will have to wait an extra second.  When an attacker is cracking your passwords, they can only guess one password per second, per CPU that they put to the task.  (Motivated attackers can take some shortcuts, but even 10 guesses per second is MUCH better than billions of guesses per second if you're just using single round SHA256 instead of a key-stretching algorithm.)

So, the salt and the work factor are both important parameters that have nothing to do with each other. I'm sorry that your first exposure to the concept was through a very poorly named function.

  The hashed password is hashed again, this time with the salt. (The salt generation and hash uses python's bcrypt)

Minor nitpick, but this is because I'm being thorough: The results of bcrypt aren't a hash, even though many people call it a hash, and everyone here will know what you're talking about if you continue to call it a hash.  The results are a stretched password or a derived key.

  The username, work-factor, salt, and hash are stored in the password database.

If the result looks something like this, then you already have the work factor, salt, and derived key all together:

$2a$08$0SN/h83Gt1jZMR6924.Kd.HaK3MyTDt/W8FCjUOtbY3Pmres5rsma

The 2a is the algorithm (bcrypt with unicode support).

The 08 is the work factor.

The next 22 characters, 0SN/h83Gt1jZMR6924.Kd., are the salt.

And the rest is the derived key.

If you're getting something different from your bcrypt library, find a different library.

  When a user attempts to log in, the entered password is hashed in the same way and compared to the record in the database. (The salt used for comparison is fetched from the password database using the entered username as the key.)

Great.  However, the library that you're using is already doing the heavy lifting for you, so use your library to its fullest.  The bcrypt.checkpw function will pull out the work factor, salt, and derived key for you.  It will then run its KDF and compare the results.

Using this library function means that, if you decide to change the default work factor in the future, you don't have to have separate code to handle the older derived keys, as bcrypt.checkpw will be able to figure out the desired work factor on its own.

  If the hashes match, a cookie is given to the user which grants them access to the restricted web pages.

This sounds great on the face of it... but make sure that the cookie itself doesn't contain the authorization.  It should contain a randomly generated string (session ID) and when accessing the site, the server should look at that session ID and check its own resources to see if that session ID is properly authorized.  Clean up the session IDs after a while, too.

If your cookie contains "is_authorized=true" instead of a session ID where the server double checks its own resources, then people can just make their own authorization cookies and will never need to authenticate.

Concerns:

  Saving the hash, work-factor, and salt in the same database seems like bad practice.

The salt and work factors are not sensitive in any way, but are necessary to validate a password.  At best, any attempt to hide the salt will result in security-through-obscurity, which isn't any sort of security at all.  You might as well store the work factor and salt right alongside the derived key, to save yourself the headache, because splitting them up aren't going to prevent an attacker from getting to them.

  Does this method of hashing (reasonably) ensure that no one can determine a users password, including myself?

As far as your responsibility as a web developer? Yes.

And thank you for asking if it reasonably ensures that no one can determine a password.  They can still be guessed in offline attacks, but using a key stretching algorithm such as bcrypt will greatly hinder attackers, even in the worst-case scenario of an offline attack against a leaked database.

The only thing you can do better, is to add 2fa and demand that your users use password managers with 24+ character long, truly random passwords that are unique for every site.

Note that password resets should not depend only on this second factor.  As per the NIST guidelines, it should depend on the same identifying factors used in setting up the account in the first place (and make as much noise as possible on as many user communication channels as your application knows about) and utilize at least one additional factor, if available.

For most web applications, this means an email to the account used during account registration (NOT text messages to a cell phone, or security questions by themselves, though these can be additional factors after the email is sent).  For an internal business application, this means the user has to make a call to the sysops team/helpdesk (or, more realistically, they need to stop by the developer's desk).

  Everything currently uses http. Is https necessary if all access is within the local network?

You have to trust your local network to some extent.  However, it never hurts to add HTTPS.  If you're concerned at all, add HTTPS.  (The fact that you asked this questions means that, yes, you are concerned.  So yes, you should add HTTPS.)

Adding HTTPS is a good idea for non-security reasons as well, as web servers (and browsers) will use HTTP/2, if available, only over HTTPS connections.  This can speed up your site noticeably.  It doesn't apply in your case, as you're using a Python-script based web server, which is unlikely to have HTTP/2 capabilities, but it's a good habit to get in for reasons beyond "just" security.  (Security is more than enough justification in my opinion, but there are managers who need additional convincing.)

  Is using a cookie a good way to validate that a user has logged in successfully?

If that cookie contains a session ID rather than authentication information, that session ID is random, and the server verifies the session ID, then yes. This is standard practice for the vast majority of websites with any sort of user identification.


RSA encryption : How to create ".arm" certificate file for Public key?

Neither .arm nor .key are standard extensions. You should be more specific on who/what generated .key files and who/what is going to use .arm files.

I can only guess .arm refers to "ASCII armor" which is an old PGP jargon for Base64, a format where only 7-bit ASCII characters are used.

The PEM format is exactly that. Assuming .key files are DER encoded (binary), try to use openssl to covert your certificate to PEM format:

openssl x509 -inform der -in certificate.key -out certificate.arm


Does CSP mitigate against client prototype pollution XSS and DOM XSS?

I have done some research and found out CSP does block client side prototype pollution based XSS: XSS with CSP bypass. Similarly, DOM XSS case was different. When I used this code, saved at example.html
<!DOCTYPE html>

    CSP
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
    <meta http-equiv="Content-Security-Policy" content="default-src 'none'">

CSP

This payload popped alert(1): https://ba0c7a11a30b.ngrok.io/example.html#alert(1) but when I used this code, saved as example.php
<?php
header("content-security-policy: default-src 'none'; script-src 'self' 'unsafe-hashes';")
?>
<!DOCTYPE html>

    CSP
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
    <meta http-equiv="Content-Security-Policy" content="default-src https:">

CSP

it didnt result in alert(1). So I would say in most cases CSP mitigates DOM XSS and prototype pollution based xss.


How can I enforce that an SSH private key has a passphrase?

No. You can't enforce on the server side that the key has passphrase. Key is always on the client side and the server sees only the signature of challenge and public key. Certificates (aka signed keys) will not help either, because the public keys are signed.

I propose you to have a look at some kind of two factor authentication or smart cards if you want to go this way in security.


Can malicious communication be hidden reasonably well in encrypted network traffic?

While HTTPS makes it much harder to detect malware from traffic payload the communication can also be hidden with plain HTTP. This is done for example by encrypting the transferred messages with a shared secret or by using steganographic techniques.

Still, detection might still be possible by looking at the meta data of the traffic instead of the content. Such meta data are for example the traffic patterns: Even with TLS the direction and size of traffic is still visible, i.e. it can be seen when a request is sent and when a response is received. Visiting a HTML page with a regular browser will result in request+response bursts since the loading of the HTML page will cause a download of the embedded resources. Other meta data are features of the TLS handshake, like which ciphers are offered by the client and in which order, which TLS extensions are used, what kind of certificate is returned etc. Other meta data are target and timing of the request, relation to DNS traffic etc.

There was an interesting research by Cisco about this topic, see for example Detecting Encrypted Malware Traffic (Without Decryption). At the end of this link you will also find references to further research.


Where does nikto tool store its default reports?

Try this:

perl nikto.pl -verbose -h example.com

Also look up -output parameter in nikto manual.


Can you do a client and server side encryption

You can, but you shouldn't. It doesn't increase security, since the client side encrypted password becomes the point of attack.

The other problem with client side encryption is that if you aren't using an encrypted channel to deliver the code, there is no way to prevent it from being tampered with en route - an attacker could simply modify it to send the raw password to them as well as the encrypted one to you.

The best practice for this situation is to use an encrypted channel to send the authentication details - https, in other words. This ensures that only your server can read the password, and then you can check it in your server side code.


a sent message for an unknown number without me sending it

Yes, this is possible.
If your iPhone is not jail broken
There is probably nothing to worry about:
Apple send themselves a registration text to verify your iMessage registration (and says so in the text when activating iMessage).
The destination gateways receiving the texts are international, those for Europe are in Belgium, if I recall that correctly.
Just google the number and see if apple comes up as a result.
If your phone is jail broken
You might been "lucky" with some form of malware.
In that case, google on the number may still help and keeping an eye on the running processes and connections might be useful to find out more.


NISTIR 7966 (Security of Automated Access Management Using Secure Shell) - is there anything new?

Yolen described his motivation with existing examples in presentaion of LISA 2013, "Managing Access Using SSH Keys". https://www.usenix.org/conference/lisa13/managing-access-using-ssh-keys https://www.usenix.org/sites/default/files/conference/protected-files/ylonen_lisa13_slides.pdf

In the presentation as well as NISTIR 7966, they don't mentioned separate management system SHOULD be necessary. They just said lack of management frameworks introduce the risk. They give the "typical" case that have very large number of clients, servers, users and keys where management tools must be necessary. In general cases, risk and cost is just trade-off.  Many can keep ssh management without single-point system.


Is explicitly disabling a default in the sudoers file the same as not listing it at all?

Both solutions appear to solve the issue, removing Defaults pwfeedback
  from the sudoers file should work by itself, I think.

You are correct because, as per the sudoers(5) man page, the implicit default for pwfeedback is off:

pwfeedback' By default, sudo reads the password like most other Unix programs,
by turning off echo until the user hits the return (or enter) key. Some users
become confused by this as it appears to them that sudo has hung at this point.
When pwfeedback is set, sudo will provide visual feedback when the user presses
a key. Note that this does have a security impact as an onlooker may be able to
determine the length of the password being entered. This flag is off by default.

However, when there is an active vulnerability like CVE-2019-18634, mitigation advice is often to explicitly disable, for a few reasons:

An explicit disable is easier to audit than an implicit default disable.
An explicit disable will work even if a particular packager has altered the implicit default.
An explicit disable is more comforting to some people than trusting implicit defaults.


"Your connection is not private" for specific website, once when opening a new tab

Domains ending in .id.opendns.com are what OpenDNS uses to display the error pages for their Content Filtering service.
There are three likely possibilities for what is happening, but there is no easy way for us to tell you which is correct.
Possibilities #1 and #3 assume that somehow your computer is looking at multiple DNS servers (which could make sense if you are on a VPN). One of those DNS servers is returning the correct result, while the other is OpenDNS which is redirecting you to a block page. (For possibility #2, this is not necessarily the case.)

Your home IP address recently changed and the person who had it before you was using OpenDNS at home and chose to block this site. If this is the case, you can create a free "OpenDNS Home" account, add your IP address to it (which should remove that IP address from the previous holder's account), and turn off all blocking.

If your ISP uses "Carrier Grade NAT" to make multiple consumers share a single public IP address, there could be multiple people sharing the same public address as you, and at least two of them have OpenDNS blocking service set to block this site. Their two accounts are fighting with each other for control of that IP address. You can check if you are behind CGN to eliminate this possiblity.

Your work is trying to block access to non-work sites over the VPN - either they want to reduce load on the VPN servers or they buy into the myth that this will "improve productivity". In the former case, they could reconfigure the AnyConnect VPN to only pass traffic for specific IP ranges. In the latter case, they are deliberately trying to block this site and failing to do it properly. (This case is less likely, since it wouldn't make much sense for this to be the only site they block.)

If you disconnect from the VPN, do you ever have this problem?


What is the technique to determine if a user is "reading" a page called? (similar to "infinite scroll")

Is this feature more focused on analyzing user behavior than saving bandwidth

I think the original goal of it was to increase responsiveness by reducing the amount of time until the browser is fully able to render the page.

  What is this technique called?

Effective leveraging of AJAX

  What do providers do with this information?

It probably provides a more accurate view of dwell time and reader behavior as one of those side-effects that became a driving force.


What happens is that the HTML output is:

{{ timer }} is a variable which gets "translated" to whatever the ?timer GET parameter is. So suppose we have a legit parameter: ?timer=3. It gets "translated" to:

But what if you put some code in timer? 3');alert('xss');//

As you can see, the logo loads, and once it loads, the onload callback is executed. There's the vulnerability.

P.S. it's not in startTimer itself, because it parseInts the variable, and it removes everything but numbers, essentially 3'); ... becoming in 3.


Is there a benefit to having SSL connections on localhost?

If you don't have other users on this machine you might be right. If you have other accounts with the ability to connect from remote they might be compromised. If the attacker is able to completely own the machine you are busted anyway. But even if the attacker cannot get root he might be able to make mysqld crash and then take over the port (default port is 3306 which does not need special permissions). In this way using SSL could help a bit, because the identity of the (hackers) server cannot be verified.

So it does not help much bit it might help a bit.


Can prism know even data outside the US Data centers?

Anyone who really knows the answer to this question is either prohibited from telling you or is a political refugee in Russia.  I think it's pretty good bet that any data that passes through any one of the "Five Eyes" nations (GBR, USA, CAN, AUS, and NZL) could be captured.  And, of course, other governments could be doing the same sort of thing.


How to send remotely loadable CSS with an email as explained in ROPEMAKER whitepaper?

There are two ways of include resources inside an email HTML part: as links to external sites (i.e. <img src=http://example.com/... or <link rel=stylesheet href=http://example.com/...) or by referencing different MIME parts inside the same mail (i.e. <link rel=stylesheet href="cid:some-id-in-the-mail">). The "exploit" just uses the first way, i.e. loading the CSS from a server controlled by the attacker where he can serve different CSS on different times, thus causing changes in the rendering of the HTML.


How to evaluate the strength of a hashing algorithm?

A strong hashing algorithm would imply that changing even one character will result in a completely different hash.

A good hashing algo has these characteristics:

The hash value is determined by the data being hashed
The hash function uses all given data
The hash distributes all possible hashes uniformly across all possible hash outcomes
If you have a string and you take a very similar string, you will get a completely different hash result (changing one single bit of input should change all output bits with a probability of 50%. Another requirement is that the hash is, to the highest extent possible, statistically independent of the input, e.g. a high hamming weight in the input does not produce an abnormal hamming weight in the output. -Polynomial)

Please tell your management

not to be Dave, and just use one of the standard hashing algorithms. If you are using the hashes to store passwords, use bcrypt. When hashing a password you are also concerned about salts, bcrypt does all that for you. Plus it's all free.


Security tradeoffs while designing a mobile Web Service API

The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though.

Don't encrypt the password, hash it. Ideally using something like bcrypt.

  I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter the better, in order to reduce bandwidth usage. However, I'm not aware of how a token should be properly generated, in case some ten or more random bytes is not enough.

The most common system I've seen is using something like a JSON Web Token. When a user authenticates themselves, create a token with information identifying the user (e.g. the user ID) and an expiration date. Sign and return the token.

Every time the token is used to authenticate a user, verify the signature, confirm the the expiration date hasn't passed, and then use the user ID to identify the user.


What should be the life time for SMS OTP?

In case you really need to implement such a thing: Paypal still uses SMS OTP. They generate a new token every 5 minutes and will generate a new one upon request if I remember correctly.

From my point of view there is no reason not to do so. Your timespan has to correspond to other security measures (like rate limiting) to make sure the OTP is not guessable in that timespan. That's the only thing the timespan is really protecting from. That is because: if someone manages to carry out one of the other possible attacks (MITM on mobile network or attacking the mobile phone directly utilizing malware) every timespan that the user takes to input the key legitimately is sufficient to carry out the attack as well.


How to encrypt data asymmetrically to be decrypt my multiple users

One simple way would be for the chat originator to generate a unique, throw-away symmetric encryption key. Then the "invitation" packet to any other participant contains the encryption key, itself public-key encrypted with the recipient's public key. Or the "announcement" packet might contain all the necessary encrypted versions of the key.

This way, only the intended participants can come to know the decryption key, and since it is also an encryption key, they may use it to send messages as well as receive them.

This is not the same problem as broadcast encryption, since each participant uses the same key and knows it.

To revoke a participant, whoever has the right to do so sends a revoke packet containing a new secret symmetric key, encrypted with the public keys of the non-revoked participants.


No, this is not true, refer to this excellent answer for more details.
Can't comment on this as I have never used the framework before. Are you sure there isn't a way to set the expiry timing of the session cookie using the framework itself?
The config file should be stored outside the web root. See my answer here. The directory where it is stored should be adequately secured of course. Proper file permissions should be enforced.


Are staggered roll outs of security patches bad?

Excellent question.

Yes, your understanding is correct, as well as your rationale behind it.

Staggering roll outs for new features often makes good sense.

Staggering roll outs for security patches rarely is a good idea.  As you pointed out, this gives even more opportunity for the vulnerabilities to be exploited.  Perhaps even more importantly, the patches can be quickly reverse engineered to develop exploits in a rapid fashion.

Microsoft often publicly releases their patches on the second Tuesday of the month (and also sometimes on the fourth Tuesday).  This has commonly been referred to as "Patch Tuesday".  There's a reason we call the next day "Exploit Wednesday".

It's unfortunate that a significant chunk of the Android ecosystem has not learned from this phenomenon.

Updates:
Several knowledgeable people have pointed out potential impact on internet infrastructure, including fears of overloading the entire internet.  The volume of internet traffic is monumental; security patches, even extremely large ones, are tiny drops in the bucket.  Microsoft releases large patches to hundreds of millions of users on the same day each month, and they have yet to "crash the internet".  Netflix, YouTube, and Twitch stream videos to millions of people every day, and even with their combined traffic, they have yet to "crash the internet".

On the other hand, Android patches are predominately (but not exclusively) delivered to wireless users.  There are solutions to any potential issues:

Provide users with a choice of when to download the patches.  This provides numerous benefits:

Does not disrupt the user's workflow
Creates traffic staggering due to human interaction and decision variability
Allows the user to wait until they are connected to a higher bandwidth system (perhaps at work, their university, at home WiFi)
Allows the user, at their own risk, to wait and see if others report problems with the patches

When distributing patches to specific regions known to have limited infrastructure that could be impacted, stagger the patches over the minimal number of days to avoid overloading infrastructure.

In regards to specifically the Google Nexus 6P security updates not being released to all users promptly, that's simply a poor choice by Google that is not in the best interest of their customers.  Compared to the massive volume of internet traffic, those patches are minuscule.

On top of that, that device is relatively rare in the Android ecosystem.    This further supports the statement that releasing the patches to all customers at once would not harm any internet providers.

Even the entire Google Nexus product line comprises only a tiny part of the Android world.  As a product line, however, there could be a little impact on infrastructure in select regions.  As such, the following methodology, while combined with the recommendations outlined above, will minimize infrastructure impact while maximizing patch distribution:

Release zero-day exploit patches immediately
Release scheduled updates on different days each month, a different day for each product
If a product has significant market share that could reasonably impact infrastructure in a region, stagger the roll out over the minimal number of days required to avoid infrastructure overload in that region only

Finally, according to your statements, it has been over two weeks since Google initially released those patches for the Google Nexus 6P.  That's more than enough time to know if their patches are causing havoc.  I have found no documentation from Google recognizing or apologizing for a bad bunch of patches, nor anecdotal evidence of any serious problems.

One could make the argument that staggering patches out over a few days could possibly be reasonable in order to detect flawed patches and to reduce traffic load.  But leaving customers unpatched for weeks is unreasonable, unnecessary, and not an effective policy from an information security standpoint.

In conclusion, based on the statements above, and your statement that Google has not rolled out the security patches to your device, my conclusion is that Google, by not delivering security patches to all affected Google Nexus 6P customers, is making a poor decision and is doing a disservice to their customers.


I am starting to study Information Security. Why do I need to use a linux distro other than Windows OS?

The only person who knows the real answer is your course instructor, so any answer to this is going to be opinion.
Market Share
According to wikepedia, combined total of all devices in the world:

Device shipments, 2015
Android   54.16%
iOS/macOS 12.37%
Windows 11.79%
Other 21.66%
* OS Device Shipments, Gartner[20]

Assuming that's representative of devices shipped since 2015, then 11.8% of the devices in the world are running Windows, wile the other 88% are running some sort of linux or unix. Remember that this isn't just computers, but phones, servers, routers, wifi-enabled toothbrushes and bathroom scales, etc. Those are all things that require security.
For servers it's even more dramatic (from the same wikipedia page)

W3Cook survey, May 2015
Linux Servers:    96.6%
Windows Servers: 1.7%
* W3Cook checks the top one million web servers monthly, taken from the Alexa ranking, using HTTP headers, DNS records, and WHOIS data, among other sources.

You can't protect what you don't know
From the way you word your question, I'm guessing you have only been exposed to Windows in your life.
Being able to protect something requires having deep knowledge of how that thing works. How could you hope to have a successful career in security if you're only familiar with 11.8% (or 1.7%) of the technology being used?
Since the internet fundamentally runs on Linux, good for your instructor for introducing you to something new.


To keep attacks out of a secure network, limit the ways they could break-in. For example, don't put a WiFi router on the secure network because anyone can connect to it even from outside your house. Also if the devices on either network don't need to talk to each other, create a firewall that restricts that traffic.
If you're creating VLANs on the router, make sure that you can't access the admin interface over WiFi. Anyone can just hack your wifi signal and login to the admin interface, and undo all of the security, and jump between VLANs. Look into VLAN hopping if you're creating VLANs on the same switch.
https://en.wikipedia.org/wiki/VLAN_hopping
All smartphones should be put on an untrusted network because any device that you walk around with every day in unknown environments can never be trusted. If you need to access something on the secure network from your phone, create a firewall rule if your router supports it.
I would recommend installing a dedicated router like pfSense or OPNSense on an old PC and use that as a router instead of a WiFi/router combo. Then put your WiFi router in bridge mode (which means it gives out IPs from pfSense and assigns them to the devices on WiFi).
IP cameras should also go on the untrusted network and shouldn't have internet access or access to any other device on your network. A firewall rule should take care of that easily.
https://www.forbes.com/sites/zakdoffman/2019/08/03/update-now-warning-as-eavesdropping-risk-hits-millions-of-chinese-made-cameras/?sh=1930561d6bf2
Make sure your router is secure by ensuring your Wifi network has a strong password. And installing the latest firmware (should be on the manufactures website). Don't buy routers from companies you've never heard of, however, even routers from reputable companies can also be plagued with security vulnerabilities.
https://www.fortinet.com/blog/threat-research/fortiguard-labs-discovers-vulnerability-in-asus-router
https://nakedsecurity.sophos.com/2020/07/24/asus-routers-could-be-reflashed-with-malware-patch-now/
To regulate who has access to the network, most routers have a feature where you have the router only give out IP addresses to devices that you have whitelisted. That way if someone were to plug in an untrusted device, it wouldn't get an IP and couldn't connect to the internet.
https://helpdeskgeek.com/networking/how-to-whitelist-specific-devices-on-your-home-network-to-stop-hackers/
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html#mac-address-control
Here's a diagram of what I was talking about above.


Is there any advantage to splitting a password?

Splitting the password is a weakness, not an advantage. It allows breaking each password half independently. Beginning with ASCII characters (codes from 32 to 126, inclusive), then removing the lowercase letters, you end up with 127-32-26 = 69 possible characters in the password alphabet. This leads to 697 possible halves, which is somewhat below 243. In other words, this is highly tractable through brute force. You do not even need a dictionary.

This is not security through obscurity. This is insecurity through incompetence.

Edit: "highly tractable with brute force" also opens the road for various optimizations. Note that LanMan is not salted, thus precomputed tables can be efficient (you pay the cost of table building once, then you attack several half-passwords -- it is actually worth it even for a single password, since one password is two half-passwords). In 2003, Philippe Oechslin published an improved time-memory trade-off (it is the article in which he coined the term "rainbow table") and computed tables for cracking LanMan passwords. He restricted himself to alphanumeric passwords (letters and digits, but no special signs), thus a space of 237. The cumulative size of the tables would then be 1.4 GB, with cracking efficiency of 99.9%, and attack time under one minute.

With a 243 space, i.e. 64 times larger, table size and attack time both rise by a factor 16 (that's 642/3), so we are talking about 23 GB or so (that's not much for today's disks) and a 15-minute attack. Actually, the attack would be faster than that, because the bottleneck is lookups on the hard-disk, and the smart attacker will use a SSD which can do lookups 50 times faster than a mechanical hard-disk (a 32 GB SSD costs less than 70$...). The table-building effort (a one-time expenditure) could take a few weeks on a single PC, or a few days on any decent cloud, so it is rather cheap.

Apparently, such tables already exist...


VMware server 4.1 -how can I prevent VMs being exposed to each other through VMCI?

ESX/ESXi 4.0 to ESXi 5.0 provide .vmx options for VMCI isolation. As of ESXi 5.1, these options have no effect.

[vmci0.unrestricted = FALSE|TRUE]

When its vmci.unrestricted option was set TRUE, a virtual machine could communicate with all host endpoints and other virtual machines that had vmci0.unrestricted set TRUE.

[vmci0.domain = ]

(ESX/ESXi only) All virtual machines and host applications were members of the default domain ("") null string, by default.
If the vmci0.domain option specified a non-default domain, then the virtual machine could communicate only with the hypervisor and other virtual machines in the same domain. This was to organize virtual machines into groups that could communicate with each other.

As of ESXi 5.1, or earlier when configured for restricted communication, the VMCI device has a security profile similar to any other device such as keyboard, video monitor, mouse, or motherboard.
Guest communications depend on the VMCI applications running on the host.
VMCI in itself does not expose any guest information.


Is Android anti-virus software necessary and helpful?

According to the Android security chief you don't need a anti-malware or anti-virus applications on your device.

Applications on Android are sandboxed, so it is much more safe. You don't have to worry about anything if you are installing apps only from the Google Play store and update them. If there are any suspicious apps, people get to notify it and the Play store removes it.

Play store had removed 700,000 malicious Android apps found in Google Play store last year

In most cases when you install an anti-virus or anti-malware, your phone gets another process to run throughout the day consuming your processor, memory and battery.

If you keep away from rooted device, third party applications, fake download links, and phishing websites your device will be safe.

Some anti-virus applications helps you filter out the phishing sites and spam messages, which is great but at the cost of performance and battery life.

Pi-Hole is a good choice. There are some applications for Android devices which block the ads too. What I personally use requires a rooted device and I would not recommend doing that. It filters out most of the adds which pop up while using the applications or while browsing.


As I'm aware Google Chrome just provides "security" when you download a file.

So answering your question, unless you actually download the file I don't think that Google will check for virus in that specific file.

But Google does offer security in a way that prevents scripts that can send information to the server, so it may just do that.


How to search for all computers running memcached on shodan

Shodan sends the STATS command and that information can be seen in the Memcached banner and metadata:

https://www.shodan.io/search?query=product%3Amemcached

You can use that information to see the number of stored items though we don't allow filtering by that information via the API/ website so you need to download the search results to process it locally.


How to deny execution of any file on a specific directory?

If you want to make sure that the files are not executed, then the best way is to not let users access the files directly.

"But how do you download them if you cant access them?" you might ask. Answer is that you provide a public facing download script that fetches the local file and presents it as a forced download to the user.

You can look at this to see how that can be accomplished.


I need to transfer user's private key (RSA) to my App. Is file sharing a good solution?

I presume that you're having the user generate an RSA keypair. If that's so, you simply need to stash it somewhere that, ideally, no other applications are permitted to look.

As you said, apps can't access other apps' document directories. However, the Apple File System Programming Guide advises you to put data the user shouldn't access in the Library directory (most likely as an Application Support file). It doesn't specifically address what to do with sensitive data, though, so you may want to dig a little deeper into these documents.

Of course, this won't stop users from getting at the private key if they really want to. You can probably use file permissions to keep the private key from being exposed by a casual search, though.

I'm not sure what file sharing would do for you here - unless you're having the server generate the keypair, perhaps?

Also, are you sure that you can't use Keychain? This Apple support document says that you can set it up with Mavericks 10.9 or iOS 7.0.3

If that's the case, then it's the best option available.


How to prevent from DNS spoofing in Java code which obtains a name of localhost

While static code analysis can improve security, it is wise to take the context into consideration. Same thing is done with vulnerability analysis reports.
In your code as written, there is no sensitive details being sent to the server (localhost in this case). So there is something else throwing the issue, and you may want to detail that.
What the analysis report is likely trying to tell you is:

verify the server through some other means before sending credentials.

This can be done with certificate pinning, which embeds a certificate chain or thumbprint into the program. Java has a built-in "keystore" functionality for this purpose.
There are libraries in many different languages that do DNS (like this one for Java), but suggesting a check on "both the forward and the reverse DNS entries" seems awkward and futile.
Again context matters as with DNS and certificate pinning, there are ways around it.
If you start with "What's the actual risk to the program I'm writing?", better answers can come about.


Authentication concept for sites served to another site

This proposed design does not take replay attacks into consideration.   In the first scenario the "hash" is now the password, and therefore this hash (and the information used to create this hash),  must be protected in the database and during transmission.

What you are trying to do is not new or unique.  When you build something from scratch there are problems with design, implementation and compatibility with other systems.   To avoid all of these pitfalls you should implement an RFC'ed standard such as 3-legged oauth:


For a hash to be collision free, each unique input would need to map to a unique output. If each output is unique, that means it can be reverse-mapped to a unique input. That would not be hashing, that would just be an encoding. Collision-free and non-reversibility are mutually exclusive by definition.

The important point is how likely a collision is, and the answer for modern hashes is negligibly unlikely. If the output key space is larger than the input key space, you're extremely unlikely to ever find a collision, and even if it's not it's still so unlikely as to not be worth considering in the real world.

I would guess though that those smart card ids aren't very complex, likely decimal numbers all of the same length (e.g. 1234567890). That means there aren't that many possible inputs and it's probably possible to calculate the hashes of all possible ids in a feasible amount of time, creating a lookup table to reverse the hashes. If that's the case, you'll want to be using a slow hash like bcrypt, scrypt, PBKDF2 etc. to make this infeasible.

The more I think about it the less the requirement makes sense. The secret here should be between the card and the reader, and the trust needs to be between the reader and the system it's connected to. Why is it a security problem if the id of a card is known? What can somebody do with this id if he obtains it? If the answer is that the id is a secret and somebody can do whatever he wants if he knows the id number, that's poor security. The security here should come from the fact that one needs to have physical possession of the card, which means the secrets are all between the card and the reader. Beyond that there's only an authenticated user with an id, which is a simple necessity to make the system work.


I'm using a Cisco ASA as a VPN endpoint. Where do the VPN clients get firewalled?

Here's how to do it: tunnel_vpn_userX controls what subnets to tunnel, filter_vpn_userX  applies normal access list filtering within that tunnel.

object-group network tunnel_vpn_userX_local
 network-object <some local network>
 ...

access-list tunnel_vpn_userX extended permit ip object-group tunnel_vpn_userX_local any
access-list filter_vpn_userX extended permit tcp any <some local address> eq www

username userX password ...
username userX attributes
 vpn-group-policy userX
 vpn-tunnel-protocol IPSec
 service-type remote-access

group-policy userX internal
group-policy userX attributes
 vpn-filter value filter_vpn_userX
 vpn-tunnel-protocol IPSec
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value tunnel_vpn_userX

Hope I didn't miss anything...


CORS headers are only honored by supported User Agents (UA from now on). The responsibility of a web developer is to set the appropriate CORS headers for every response, and it will be the responsibility of the UA to enforce such headers and block the access if the headers are going to be violated.

Any request made by the UA will fall in only 1 of 2 categories regarding CORS:

Basic requests that don't require any special treatment
More complex requests that require some special treatment

The process that decides in what category a request ends up depends only on the http request (if it has a payload, the http method, cookies, other headers...) and is decided by the UA and written in the RFC.

If the original request requires some special treatment, then the UA will perform 1 more request before the original http request, that second request has an OPTIONS method to the same URI of the original http request and is only done to get the CORS headers that will apply to the original request in order to make the decision to allow or deny the original request.

Now regarding your questions:

  However, for a POST request, for instance, if the origin is not allowed, should the request be blocked or is already too late at that point?

Since a POST requests is always a request that requires special treatment, it will get denied after the OPTIONS request (also called preflight request) is done if the CORS headers deny the request.

  It is possible that a server does the request, so CORS does not apply at all and no origin is set so it cannot be done.

Yes, if a server is doing a CORS request, then it's his responsibility to honor it since it has become the UA of that http request.

  So, this only truly applies to browsers (as far as I know).

Kind of correct, it applies to any UA that honors CORS headers, and that is usually a browser, but doesn't have to be per se.

  So, perhaps when this happens the browser is already so far gone that this is already too late.

This can never happen for special treatment requests, since a browser that supports CORS will only make a request once the preflight request has allowed him to do so.


Upload data from Internet to DMZ to an intranet

You should give consideration to converting the document from its native format.  Convert JPG to PNG, say, and Word to PDF.  It's a catch-all attempt to try and remove any document-specific malware.  The advantage is that it might protect against unknown and future threats.  The disadvantage is that it might mess with formatting or lose content.  The level of effort you go to here is determined by the risks.

Advancing the idea, you could keep a native copy around so that in the case of it being damaged in the conversion process, you can recover the original, and make the risk-based decision to use that.  For the truly paranoid, encrypt the native file with the public key of a key pair, where the private key is only available on a specific hardened standalone non-persistent machine.  Use that machine alone for viewing the native documents.

Still more: the document conversion process needs to be on a "trusted" machine.  Ideally don't do it on the Internet-facing web server, nor on the internal server; so it should be done in the DMZ.

Your data should be pulled from the Internet into the DMZ by the DMZ, and then pulled from the DMZ into the internal network, by the internal network.  It's just a good principle, and otherwise might require more firewall rules than you otherwise need.

I'd look at rsync-over-ssh as a battle-tested one-way sync method with mutual authentication.  Run it regularly, and you don't have to worry about signalling the DMZ to come and collect files (might not be enough if you must process these files quickly, though)

Of course, this may well be too much effort to manage your risk.


Is there some form of encryption built into it?

Yes, 3G has encryption. It usually is strong enough for attacks based on observation alone.

  is that secured or easily hackable?

Sigh. Could we move away from using words like "hackable" or "I've been hacked" in general? They're super non-descriptive.

If "hacking" means cracking the cipher used to encrypt the over-the-air data, no, that's pretty hard and I don't know whether that is done anywhere. That is, assuming that in a post-2010 world, operators have learned to use the right ciphers and periodically exchange keys.

If "hacking" means swindling and imposing as a legit base station to capture the traffic of a telephone, maybe with or without cooperation of the network operator: That's a lot easier.

If "hacking" includes your computer, to which you connect your modem: Well, you might have noticed that there's thousands of new malwares every month. There's certainly some security holes in your system. And that might be used to gain access to your data, regardless of encryption.


White hat hacker asks for account to do penetration tests

The person who contacted you was most certainly not a "white-hat hacker". This is not how they operate. The person is most likely trying to scam you in the simplest possible way.

What is a White-Hat Hacker?

In the simplest terms, a White-Hat Hacker (henceforth called "White-Hat") is a security professional hired by a company, group or individual (henceforth called "customer") to test a system owned by said customer.

The White-Hat and the customer agree on a scope of the test, the timeframe, how vulnerabilities should be reported, user accounts for systems to be tested and similar agreements. This is usually referred to as a "Permission to Attack" and is the legal basis of the work of a White-Hat.

Then the White-Hat proceeds to do their work, writes a report and makes suggestions to the customer on how to improve the security of their system.

Simplified, a White-Hat is a Hacker you hire to test your systems.

What is a Black-Hat Hacker?

A Black-Hat Hacker (henceforth called "Black-Hat") does not have an aforementioned "Permission to Attack" and tries to find vulnerabilities wherever they can. Since their "work" is not backed by any legal grounds, they don't need to worry about playing by the rules, collateral damage, etc.

Black-Hats can have various motivations. The overwhelming majority does it for monetary gain, although others can be in it "for teh lulz", for political reasons or for their own personal convictions.

Simplified, a Black-Hat Hacker is a Hacker that tries to exploit vulnerabilities without any legal basis to do so.

I've been contacted by a person claiming to be a White-Hat regarding a vulnerability. Is it a scam?

Not necessarily. Some products or programs reside "offline" and are thus owned by the White-Hat Hacker. I don't need permission of a lock manufacturer to pick a bike lock that I bought from them. (I do however need permission of the owned of that individual lock!) If I found a design flaw in said lock, I can contact the manufacturer and inform them of said vulnerability.

Similarly, I could buy a product and analyze it. If I found a vulnerability, then contacting the vendor through a responsible disclosure procedure would be the only ethical thing to do.

However, in such cases it always has to be asked "Who's system was attacked?". In case of the bike lock, it is clear. I owned the lock, hence I can attack it. With software, especially cloud-based applications, the issue of ownership becomes much more complicated.

I stick to the rule "When in doubt, call an expert!" and in this case an expert would be a lawyer.

To summarize the question, "It's not always a scam and could be an attempt at responsible disclosure. Proceed carefully."


/WEB-INF/web.xml showing MySQL credentials?

Could it?  Yes.

Is it?  That's less certain.  If your MySQL server is configured properly, it isn't accessible from the Internet at large, and the credentials are useless to anyone who doesn't have the ability to run code on the server.

Of course, this assumes that the username and password are unique to the server.


Can Self extracting rar file (SFX) be used to automatically install malicious software?

As SFX are executable program files they can at least be infected by a malware/virus/trojan, like any other program. Such malwares can be used to install malicious software, directly or indirectly (by dowloading something, for example).

I don't know whether there are specific exploits tied to SFX though. The above is general to executable files. The only SFX vulnerability I found so far is this one, which doesn't prove there is no more harmful one.

Reading this link from RARLab.com can be interesting for more details: http://www.rarlab.com/vuln_sfx_html.htm

Also, when you wish to unpack a SFX, nothing prevents you from opening it with WinRAR instead of executing it as a program. This way the unpacking executable part of the archive won't be executed. This is just a first level of protection though as once again I'm not sure whether SFX-specific exploits exist.

Regarding the detection of such malwares, it is all up to your antivirus. Basically, they won't be detectable at the very beginning ("the first day") but will probably be after the next "malware definition files" update of your antivirus. (More about that in this other answer: https://security.stackexchange.com/a/140450/126594)


Two numbers are needed because there is a many-to-one relationship between TCP streams (with separate TCP sequence numbers) and an IPsec tunnel (with its own sequence.)

Imagine a host with an IPsec VPN. It has two programs using the network: a web browser and a mail client. If there were only one sequence number, then either they would have to take turns making TCP connections through the tunnel, or they would each need a separately-configured IPsec tunnel for each TCP stream they establish.

The existing architecture ensures that multiple TCP, UDP, and other IP protocols can be multiplexed through a single IPsec tunnel.


Is there an IDS based on process patterns?

Whitelisting is considered good practice. Blacklisting is known to always be an "after the facts method" which leaves your system vulnerable. A bit of a linux admin can setup SELinux or Apparmor. There are a lot of docs and tutorials available about it. They are not extremely complex imo, you just need to be willing to learn it.

There are HIDS available like OSSEC that allow you to implement such rules (with some additional scripting). I use it on all my Linux machines as well, but it doesn't replace apparmor or SELinux even remotely.

It may sound a bit rude, but if you want security, you can't be lazy.


Non-Repudiation that can Never be Proven

Non-repudiation is not done with public keys; non-repudiation is done with a legal framework which defines responsibilities and duties. Though details depend on the jurisdiction, most will more or less follow the following scheme:

A signature that you perform is binding as long as you did it. That's the definition. The rest is about what happens in case of litigation, and you claim that you did NOT do it.
An electronic signature is one that is made with some mechanism where electrons are involved, but not ink on paper.
Local laws usually shift the burden of proof. If you simply write your name at the end of an email, then that is legally a binding signature, but in case of litigation, it is up to your adversary to demonstrate that you really signed the email. That is, a name at the end of an email will effectively bind you only if it can be positively proven that you wrote that email as it is. That proof can take a lot of forms; e.g., it could be a witness, who saw you write that email.
Local laws may recognize the existence of strong signature systems where the burden of proof is reversed: the signature system is deemed robust by default; if you want to repudiate your signature (i.e. if you claim that you did not do it), then you have to do the work and find proof of framing/hacking/whatever (e.g. you find a witness who saw you hiking in Greenland, far from any network connection, at the time the signature was purportedly generated).
Local law systems will usually grant the "strong" status to a signature system only after a complex assessment process of the inner workings of the said signature systems. This will involve a lot of paper and certifications and hordes of auditors, and it will be expensive. Most local law systems will require that alleged strong signature systems use asymmetric cryptography with public keys and so on (this is a prerequisite, but not sufficient in itself to achieve the "strong signature" legal status). This is where cryptography matters: it is a tool which may help achieve a given goal within a given legal framework.
In any case, it would be inordinately optimistic to assume that "access to the logs" would reliably settle the question of whether hacking occurred or did not occur. Logs can be erased; logs can be faked.


Corrupt password being pulled from wireshark data?

What does the hex dump say? In general, 8-bit and non-printables are printed as '.' by most viewers. Pretty much like this (just on a Linux prompt though):

$ echo H€llo | hd
00000000  48 e2 82 ac 6c 6c 6f 0a                           |H...llo.|
00000008

And here is an example of how to decode the hex:

$ perl -ne 'chomp; s/ //g; print pack("H".length, $_)' <<< "48 e2 82 ac 6c 6c 6f 0a"
H€llo

You might also need to figure out what encoding was used and convert it to whatever your teminal is using.


Does using the same encryption algorithm multiple times make a difference?

Yes, it makes a difference. It makes your system more risky.

In answering this question, I'm going to assume that you're implementing an AES-AES cascade using a sensible mode of operation (e.g. CBC or GCM) and with independent keys.

The benefit you seem to be proposing is that you could prevent brute-force attacks by using multiple layers. The problem is that, if an adversary has any chance of breaking a 128-bit key, then having to break three of them makes almost zero difference to them. You're talking about the difference between 2128 and 2129.58 operations. Considering that the limits of computation put the costs involved with cracking a 128-bit key somewhere in the region of 1/100th of all of the power ever produced by man, that little bit extra barely matters.

The only benefit that an AES-AES cascade would bring is that many classes of attack against block ciphers are made more difficult. For example, chosen plaintext attacks rely upon getting a system to encrypt attacker-selected plaintexts, and usually involve comparing the resulting ciphertexts. However, with AES-AES cascades, you can't possibly select the input to the second cipher.

There's a problem, though. Remember when I said I'd assume you'd made sane decisions? That's where things start to fall apart. By increasing the complexity of your system, you increase the number of security decisions you have to make, and increase the potential for security failures and bugs. Do you perform two sequential AES block transforms for each block process in CBC, or do you encrypt everything with AES-CBC and then encrypt it all again? Have you used two separate IVs? Are you selecting IVs independently? Are you selecting keys independently? How are you applying and checking authenticity? How are you going to safely exchange, store, or derive the keys and IVs in your protocol? Are all of your implementations strong against side-channel attacks such as DPA and timing attacks? That's a lot of questions to get right, and a lot of potential areas for failure.

Finally, I'd like to remind you of the purpose of cascades: to ensure that a weakness in one cipher doesn't result in a loss of confidentiality of data. By correctly implementing a cascade of, say, AES-Serpent, you ensure that both AES and Serpent need to be broken before the data is compromised.


Prompt for PIN when installing Android Apps?

The core of your question seems to be:

  If I lose my phone, can I prevent the attackers with physical access from installing apps through the apps store?

The hidden assumption here is that you don't mind if they get into your device and root around in the apps / data that are already there, but you really don't want them installing new apps. Well, they're into your device, presumably they have access to your SMS, email, and 2FA code generator app so they are you; they can more or less reset any passwords they want.

This is an oddly specific request, so I think the standard advice applies:

Use a strong password so they can't get onto the device at all.
If you know you've lost the device, use Android's remote lock / erase functionality (yes, this requires both you and the device to have internet connectivity).

As for

  Can you trust Android lockscreen if you use fingerprint sensor or is there mostly a way around it?

I typed "fingerprint unlock spoof" into Google and got a list of articles like this and this which tell me how to lift fingerprints off the device screen and create a fake fingerprint that will unlock the device. The process takes 15 - 30 minutes if you know what you're doing. So yeah, fingerprint unlock is fine for keeping your kid sister from reading your texts, but don't mistake it for real security.

Addressing comment:

  I'm very curious why fingerprint is less secure then a password.

Two reasons:

You don't leave a copy of your password on every glass, table, doorknob, iPhone that you touch.
If your password gets cracked, you can change it. Fingerprint not so much.


Is it possible for someone to make a purposefully vulnerable site then take advantage of that vulnerability to hack the users?

Is it possible for someone to make a purposefully vulnerable site

Yes.

then take advantage of that vulnerability to hack the users?

Yes but, he doesn't need the vulnerability.
When we talk about a vulnerable site, that usually means it allows anyone to do some action which was not intended by the owner. For example, a vulnerable StackOverflow site could allow anyone to log in under the account of someone else. However, if I was the owner of StackOverflow and wanted to take over your account I wouldn't need to exploit a vulnerability on the page. I could do that directly (such as manually changing your password to something else).
The main reason I can think for that would be for plausible deniability / looking inept rather than malicious.


Explain the concept of RBAC to limit the right of senior staff

RBAC cannot directly stop a user from doing something evil if the user must be able to do an action with the potential for evil as part of the his job function.  For example, if the senior staff member does have the need to move around money with junior staff budgets because he fixes allocations between the junior staff members - then he could very likely as easily move the money to benefit himself in some nefarious way, since moving money is a pretty powerful tool.

Common forms of protection that DO use RBAC are a bit more subtle than just "don't let him do it".

Solution 1 - 2 Man Control

One solution that can work is to separate the work up into duties so that several people would have to conspire to commit fraud.  For example, give Sr. Executive the right to move money, but not create accounts.  Make account creation w/in the purview of a different team or a bigger boss who can't also move money.  Now the Sr. Staff can move money, but not to a personal account.

Solution 2 - Approval Required

Another similar approach would be to require approval of transactions.  Sometimes there's a dedicated group of approvers who can't also initiate the transaction.  And other times it's just that another person w. the same privilege is required to peer review the work.

Solution 3 - Job Rotation

Make the senior staff take a vacation every year. During that time, remove the role from his account and put it on someone else's (his alternate) - let his alternate get access to EVERYTHING (including logs), and let the person do a review of the senior staff's behavior.

Solution 4 - Auditing

Create a separate role of auditors who see the history of all transactions.  Make them review the senior's actions and make sure nothing inappropriate happens.

Make sure that senior does not have write/delete access to these audit logs, so he can't change them.  Put business logic in place to make sure that the audit role cannot be connected to any other role with change access in the system.

Those are the classics.

1 & 2 prevent the misuse of privileges.

3 & 4 track whether misuse ever occurs, the deterrent becomes the severity of the penalty


Client/server communication keystore and tls

Certificates are used to prove the authenticity of a given computer. TLS is just used to encrypt the data.

If you want to prove the authenticity of the Server(which you want to, atleast in most cases) then create and use a Certificate for the Server, this requires that each client connecting to the server should somehow be able to verify the Certificate of the server.

If you want to verify the authenticity of each of the clients, then you need to create a unique certificate for each client and then verify the certificates of each client in the server.

A keystore is just a list of Certificates that are used to verify a given certificate. for instance a client will use a keystore to verify the certificate of the server.

This Thread explains how the Certificates are Verified.


Should I (care to) install security updates if I run on VirtualBox

As you said, you're virtual machine is connecting to the internet. If you're using an outdated package with security vulnerabilities, your guest OS can get compromised. (How depends on the security vulnerability and the usage of the virtual machine.)

If an attacker has access to your virtual machine, he can try to break out of the virtual machine to get access on the host system, even if the host system is fully patched. An attacker with code execution on an system in your environment is always bad, even if it's an unimportant part of your environment.

If he is on the virtual machine, he has very likely access to your local network and can attack all systems that are accessible from your system.

Another possible way could be a shared directory of the host system which is accessible from the virtual machine.

Even if the other two things are not possible and he could try an attack like the row hammer exploit to break out to the host system.


If passive MITM is sufficient you don't need to reroute anything. What you are looking for is a so called "lan tap". There are plenty of hardware tools on the market but you will be able to construct one yourself quite easily. It only consists of several ethernet ports and maybe some capacitors. You will only need those in case you want to sniff a 1G line with a 100M ethernet port.

There is a lan tap on the market by Michael Ossmann here which I recommend looking at because he seems to be a great guy with lots of nice ideas.

Anyways you can easily build one yourself like e.g. in this tutorial. You can then put it between the WAN side and your uplink and happy sniffing ;)


For this question, I am going to assume that the windows event service is running on the same machine that is being attacked.

Yes, an attacker could tamper with audit logs to hide their tracks if they gained control of the machine.

Typically, this is mitigated by forwarding logs to a centralised logging service. This has two benefits:

It makes log tampering much more difficult, and;
Events from across the network and be correlated and queried.

If you have a good logging and monitoring strategy in place, this should allow you to detect, respond and recover much more quickly, limiting the severity of the security incident.

Strong access management can also help to reduce the risk of an unauthorised individual modifying logs. Write permissions should be limited, and manual changes to the logs should generate security alerts.