How well do current browsers handle certificate revocation?

Not very well.

In theory, the system should work. In practice, it doesn't. The implementations intended to manage revocation - namely CRL and OCSP - both have problems. Most of this answer is based on this article by Alexey Samoshkin, as well as this article by Scott Helme.

What about CRLs?

A certificate revocation list is a remarkably simple way of determining if a certificate is valid or not. It is in essence a list of all certificates that have been revoked. If you would like to check if a certificate has been revoked, you need to check the associated revocation list.

This list is potentially very large, slow to download and requires you to be online in order to be able to verify the validity of a certificate. While the online requirement seems like a non-issue for browsers, there are more uses for certificates than to authenticate a web-server, which may indeed be offline.

In practice, CRLs are considered an outdated mechanism that deliver far too much overhead and are infeasible to do in practice.

What about OCSP?

OCSP was designed to be the golden goose that solves all the problems with CRLs. In practice, it introduced a set of new problems.

Increased latency due to the need to make an inline request to the OCSP endpoint.
Dependency of OCSP endpoint availability.
Privacy compromise to the CA, since you need to transmit for which certificate (and thus which domains) you would like to have OCSP information.

What about failures?

What happens if a CRL or OCSP endpoint is not available? Turns out, nothing. If the status of the certificate can't be validated, browsers default to considering them legitimate. This means an attacker that can successfully get my browser to "give up" on trying to get OCSP data (e.g. by dropping all packets intended to go to an OCSP endpoint), even revoked certificates are considered valid.

Will we ever fix revocation or should we just give up?

There are attempts to mitigate these problems. Chrome uses CRLSet, and Mozilla uses OneCRL. The idea is basically that my browser contains a list of all CRLs and periodically (e.g. once per day) updates them.

Another attempt made is OCSP Stapling, which shifts the burden of proof to the server again. The idea is that the server periodically asks the CA if the certificate is still valid, and then gets a timed response, which the server includes with the certificate.

This fixes several of the above mentioned problems:

The certificate and its revocation status are sent in one transmission, reducing latency.
The CA does not get information about which domains are requested by the user.
The OCSP endpoint of the CA can have reduced availability, since messages are valid for some time.
The OCSP endpoint has a lower load, since it is distributed more among web servers.

So where is the catch?

I mentioned that the current status of certificate revocation is bad, so obviously there must be a catch. Turns out that web servers aren't really that good at implementing OCSP stapling. I won't go into all the details, since Alexey's article does a fine job at explaining it. The basic gist is that even if enabled, some servers may not immediately send out stapled responses. Some servers, like nginx, don't send a response if the certificate has been revoked. This means even if the web server knows the certificate is revoked, it will not tell the user because...reasons?

What about must-staple?

Glad you asked! The idea is simple, the certificate includes a flag that indicates that a server must staple an OCSP response, or otherwise verification will fail. Sounds good in theory, so where is the catch?

The catch is that browsers react weirdly to this flag. Firefox throws MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING, which only somewhat makes kind of sense when you already know what it's supposed to mean - only slightly better than throwing us a T_PAAMAYIM_NEKUDOTAYIM. Chrome, on the other hand, doesn't care at all. Chrome doesn't support OCSP at all, so it's only logical that an extension that requires it is just being ignored.

In conclusion, certificate revocation is broken and there is very little each of us can do to fix it.


How does exploit development work for penetration testers?

The change of addresses on every boot is called Address Space Layout Randomization (ASLR). Together with Data Execution Prevention (DEP), ASLR is one of the most effective security control against memory corruption exploits. Read the excellent answers at How Do DEP and ASLR Works. However, when buffer overflow exploits are created which targets anything above Windows XP (practically everything nowadays), then ASLR is bypassed using a few techniques. The most common one is to transfer the code execution to a non-ASLR enabled module that is loaded at fixed or predicted address. Majority of the IE exploits that target IE8 and IE9 uses one of the two modules (MSVCR71.dll and HXDS.dll) since both of these are non-ASLR and are loaded in the IE process (either by default or can be triggered easily).

Most of the flash exploits uses a technique where length of the vector array is overwritten and more data is read than intended. When the attacker is able to read arbitrary length data inside the exploited process memory, it can be used to find addresses of common DLLs from which ROP gadgets could be constructed. You can find further details in the excellent paper from Haifei Lei here. If you want to read some code that is able to bypass ASLR, take a look at the exploit code used by Metasploit here.

In short, ASLR together with DEP is an excellent mitigation. However, techniques are there to bypass it in certain cases for reliable exploitation.


What's the safest way to enter information on a website?

On-screen keyboards are not a solution as any key logger may even capture screenshots, which defeats even randomized on-screen keyboards. (source)

  The bottom line is simply this: you should never assume there's a way
  to bypass keystroke loggers. They could easily be more sophisticated
  than your attempts to work around them.

  By far the only sure way to deal with keystroke loggers is simply not
  allow your machine to be compromised in the first place.
  (source)

Probably one of the best ways to protect yourself is to be sure that whatever you are running is free from loggers. For example, you could use a live DVD (easy and cheap).

There is an upcoming "kickstarter" product that seems to simplify that process by embedding a micro board inside a keyboard, which can be booted instead the current OS or in a container inside the current OS:

  SilentKeys is a Plug'n'Play USB keyboard that
  protects you both off-line and on-line. Keep control over your privacy
  and safeguard your computer from viruses, snooping and hackers.
  Protect your keystrokes from key-loggers. Go anonymous at the push of
  a button. Encrypt your data and safeguard access to Paypal, Facebook,
  bank as well as all your on-line accounts and credentials.

https://www.kickstarter.com/projects/preevio/silentkeys-a-keyboard-that-protects-your-privacy-a

I'm still not familiar enough with that project so I can not recommend it nor explain more details about it. I just thought its interesting (I'm not in any way related to that project).

NOTE: My answer is based on the idea that you are looking for a solution in which you can't trust the computer which you are using (like in a public place). If you are talking about your own personal computer, then I would strongly suggest you to use Linux and install tripwire. That piece of software will notify you if any of your OS files is modified in any way. It may not be 100% effective against in-memory key-loggers but it gives you a greater knowledge over what is being modified in your system without your consent.

Update (2019)

Some years have passed and re-reading my answer, I feel that I'm missing some important points:

There are software and hardware keyloggers. Software keyloggers can be deployed remotely to any device (not just public computers), so your best protection (which is not 100% safe) is to keep your devices updated, validate downloads checksum, do not install anything that you don't know, avoid using devices or connecting into networks that you don't own or you don't trust, etc.

If your device has an infected BIOS, and if we assume that the malware is able to "see" everything you input, none of the methods suggested in this answer would keep you safe.

Now, about hardware keyloggers, those are more difficult to deploy. Even the "DVD" method won't protect you if the keyboard has been tampered. If we go deeper into hardware, we can talk about the possibility of using malicious chips which could potentially steal information.

Bottom-line: Hackers get more creative with the years so the best thing is always assume you may be hacked and your passwords stolen. Have a backup plan and don't keep everything in the cloud.


Why are MD5 and SHA-1 still used for checksums and certificates if they are called broken?

SHA-1 and MD5 are broken in the sense that they are vulnerable to collision attacks. That is, it has become (or, for SHA-1, will soon become) realistic to find two strings that have the same hash.

As explained here, collision attacks do not directly affect passwords or file integrity because those fall under the preimage and second preimage case, respectively.

However, MD5 and SHA-1 are still less computationally expensive. Passwords hashed with these algorithms are easier to crack than the stronger algorithms that currently exist. Although not specifically broken, using stronger algorithms is advisable.

In the case of certificates, signatures state that a hash of a particular certificate is valid for a particular website. But, if you can craft a second certificate with that hash, you can impersonate other websites. In the case of MD5, this has already happened, and browsers will be phasing out SHA-1 soon as a preventative measure (source).

File integrity checking is often intended to ensure that a file was downloaded correctly. But, if it is being used to verify that the file was not maliciously tampered with, you should consider an algorithm that is more resilient to collisions (see also: chosen-prefix attacks).


Can I protect against keylogging by using the mouse?

A lot of keyloggers are smart enough to catch this. Not only do they log the keys being physically pressed, but they also log the contents of password boxes whenever window messages are processed, or when browser forms are posted. They also often capture small blocks of the screen around the mouse cursor, to catch cases like this.


As long as you have the certificate key pair (public and private), any computer can act as identified by the the certificate CN (common name). This is suppose to match the FQDN of your service, or else many browser will fail the authentication on the client side without even checking the signatures.

Provided that you use a reverse proxy (or DNS changes) to switch from production to recovery server, the transition can appear seamless to the client.


The older the Linux kernel is, the more secure?

Two major factors in the likelihood of open vulnerabilities are the frequency of changes, and time to discover vulnerabilities (and develop them into exploits).

While a version under active development is more likely to introduce a new vulnerability... and old version has had more time for attackers to analyze the source and create new exploits. It’s a bit of a balancing act.

Also consider that newer versions may have introduced stronger security barriers that are not present in older versions at all.

And when an vulnerability is found, it’s usually patched first in the latest version and then back-ported to the older versions. So time to fix is usually a bit faster on the new versions (we definitely saw this with Meltdown in Debian, where Debian 9 got a patch almost immediately, and it was weeks before it was back-ported to Debian 8).


Why does WebAuthn require a challenge when asking the client to register a new credential?

I've asked around a lot about this and haven't been able to find a definitive answer. However, I think the challenge is needed for the following reason:

Replay attacks should mostly be prevented by TLS, but as mentioned here and here it is still possible to execute a replay attack even with TLS by fooling the user or the user's browser to retry a request. Thus, this challenge helps cover a gap in TLS's replay prevention mechanisms.

For example, an attacker could compromise a user's identity in the following scenario if the challenge wasn't required:

A user tries registering a new credential.
That request is held by a man in the middle and a TCP reset is sent to the user's browser.
The user's browser retries the request and successfully registers the new credential.
Within a short period of time, the user decides to deregister their credential.
Again within a short period of time, the man in the middle releases the original request to the server and thus, the credential is re-registered without the user's knowledge.
Sometime later, the man in the middle steals the user's FIDO2 authenticator.
The man in the middle can now pose as the user.

Update

After realizing that a replay attack doesn't have to occur as a result of a compromised node in the network but could also occur as a result of a compromised operating system or compromised browser, I thought of the following example that would be possible without a challenge during registration:

An attacker gains control of a user's browser.
A user registers a new credential and the compromised browser intercepts the PublicKeyCredential before sending it to the server.
The attacker steals the user's FIDO2 authenticator.
The user deregisters their credential.
When the user goes to register a new credential, the compromised browser sends the old PublicKeyCredential instead of a new one.
The attacker can now pose as the user.

A very similar scenario could occur if the user's operating system was compromised and a challenge wasn't used during registration.

Also, these scenarios would only be relevant if a relying party required that registration/authentication be executed with a particular device that the attacker couldn't easily crack.


What's the security impact of tampering with Google OAuth continue parameter?

If you use the basic HTML web version of Gmail and have look at the hyperlinks inside the mail, you'll find your answer.

The issue happens because there are many open redirects for Google, since they don't consider this a security vulnerability.


How to define audit controls responsibility? @ SIEM

In the past I performed the function of an auditor. (for legal reasons, I cannot call myself an auditor, but the fundamental function of an auditor is to compare expected behavior with actual behavior, and that's what I did).   @Iszi is correct that different institutions will have different understandings of RACI.  If I were an auditor visiting your facility the first finding would be that your management hasn't described that responsibility matrix. In traditional auditing, one does not hold people responsible where there is no policy. (Modern risk based auditing can operate a bit differently, but I think that's outside the scope of this question).

Based on the evidence presented, I believe you are correct.  The procedural document should describe the procedure for system auditing, including the events to be audited, and the procedure for reviewing the audit logs.    If the goal is merely to comply with an audit regime, that is sufficient.

If the goal is to improve security, reduce the organization's exposure to risk, decrease the number of incidents and decrease the damage done in any individual incident, then your organization needs to go further.  Your system audit procedures are based on assumptions about the assets your protecting, and the threats to that asset.  Threats and assets change more frequently than eventid's.  Your management should have a mechanism to update the audit procedures.  Audit review is not an end; it is a tool to reduce risk, reduce incident frequency and severity.  Management should establish a periodic review of audit activities and to adjust those audit activities to better support the organization's business goals.

(I recognize that I've used the term "audit" in two contexts, and that it could be confusing. I'm assuming that you are writing procedures for capturing and analyzing system event logs (system audit).  This is separate from external audit and review, which might be called independent audit)

As @Iszi says, each organziation will differ, but I believe that in the general case:
System Aministrators/SOC staff are responsible for daily/continuous review of audit logs as described in the procedural document you're writing.

System Owners/System Management is Accountable for the results of audit (generally measured as the time to detect  an incident, the % of incidents detected on internal vs external evidence, and the average time to resolve an incident).   Management is also responsible and accountable for managing the audit process, which includes ensuring that the audit procedures are updated to match business needs.

This gets a little more complicated if we outsource security monitoring to a SOC; the system manager/owner should still be accountable, but they have delegated responsibility.  If I were reviewing such an arrangement, I'd look for an SLA for Security that included the RACI you're looking for.


Can the content of a password protected zip file be known?

Yes. Aside from the fact that the filenames are unencrypted, the contents of a password-protected Zip file can be recovered if it uses the old, insecure ZipCrypto cipher which uses the insecure, non-cryptographic CRC algorithm for data confidentiality. A research paper from 1994 showed that an attack against the underlying encryption can be done in several hours regardless of the strength of the password on a contemporary home PC. Nowadays, such an attack can be completed in seconds with free and publicly available tools. You must not rely on default, legacy Zip encryption.
The PKZip format supports three encryption methods. The first is the legacy, highly-insecure ZipCrypto. The second is AES-based encryption stored in the compression field in the metadata, and the third is AES-based encrypting using its own header format. The encryption specification is online. Using AES-based encryption rather than legacy encryption can result in incompatibilities, especially with older programs, but most modern, well-designed Zip programs can handle it.
In order to protect the contents of a Zip file, you should use strong encryption. Various tools such as WinZip and 7zip support an ad hoc AES-based format for Zip files which additionally encrypts the individual filenames and sizes within the compressed archive.


Storing SAML Idp certificates in APP_Data folder

Which certificate is this? Is it just the public key used to validate the token?

If it's just the public key, then the only thing you need to be worried about is someone overwriting it with a different key.

If you're that concerned with it, you can instead store it in the certificate store, and ACL it such that it require admin permissions to change. The practical issue is that you'd then need to store the thumbprint or subject of the cert somewhere so you can look it up in the store. Storing it in AWS would make it slightly more difficult for someone to mess with it. You'd want to make it readonly from your service so an attacker on the box can't use the same creds to overwrite it.

On the other hand if you're talking about the private key used to decrypt an encrypted token... that's another story. You really need to consider what sort of attacks you're looking to prevent.

You can store it locally on disk and anyone with read access can, well, read the key.
You can store it as a PFX file on disk with a password, but you need the password to decrypt it, and that needs to be stored somewhere securely, and down we go the rabbit hole.
You can ACL the key so only the web app can read it, but odds are it's running as network service, so that's pretty open.
You can switch the app to use a named account with password, and ACL the file so only that user can read the key, but an administrator can still read it, because: admin.
You can store it in the certificate store, but the previous 2 points still apply.
You can store it in AWS, but this requires a key to connect, and that key needs to be stored somewhere securely. Again down the rabbit hole. Additionally, this key needs to be pulled down to be used, which can either be stored on disk or in memory. On disk makes this all moot.
Lastly, you can store it in a proper key container like an HSM (see e.g. Amazon HSM, or Azure Key Vault) where the key never leaves the store, and you send encrypt/decrypt commands to it. At this point you still need a way to connect, but you can't extract they key, though you can send arbitrary data to decrypt.

This is where a threat model comes in. You evaluate the risks associated with each method, and only then can you determine whether the risk justifies the effort and impact of method.


Metasploit. Is always replacing domain names with resolved ips on RHOST/RHOSTS?

You are searching for the VHOST option. As you may know, when you rent some web hosting services, you may choose between a dedicated server and a shared one (which is much more cheaper)

On shared servers, you are sharing the same machine with random peoples. It means the websites hosted on a shared server will share the same IP address. That's why you need to write the virtual host option, it will specify which domain name you want to query on this IP address.
On dedicated servers, you can configure the machine the way you want. With or without virtual hosts.

You can determine virtual host presence with the host command on your Linux distribution:

┌──[13:33:43]─[root@attack3r]
└──> ~ $ >> host target-website.com
   target-website.com has address 49.49.49.49
┌─[13:34:21]─[root@attack3r]
└──> ~ $ >> host 49.49.49.49
   49.49.49.49.in-addr.arpa domain name pointer www.host-service-provider.com

In the example above, by resolving both the IP and target-website.com you can determine:

The target website point to 49.49.49.49
49.49.49.49 point to the host service provider domain name

In this example, target-website.com is a virtual host on 49.49.49.49. Otherwise, the IP lookup should return target-website.com, not the service provider domain name.

Keep in mind that there are some exceptions, for example, try to do the same operation with security.stackexchange.com

Testing without VHOST

use auxiliary/scanner/http/wordpress_xmlrpc_login
set RHOSTS 49.49.49.49
set TARGETURI /wp/
set USERNAME root
set PASSWORD toor
run

Output

[*] 49.49.49.49:80    :/wp/xmlrpc.php - Sending Hello...
|R-chain|-<>-127.0.0.1:9050-<><>-49.49.49.49:80-<><>-OK
[-] XMLRPC is not enabled! Aborting
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Adding VHOST

set VHOST target-website.com
run

output

[*] 49.49.49.49:80    :/wp/xmlrpc.php - Sending Hello...
|R-chain|-<>-127.0.0.1:9050-<><>-49.49.49.49:80-<><>-OK
[+] 49.49.49.49:80   - XMLRPC enabled, Hello message received!
[*] Starting XML-RPC login sweep...
|R-chain|-<>-127.0.0.1:9050-<><>-49.49.49.49:80-<><>-OK
|R-chain|-<>-127.0.0.1:9050-<><>-49.49.49.49:80-<><>-OK
[-] 49.49.49.49:80   - Failed: 'root:toor'
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

edit : Answering comments

yes it does:


How a trojan allows attacker to connect to remote computer behind a router

The attacker doesn't connect to the victim computer, the victim computer connects to the attacker. Data in a connection can flow in both directions, it doesn't matter who initiates the connection in the first place. Once a connection is established the attacker is able to execute commands on the victim computer. The attackers use well-known web protocols that are usually allowed.

Here's how it works:

The attacker compromises a server of servers to set up a command and control (C&C) system
The trojan is customized to connect to the C&C systems
The trojan is distributed (by spam emails, drive by downloads,etc) and victim systems infected
The infected systems initiate connections to the C&C systems
The attacker sends commands, updates, etc to the victims through the victim connection
The victim computers then action the malware commands (send spam, scan for identity or credit card information, search for company secrets, etc)
The victim computers send reports and data back to the attacker


Is indirect access to a computer as bad as direct?

If the the customer's client is security critical do not setup TeamView to connect to it. If breaching the customer's intranet puts the eclient's server at greater risk, then do not user TeamView.

A cursory reading shows that TeamView can use UPnP (Universal Plug and Play).

There are *29 CVE*s (Common Vulnerabilities and Exposures listed for uPnP!

If you do not know exactly how the authentication and routing of a product works, do not use it for security critical activities or infrastructure.

Anything that is more complex has the risk of having more bugs, issues, and vulnerabilities. So when you mentioned that ssh was simpler you had the right idea.

If you are using ssh to access security critical infrastructure please use key authentication instead of password authentication.


Browser fingerprints, theory or reality?

Well I can only provide anecdotal evidence for this, but I have seen a site that I was reviewing make use of Panopticlick style functionality for tracking, so it definitely does occur.

It appeared to be part of their overall user tracking / analytics set-up


Should I encrypt Long-lived Facebook Access Token when storing them in my DB?

Simply: yes, encrypt it. And don't store the encryption key in the database.

The token is tied to your app, so an attacker might not be able to use it alone, but if they can breach your database and get your app secret too they can use the token. You'd have to encrypt the app secret and the user tokens.


Why does MD5 hash starts from $1$ and SHA-512 from $6$? Isn't it weakness in itself?

First, there's Kerckhoffs's principle which is always desirable:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

where in this case the password is the key.  So its not a goal to keep the cryptosystem secret.

Second, you are wrong about those being md5 or sha512 hashes; the values stored in your /etc/shadow are md5crypt or sha512crypt, which involves a strengthening procedure (many rounds of a md5 or sha512 hash).

Now if your four choices are MD5crypt, sha256crypt, sha512crypt, and bcrypt (the most popular choices in linux systems), here are four hashes all generated with $saltsalt$ (or equivalent) as a salt and hashing the password not my real password:

>>> import crypt
>>> crypt.crypt('not my real password','$1$saltsalt')
'$1$saltsalt$4iXfpnrgHRXkrDbPymCE4/'

>>> crypt.crypt('not my real password','$5$saltsalt')
'$5$saltsalt$E0bMpsLR71z8LIvd6p2tD4LZ984JxyD7B9lPLhq4vY7'

>>> crypt.crypt('not my real password','$6$saltsalt')
'$6$saltsalt$KnqiStSM0GULvZdkTBbiPUhoHemQ7Q06YnvuJ0PWWZbjzx3m0RCc/hCfq54Ro3fOwaJdEAliX9igT9DD2oN1u/'

>>> import bcrypt
>>> bcrypt.hashpw('not my real password', "$2a$12$saltsaltsaltsaltsalt..")
'$2a$12$saltsaltsaltsaltsalt..FW/kWpMA84AQoIE.Qg1Tk5.FKGpxBNC'

Even without the annotation, its fairly straightforward to figure out which scheme they each use (md5crypt, sha256crypt, sha512crypt, and bcrypt are 34,55,98, and 60 chars long respectively (in base64 encoding with annotation and salt).  So unless you suggest truncating the hash, or altering the hashes properties the annotation for consistency doesn't lose any security.  It also gives you a method to gracefully update user passwords.  If you decide that md5crypt is no longer secure, you can switch users' hashes to bcrypt on next login (and then after a period of time deactivate all accounts left on md5crypt).  Or if your algorithm like bcrypt (when it was $2$) needs to be updated, because of a flaw in design you can readily identify flawed schemes when the fixed scheme went to $2a$.

Even worse, you could try saying, I'm going to modify sha512 with new constants and round keys.  That would make it superhard to break -- right?  No, it just makes it super hard for you to know you didn't accidentally introduce a major vulnerability.  If they can get at your /etc/shadow, they probably can also get at the library used to log you in and with time could reverse engineer your hashing scheme and this will be MUCH MUCH simpler than breaking a strong password.

Again, the expected time to brute force a very strong passphrase stored in sha256 hash is O(2^256 ), e.g., a billion computers doing a billion sha256crypts  per nanosecond (each involving ~5000 rounds of sha256), would take 300000000000000000000000 (3 x 10^23) times the the age of the universe to break it.  And with sha512crypt, if each of the ~10^80 atoms in the observable universe each did a billion sha512crypts every nanosecond it would still take 10^38 times the age of the universe.  (This assumes you have a 256-bit and 512-bit or higher entropy passphrase).


For any protocol, you could come up with a definition of "all data" that would necessarily imply that something isn't sent encrypted.

For example, during the initialization and key exchange, the algorithm selection is public. Your average cryptographer will give you little more than a raised eyebrow if you complain about that fact though, since obviously it can't be encrypted as you haven't selected an algorithm yet.

Obviously something has to be sent unencrypted if for no other purpose than to set up encryption. But once the connection is secure, everything is secure. Once you have an encrypted channel, nothing from that point on is sent outside that channel. Furthermore, the protocol is extremely cautious to avoid sending any sensitive data before encryption is available. No username, no password, no identification of any sort, no indication of purpose, or any of that.

What little there is to decode is readily decode-able using common free tools such as wireshark. Fire up a packet capture, start an SSH session, and examine the exchange yourself. You'll see immediately what can be seen and what can't. Wireshark does a great job at decoding the protocol to allow you to view the internals of how it works.... to the extent that it's visible to someone watching the network traffic.

The typical flow looks like this:

SSH version/software identification
Key exchange init (algorithm selection)
Diffie-Helman key exchange (uses SSH host key to prevent MITM)
Everything after this is encrypted
User authentication (including user key-based authentication)
SSH Session now activate


Issuing browser certificates to Chrome and Firefox with Microsoft CA

Certificate Signing Requests (CSRs) are a standard format, as are signed certificates. Without that standardization, the entire certificate system would be (more) horribly broken.

Any certificate signed by the CA and placed on a computer with the corresponding private key will be valid. Where they're generated is essentially irrelevant.

If you're already using IE with Active X for the process, then just export the resulting certificate and key. If not, make your own key and signing request with OpenSSL.

For import / export, see this also.


You can use a CSPRNG for the IV. This can be stored next to the encrypted text. The IV does not need to be kept secure, it just must be random.


Is there repetition in the Solaris 11 hash routine? Can I add some?

Are unix/linux sha256/sha512 passwords in /etc/shadow key-strengthened?

Yes.  They use a crypt procedure that does a default of 5000 rounds of hashing.  The sha256-crypt/sha512-crypt procedure is described here
and in java

Can I change the number of rounds?

Yes.  Simply edit /etc/pam.d/passwd or /etc/pam.d/common-password (or solaris equivalent) and add 'rounds=73500` at the end of the line that looks similar to:

password    [success=2 default=ignore]  pam_unix.so obscure sha512 rounds=73500

and then change your password using passwd.  Why 73500?  Well, timing crypt with rounds=5000, I was getting about 3.4 ms per password.  (5000*50/3.4 ~ 73500).  You can check if a password in your /etc/shadow  files was done an abnormal number of rounds if it looks starts with yourusername:$6$rounds=73500$RFzXZTGB$ where $6$ indicates the crypt procedure used (sha256-crypt is $5$, sha512-crypt $6$) followed by number of rounds and then the salt.

But I want bcrypt; Can I switch to that:

Check /etc/pam.d/ and (1) change all references of pam_unix.so to pam_unix2.so (check that the file is there) and (2) then change sha512 to blowfish in /etc/pam.d/common-password

https://serverfault.com/questions/10585/enable-blowfish-based-hash-support-for-crypt/11685#11685

One noticeable difference between bcrypt vs sha512-crypt; is that bcrypt work-factor scales exponentially; e.g., a work-factor of 12, should take double as long as a work-factor of 11, while sha512-crypt rounds scale linearly (e.g., rounds=10000 should take twice as long as rounds=5000).  This is simply because bcrypt says do 2work-factor rounds.  As a quick benchmark on my machine, one bcrypt round is more expensive than a sha512-crypt round; with a rough equivalence of ~4 ms with rounds=5000 or work-factor=6 (26=64 bcrypt-rounds).  But as both can be scaled up this should not be an issue until the number of rounds overflow the unsigned 32-bit/64-bit int (when rounds = 4 billion or 1019 respectively).

Python timing Stuff With sha512-crypt

You can check crypt via python (in linux this performs just as fast as the C version as it just is a thin wrapper for the crypt library written in C)

>>> import crypt
>>> crypt.crypt('testtest', '$6$6LzxTFam$')

In python on my machine with the crypt module it takes about 3.4 ms per sha512-crypt password at 5000 rounds and ~50 ms with 73500 rounds.

>>> import timeit
>>> timer = timeit.Timer("crypt.crypt('testtest', '$6$6LzxTFam$')", setup="import crypt")
>>> timer.timeit(1000)
3.4215329647064209
# with 73500 rounds:
>>> timeit.Timer("crypt.crypt('testtest', '$6$rounds=73500$RFzXTGB$')", 'import crypt').timeit(1000)
50.738550186157227


Live Linux which does not mount any hard drive in the computer

Backtrack 5 gives you the option when booting to start in forensic mode which means it will not attempt to mount any drives, unless specifically requested by the user.


Trustworthiness of Let’s Encrypt and ZeroSSL within browsers and OS

From edits, I think you're trying to work out how Let's Encrypt certificates are trusted by browsers/OSes even though they're a new CA.

Essentially, they're trusted by older devices because their intermediate certificates (the ones they actually use to sign certificate requests) are signed by a known root certificate from another provider (IdenTrust) as well as by the Let's Encrypt root certificates. The IdenTrust root certificate is known to older devices, hence there is a chain of trust to a trusted root.

For newer devices, the Let's Encrypt root certificates are known as well, meaning that browsers which are aware of these certificates have multiple possible chains of trust to trusted root certificates - it can go site certificate->LE intermediate->IdenTrust or site certificate->LE intermediate->LE root.

In the case of StartSSL, the trust in the root certificate was revoked by browser and OS vendors due to various flaws in how the CA was handling certificate issuing. In theory, the same could happen to Let's Encrypt, but it could also happen to any other CA, if they're doing dubious things. For an example of a large CA having trust revoked, see Mozilla blog post on distrusting Symantec


More clarity on Certificate, public key, hash

What you are looking at (PEM, text) are just two possible views of the same data.

  what is my public key here ... is it a continuous large number in hex format

A key is a sequence of bytes. Hex format is just a representation of these bytes as text in order to be viewable by a human. There are different kinds of public keys (RSA, ECC,...) and what the sequence of bytes exactly mean depends on the kind of.
What you see here are not the pure bytes of the RSA key itself but already an interpretation of the bytes, i.e. the modulus and exponent of the RSA public key.

  How to see only encoded public key from a certificate

The public key can be extracted from the certificate with

$ openssl x509 -in cert.pem -pubkey -noout

If you only want to get to the bytes of the key itself and strip the encapsulation you can use openssl asn1parse -in pubkey.pem -dump to get to the details. See also RSA: Get exponent and modulus given a public key on how to extract exponent and modulus from the public key.

  How do we take sha1 hash to hash the public key?

Once you have the public key as PEM (as above) you can convert it to binary and take the sha1 of it. Conversation to binary is done by stripping the PEM header and footer (grep -v '^-') and then converting the rest from base64 to binary (base64 -d):

$ openssl x509 -in cert.pem -pubkey -noout | grep -v '^-' | base64 -d | openssl sha1


SSH: reusing public keys and known-man-in-the-middle

Usually, people recommend to use a single private-public key pair everywhere (if we're not talking about a possibility of compromising the private key)

Note that there are two key pairs involved in an SSH connection:

one to identify the server host (the server has the private key);
one to identify the user (the client has the private key), if using public key authentication.

The recommendations you cite are about user keys. Having a single private key per user is a viable model, though I don't particularly recommend it (the cost of having separate key pairs per host or site isn't that high). Server keys, on the other hand, are never duplicated. They are generated afresh when the SSH server is installed.

On this topic, beyond the posts you've cited in your question, see also What is the difference between authorized_keys and known_hosts file for SSH?

In the attack you describe, you've mixed up the roles of the keys. These are the host keys, ssh_host_rsa, and not user keys. This isn't directly relevant in how the attack you describe works, but may be part of your confusion.

The sticky point is at step 3.3:

  PC1 accepts S1_id_rsa.pub's fingerprint (as it's known)

There are two cases.

If PC1 has connected to S2 before, then PC1 (or more precisely the account of the user on PC1) has memorized S2's host public key in its known_hosts file. So if S1 sends S2's host key, the SSH client on PC1 will detect that the purported host key does not match the recorded host key and abort the connection with a scary message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

The attack is thus impossible in this scenario (unless the user goes out of his way to bypass the check — OpenSSH purposefully makes this difficult).
If PC1 has never connected to S2, then PC1 will happily accept whatever S1 is now telling it is S2's key. Since PC1 has no prior knowledge of any association between the name S2 and a cryptographic identity, nor any way to contact a trusted third party who knows such an association (i.e. a public-key infrastructure), there is no way to prevent this man-in-the-middle attack.


Host Header Attack -> Password Reset Poisoning -> ASP.NET Web API 2 hosted as Azure App Services

Gonna give it a shot and answer this myself. The code responsible for sending out the email looks like this:

await emailRepository.SendResetPasswordTokenAsync(Url.Action("ResetPassword", "Authentication", new { token.Token }, Request.Url.Scheme), model.Email, token.User.FullName);

The vulnerable part is this bit:

Url.Action("ResetPassword", "Authentication", new { token.Token }, Request.Url.Scheme)

I created an application on my machine and tried creating URLs with IIS Express and changed host and got the exact same error. I think this error occurs because there is no default binding and because the request is issued using HTTPS. If I change the request to use standard HTTP the host header is interpreted and in the request below I end up on domain2.

However I also tried it using my local IIS with binding to catch all on port 80. Using the same code as the vulnerable application I was able to manipulate the host:

Code:

public ActionResult Index()
{
    var host = Request.Headers["host"];

    ViewBag.Title = $"Host: {host} Url Created: {Url.Action("Index", "Home", "", Request.Url.Scheme)}";

    return View();
}


You can use to normal wireless cards and change the mode to Monitor mode .

Ralink and Atheros cheapests are best choices .

Aircrack-ng's website have compatibility drivers page, since that proposed good device for WiFi sniffing data and raw packet injection, you can use that :

Best wireless USB proposed devices


Do you need to test the credentials or really store it ?

If all you want is check whether the user knows a given credentials, then use a secure password key derivation function (for instance, PKBDF2, BCrypt or SCrypt) instead.

If you really need to store the credentials (for instance, you need to forward it to an external service), then the answer is that you need to rethink your model:

If you're providing pre-filled passwords for a remote service (for instance, you want all your users to share a specific account on a mail server), then that means you're using hard-coded passwords and that is really bad: you cannot possibly secure it and obtaining these passwords, even if you obfuscate then, is usually very easy for an attacker to obtain it. And once one attacker has obtained that password, he can leak it for everyone else to use.
If your pre-filled password are actually just initial values that are supposed to be changed later, then leave them blank and force the user to change them during the installation.


What are the security implications of enabling CORS for images?

Depends how you set it up. If you allow Cross Origin Requests from any domain, then an attacker who finds the image URLs can do anything you can do within your Javascript application - the security is exactly the same as what you have. If you restrict the requests to your specific application server, they shouldn't be able to do anything, just as you can't at the moment.

CORS is aimed to prevent client side attacks such as loading an image which the remote site can't see (with an image tag to a, for example, Facebook server), then copying the content to their server without the client being aware. Therefore, the situation you describe is exactly what it handles well.

In this case, it is more important that any functions to save the modified images to the server are secure, since these could result in server compromise, or simply in third party sites using your system as a way to store their images. Don't forget that even with CORS enabled, an attacker can easily load images directly from your server if you don't perform proper authentication steps - for example, by running a cURL command on the image URL.


Web developer needs customer's private key

Plenty of entities will commonly have access to the private key:

Hosting provider may read it at will.
Employees of company may read it.
Service provider who generated it may store a copy.

We handle this by legal agreements. We trust our hosting providers not to peek at it, because their business model is selling hosting (and implicitly trust), not stealing your private keys. In addition, there may be explicit NDA's and legal accountability.
We trust employees, because of NDA's and a legal framework for holding them accountable.
You see a theme here? It's a private key for payment processing. If you don't trust whomever develops your e-commerce platform to handle this, you shouldn't trust them to develop your e-commerce platform either.
In fact, having competent people handle the key material may be securer than attempting to instruct someone from Company X, who may not know about editors leaving a backup file behind - or transporting it over insecure channels - or all other kinds of mistakes.
Transfer the key to the developer in an as secure fashion as possible. This may be S/MIME-encrypted e-mail, PGP, or a 7zip-archive with a complex password sent in a separate channel (SMS, phonecall, mail etc).
Develop a legal framework for holding Company Y accountable if they leak the key, and specify measures that they should take - such as limit the availability to the minimal set of persons needed and so forth.


Secure architecture for isolated printer network

Ideally, printers are to be seperated from their clients (and the internet) as much as possible.

There seems to be some kind of confusion on your side between categories of network devices. I'm assuming you're coming from a COTS standpoint which usually means that a device called "Router" does carry the jobs of "Router", "Firewall", "Switch", "WiFi Access Point", "Gateway" and "NAT", which might lead to the confusion.

A network architecture that can provide this might in it's simplest possible layout (which can easily be more complicated when deploying microsegmentation between clients and/or printers for example) look like this:

[Clients -> (Firewall] -> {Print Server) -> Printers}

where

[] = the network connection between the clients and your Firewall,
() = the network connection between the print server and your Firewall,
{} = the (network?) connection between the Print Server and your Printer(s)

Now, the connection between the print server and the Printer(s) doesn't need to be networked. The printers could just be locally connected to the print server, for example by USB or LPT.

Also worth noting is that this setup is minimal for this case; usually, there are different subnets of clients that need different printer access which leads to vastly more complicated setups that do seperate networks even further, using more Firewalls, Gateways and Print Servers.

Please also note that none of this includes internet access thus far. In this setup, internet might be provided through the Firewall (over a seperate network connection) and access rules on the firewall would prohibit internet access for the print server.

Additionally, COTS "Router" devices usually do not provide all features of actual Firewalls, making this setup hard to achieve with it - and you usually do not. One notable exception are COTS Routers that offer a USB Port to connect a printer to in which case the device itself functions as the print server.

Lastly, please note that the threat model for private households and companies vastly differ and this setup might not be suitable for home deployment.


Mysql - two-way encryption of sensitive data (email addresses) outside of Apache, PHP and MySQL

"Ciphers are hard. Cryptography is hard. Ciphers are the easy part."

  --Bruce Schneier

Coming up with your own home brew algorithm for encrypting email is literally the worst mistake you could possibly make in cryptography.  I am not being hyperbolic, it is in fact the worst mistake.   The whole point of modern cryptography is that the algorithms are public so that they can be peer reviewed.  I would never consider using a private algorithm for any reason.  The key is what is secret,  and this makes the system work.

In your case. The database can be compromised and the messages can remain secure if each client used their own asymmetric key pair.  The email infrastructure just passes along the cipher text without any means of deciphering it.  This is how Enigmail works.  In fact I highly recommend using Enigmail,  why reinvent the wheel?


Protect SSL connections from MITM for users with modified clients

Would HSTS be effective if the Proxy's CA is in the trusted store?

The public key pinning built into Chrome and Firefox is ignored if the certificate is signed by a CA which was explicitly imported by the user (i.e. trusted but not built in). This is to support the common use case of legal SSL interception in security devices and software, i.e. to detect malware even in encrypted connections.

I'm not sure about the HSTS header, but I assume that the behavior would be the same.

  Is there any way for me to protect against this MITM attack server side?

You can not detect which CA gets used on the client side. What you can do is to require a client certificate. Both legal and illegal MITM will not be able to  transport the original client certificate through the MITM so they will either fail (in most cases) or they need to rewrite the client certificate too which you can detect on the server side.

Of course even with requesting a client certificate you will not be able to detect clients where some software (malware or not) gets access to the decrypted traffic by injecting into the browser directly, i.e. using browser extensions or DLL injection or similar techniques.

  Like have the server check the client to ensure the right client is being used.

All you can do on the server is ask the client and check the answer. Since the client can lie to the server you could make it hard to lie by obfuscating the code and then asking for things which can be only answered by the client executing the code in the right way. But this can be the right client, the wrong client which understood the obfuscated code or the wrong client just instrumenting the original code.

What you really want is a remote attestation that you not only deal with an original unmodified client but that also no other process can somehow control the behavior of this client. To get this you have to start much deeper, i.e. usually you already need to have control of the clients hardware etc. I recommend that you look into the techniques they've tried to harden XBox and Playstation so that only original and unmodified games can be played and how often ways were found to evade the protection techniques. Or how Sony tried to control their customers PC to prohibit the ripping of their CD's by silently infecting the PC with a root kit.


Trying to get a grasp of approximate risk level of CMS admin logins over http

It's always good to have encryption over a CMS-based website. I would recommend to always use HTTPS because you never know who is intercepting traffic and what their intentions could be. For instance, if someone was intercepting your traffic and performing MITM attacks; they could respectively grab your login if they decided to and could pretty much try this login with other accounts of your own etc etc.

Although all users can become trusted as you are implying in your question, I would still use encryption. Anything can happen. I don't know if you have heard of an HTTPS exploit called 'BREACH'. This is a security exploit upon HTTPS that uses HTTP compression. More about it here: https://en.wikipedia.org/wiki/BREACH_(security_exploit)

You're definitely on the right track, I don't see flaw within your knowledge and you're definitely asking the right questions to build your base.


Wiping a computer of personal information while keeping the operating system intact

Windows 8 and 10 have options to reset your operating system to factory defaults, with or without keeping your personal files.

Click here to see how to do that

Additionally, you can use a utility called eraser to securely erase free space left on the drive.

Click here to check out eraser

This combination would be the simplest method to accomplish what you want accomplished, to the level of security that would most likely suit your needs.

Edit: Microsoft designed their reset tool to be able to securely erase your data, suitable for situations in which the ownership of the computer itself is transferred. This means that eraser may actually be unnecessary. However I will keep it included with this answer for completeness purposes.


Why use usernames and not just email addresses to identify users?

Your question is missing a lot of context, but what you do say sounds like you’re looking to settle an argument. So my answer will start with “It depends...”

One reason to have unique usernames that aren’t email addresses is to protect privacy when other users can see the username. For example, GitHub profiles indicate the username in the profile URL, and as authorship indicators on commits, issues, comments, etc.

Providing a username as the user’s public face instead of their email address allows them a layer of privacy.

In some rare cases, a service may elect not to collect email addresses at all... since email addresses can be considered sensitive and personally identifiable information. The downside to not collecting an email address at all is that account recovery for someone who forgets their password, or has their account breached, will be more difficult without a verified channel to use for recovery.

Or for the hybrid approach, one might collect
the email address, but store it in the database behind strong encryption. Strong encryption is generally difficult to search on, so having a less sensitive identifier to use that can be store in plaintext would be convenient.


A DOM-based XSS is a vulnerability in the application or in the browser?

As the application provides the logic that results in unexpected behavior DOM based XSS is clearly an application issue.

DOM-based XSS protections are built-in to many modern browsers, but you should not rely on them as they protect against a smaller subset of attacks.

  Edited to clarify that one should not rely upon browser features for
  XSS protections.


Why aren't we all compromised on the internet?

The number one reason why we are not all compromised is that there are just not enough attackers to do the job, and most of you are not interesting enough targets either. Civilization as a whole can keep on running because most people are basically honest; you can walk in the street among complete strangers and none of them will try to punch you or stab you, despite the low numbers of police forces. This also works on the Internet.

Now that reason is also the one which explains while security holes induced by sloppy development appear to be allowed to linger for years. XSS ultimately comes from Web site developers who fail to handle input data from clients as data; they reflect such data by dumping it unmodified in pages returned to other clients, a fateful gesture by which they turn that data into code. This is a design bug, and since it has security consequences, that bug is a vulnerability.

Things are getting better gradually, though: now, many Web developers are at least aware that putting together a secure login page is not as easy as it seems. Among the operational rules that Web developers begin to follow more or less consciously is the idea that a "login page" is something special that should be separated from "normal pages" and that should, in particular, NOT contain any user-reflected data. A lot of programmers don't put it that way, either in written words or in the privacy of their mind, but they still follow such "hygienic" behaviours, which, like their biological counterparts, are effective even when you don't understand them.


My OpenPGP private keys are set up with sub-keys. What happens if I revoke a sub-key and re-issue a new one?

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

You pretty much got everything right; that's exactly what subkeys are primarily used for (there are some other neat use cases apart from exchanging subkeys without losing reputation in the web of trust).

I'd add that there might be a given latency: the key needs some time (usually minutes, less than an hour) to spread through-out the key server network. If the situation is critical, and you know somebody is listening your communication, consider uploading to different servers in the SKS server pool to speed up reconciliation/spreading of the key.

Furthermore, your communication partners will very likely only occasionally fetch updates of your key. Consider sending an information about changed subkeys due to compromised old ones; and also explain why your master key is still save.


Is it possible to include a PHP Function while performing SQL Injection?

Generally, it CAN NOT be done. SQL injection only allows you to execute SQL commands. You are not directly able to use PHP.

The only way you may be able to execute PHP using SQL inejction is if the page uses eval() on un-sanitized input from DB. Few web pages will ever do this. It may be possible even if the page uses something even more rare and weird such as generating a php file to be included from DB, but this virtually never happens.

If the page uses eval on result from DB, then you just use the SQL injection to insert the code to the appropriate place in the DB (the column that is put into eval) and then visit the page that uses the eval(). Once the PHP code from the DB is passed to eval, it is executed.


How do we estimate the time taken to crack a hash using brute force techniques

For hashes with no attacks beyond brute force, cracking time is:

keyspace / hashrate

A six-digits-or-less password has a keyspace of 1,111,111 possible values, so a hashrate of 377 hashes per second is sufficient to crack it.  Now, for a modern computer, that's exceptionally slow (the sort of hash rate you might expect from an Apple II), and wouldn't be worthy of note.  The article is actually about passwords of 1 to 6 characters: assuming alphanumerics, that's 6.2*10^10 possible values for a more impressive 21 Mhash/sec; if it's bytes, that's 93 Ghash/sec.

SHA-512, SHA2-384, and SHA-224 aren't much slower to compute than SHA1 or SHA-256, so if you can brute-force a SHA1-hashed password in an hour, you can brute-force it in about an hour if one of the other SHA hashes is used instead.  This is why passwords should be hashed using an inherently slow algorithm such as bcrypt.


Can I replace username and password with a long random text in URL?

Even though the entropy in a large random token suggests that the token would be a secure mechanism of authentication, there are many problems associated with it:

The token is fixed per user, so a user can't change the token if they suspect it is compromised.
The token could be used unlimited times, which increases the opportunity for compromise.
Based on your description, the customer may know the tokens for his or her employees. While the data may be the same (or have the same access restrictions) for each account the customer manages, this compromises non-repudiation. The customer could use an employee account and no one would be the wiser.

There is a Process Problem

As you have pointed out, having customers call customer service to change a password has two significant problems:

First, it is inefficient for your business, and is costing your business and your customers money.
Second, it is dangerous from a security perspective.

Consider how allowing customer service to reset passwords affects the application security:

Any customer service representative can reset the password (and based on how you describe it, actually set the password) of any customer account, and can therefore access the confidential information of that customer's account.
Depending on the procedures for the phone-initiated password reset, the process could be susceptible to social engineering.

Use the Random Token to initiate a Password Reset

Customers who need to change their password should use the existing web application to request a password reset. This could ask for an email the account is registered to, and optionally, a set of security questions (depending on your own risk assessment). Next a password reset link with a random token is emailed to that email address. This link should only be valid once, and should expire after a short time if not used. When the user clicks the link, they are authenticated. Most web apps will have the user set a password at this point. In your case, you may want to allow the user to skip setting a password, since they will forget it anyway.

Customers who call customer service to reset their password should be instructed to use the password reset feature. The customer service rep may remain on the line and walk the customer through the procedure, but the key point is that the customer does the reset themselves. Once a customer resets a password themselves, they are less likely to call in again.


By executable, you probably mean the .exe "executable" format that Windows uses to denote anything that contains a program. (Note that other extensions such as .com may also be executable, and it are not only executables that can get you infected; a malicious PDF does the job just as well.)

Any OS allows the execution of files, or else you can't do things like starting Powerpoint. You are right though that Chrome OS can't (by default) execute Windows' .exe files, but it's just as easy to make "binaries" (a more general term for executable files) for Chrome OS.

Chrome OS is based on Linux, making it vulnerable for pretty much any attacks that work on Linux computers, though it seems some things are sandboxed more than most other Linux distributions would do (see rakslice's comment). Many things in Chrome OS are done in the browser which makes it more secure, but this still doesn't eliminate all exploits. Migrating to Chrome OS would at least temporarily solve your problem since any attackers need to rethink their strategy, but it won't take very long. Windows, when used correctly, is a reasonably safe OS to use. The fact that you have real security issues (as you put it) hints at an underlying problem such as incompetence of employees (opening untrusted email attachments), bad patching, or something else.

If the attacks are by chance, e.g. when a user visits a website that happens to be infected, moving to Chrome OS (or any other Linux system) will solve your problem. In small organisations this might be an option, though in general I wouldn't advise to change the OS just because some employees happened to visit an infected website. Better install good anti-virus software, monitor workstations, limit permissions as much as possible, and setup a plan to perform when infections do occur. Something like: the computer will be taken off the network, the harddrive will be inspected and scanned in a safe environment, when the malicious part is found other computers will be scanned to see whether they have the same, and any infected computers will get a complete reinstall (shouldn't be too much work with system images and adequate backups).

If the attacks are targeted at your company specifically, you're in bigger trouble. Get someone on board with real knowledge of security, at least temporarily to get things under control. Targeted hacking attacks by professionals are hard to defeat and usually beyond the control of most sysadmins.


What's the best way to send and receive lots of login credentials?

First, you can't e-mail over HTTPS.  HTTPS is a web site protocol, not an e-mail protocol.  Encrypted e-mail exchanges require the mail servers to communicate using TLS or SSL.  The best way to exchange credentials, if you absolutely have to do it, is to encrypt them with a secure, long password or better yet, a pre-shared key or using a secure key that is shared using asymmetric cryptography to prevent the key from being accessible to someone reading the e-mail.

Secure FTP is also another viable option if you have a secure FTP site that can be used.  Again, high security passwords should be used.

SFTP is probably the simplest since you can install a fairly simple client to let them upload it with.  Most e-mail encryption setups are going to be overly complicated for an average user unfortunately.

The ultimate easiest way would be to use some kind of HTTPS website that would allow them to submit the credentials and protect them with a random key that would be encrypted with a public key that only allows the credential key to be decrypted after the credentials are removed from the web connected machine.


Is it safe to derive an IV partially from the secret data if it is hashed before use?

If your IV is derived from the plaintext, so that encrypting the same plaintext twice leads to the same IV, then you lose semantic security: someone can tell whether two plaintexts are equal by comparing the ciphertexts.

Other than that, for CFB, it is ok to use a predictable IV; what is critical is that the IV is not reused (or at least not reused for distinct messages, with the caveat above).

So a cryptographic hash of the whole plaintext, or of the plaintext plus other data, is a suitable IV as long as you don't mind exposing plaintext equality. Note that if you include data other than the plaintext (e.g. IV = hash(plaintext || moredata)), then this also exposes the equality of moredata if you have the same plaintext multiple times with different moredata.

Source: Is using a predictable IV with CFB mode safe or not? On the danger of reusing an IV, see Will varying plaintext compensate for a fixed initialisation vector?


Can the sandboxing technique prevent a buffer overflow attack?

Can the sandboxing technique prevent attack? How?

No, sandboxing will not prevent attacks designed to take advantage of this buffer overflow.
To quote Wikipedia,

In computer security, a sandbox is a security mechanism for separating
running programs, usually in an effort to mitigate system failures
and/or software vulnerabilities from spreading. It is often used to
execute untested or untrusted programs or code, possibly from
unverified or untrusted third parties, suppliers, users or websites,
without risking harm to the host machine or operating system.

In your case, the program is wholly contained.  The authentication is within the program, the authentication bypass is within the program, and the putative secret information is within the program.  All the harm that is done is within the program; it does not touch other programs or the operating system.
Therefore, a sandbox, which separates programs, cannot impact the security of this one program.  Sandboxes address sets of programs; they do not protect individual programs.


Accuracy of Iris Biometric Authentication

I don't know about the false acceptance rates of biometric devices.

  At a busy airport, an error rate of 1 in 1000 could mean 10 to 50 bad
  guys going through per day.

Why would you assume that every false acceptance is a bad guy? If you were a bad guy, how could you be sure that you got through when the biometric reader was going to accept a false id (fingerprint/iris)?

Also, it is difficult, if not impossible, to create perfect (unbreakable) systems. There are way too many factors to consider.

This is an acceptable risk, in my opinion. Imagine what would happen if we dismiss the system due to this risk? That would create more problems.


How long does it take for Google to detect click fraud and suspend an AdSense account?

When they realize that a big proportion of your clickers aren't buying anything, anywhere... if they have access to this data.

I guess they can have feedbacks from clients on where they obtain their sales, and if on your site they are really low, or non existent, they will surely compare it with the typical profile of the people visiting sites similar as yours. Then they will just need to reach a critical value of abnormal behavior to claim with confidence that you are hiring a click farm.

this question cannot be answered precisely as

As GdD said, it is counter-productive for Google to tell
It certainly depends on the type of site, the time, the type of visitors (and their buying habits), the number of visitors per month, and the few elements that click farms may publicly post (hours, duration of the click sessions, global localisation of IPs -do they match geographically with similar site's customers?-, how many of the clickers aren't on other cookie-enabled Google services compared to the average, etc.)

The only advice I can give if you decide to hire such services is:

Don't
If you still do it, be clever. Do it in a nefarious way that doesn't draw too much attention. Remember, you are still under the threat that the click farm may operate unstealthily and/or get busted, bringing down all its clients in the process.

Good Luck.

PS: This is merely logical reasoning. I neither work for Google, nor do I have a stake in the click fraud industry =)


Should I regenerate new SSL private key yearly?

Reasons to Regenerate

In case there was a private key compromise you didn't know about
If you are renewing your cert, why not?

Reasons to Not Regenerate

Adds little (if any) extra protection
As CA compromises become more common-place browser plugins are remembering visited site's certificate fingerprints in order to check for changes (a type of anomaly detection). Changing your key will change the fingerprint.
Unnecessary work

This was the best I could come up with. I think solely for #2 on the Not list, I wouldn't do it. You can look at these though and weigh the reasons given your specific setup.

If anyone else has any to add, let me know.


Can a company track your browsing history if you are not connected to the company network?

If you haven't disabled search history, they'd be able to look at your searches if they go to the search history record for your account.  You can check your own Google search history by logging in here.

They may also be able to track activity on other Google services, like Youtube, Maps, News, etc since they've implemented Single Sign-On which logs you in to all of their services together.  But if the laptop and internet connection are not controlled by your company, it is unlikely that they'd be able to get anything not related to Google.


A compromised router (which is just another computer that happens to be on the network path between your other computers and the Internet) can attack hosts and compromise them. It can also redirect your HTTP (not HTTPS) requests to malicious websites in an attempt to fool you into installing malware. However, I would be really surprised that it could compromise a brand new, up to date Windows machine assuming the user wasn't an idiot and didn't intentionally execute the crap served from the malicious websites it redirected to. I'm not saying it's not possible - there is always a risk of a zero-day vulnerability (which would work silently without any user intervention), but nobody is going to "waste" a valuable zero day on you unless you're a really valuable target (and then they'll do a better job at silently compromising you rather than alerting you because your Internet doesn't work).

I'm actually sure your problems aren't caused by malware, but given that both PCs seem to have malware (at least according to the so-called "technicians") it looks like both computers continuously compromise each other so it's time for a proper solution.

Stop paying incompetent people for installing useless "best virus protection" (there is no such thing, antivirus evasion is trivial and the best antivirus is you) on an already compromised machine. Follow the usual procedure for dealing with compromised hosts : from a known clean machine (friend's PC, etc), download the ISO corresponding to the Windows version on your computer - pirate sites are a good source for them but make sure to verify the hashes against the official hashes published on MSDN to make sure you didn't get a compromised version. Now burn that on a disc, bring it home, disconnect your computers from any network (Ethernet disconnected and Wi-Fi switch set to "off"), boot from the disc, nuke everything and reinstall. Do the same for all machines on your network, then reset your router, connect the machines to it and only let them install updates - don't browse the Internet just in case your router redirects to malicious websites that would exploit the still unpatched Windows. Once it's up to date, if you still see weird stuff like redirections to malicious pages (sometimes full of nasty ads like porn), return the compromised router to your ISP and invest in a better one that has at least a somewhat decent firmware.

Note that you should never trust the "Refresh My PC" feature nor the built-in recovery partition for reinstalling a compromised machine - writing to that partition is trivial and malware can easily use it to persist.


How was Walmart able to pop up an unsolicited "Rate your visit" notification on my phone?

TL;DR: By December 6th, 2018, Google stopped serving Nearby Notifications. Android users won't receiving this kind of notifications.

How were they able to push a notification?

As @Martin Fürholz pointed out, that was came from Google Maps notification service. Specifically, from Nearby Notifications feature that being developing by Google for the last years.

  Nearby Notifications Overview:

  Nearby Notifications helps users to discover what's around them, by surfacing location-specific notifications for apps and websites, with no prior app install required. Using Nearby Notifications, you can:

  Drive your own app installs.
  Open personal or business profiles in social apps.
  Launch conversations or chatbots inside messaging apps.
  Drive consumers to content about nearby products.
  Help users explore store inventory.
  Drive checkins, reviews within local/travel apps.

  Neither experience requires that an app is installed on the user's device.

(source)

  How Nearby works:

  Nearby can use small amounts of Wi-Fi or mobile data to connect to Google and get info about broadcasts or shared apps.

  Nearby doesn’t track, monitor, or send personal info from your phone.

  Nearby broadcasts are one-way, like over-the-air TV or radio.
  Services that send Nearby signals don’t detect or get data from your
  phone.
  When you give permission, apps that work with Nearby share
  with each other using remote servers. The sharing devices don’t
  connect directly.

(source)

How to disable Nearby Notifications?

Open your phone’s Settings app
Tap Google > Nearby > Settings
Under "Notification categories," tap a category.
Turn that notification type off.

(source)

Related articles:

Google Maps now lets you quickly, and mindlessly, rate places from a notification
Google Maps for Android Lets Users Give Ratings to Places Directly From Notifications

But, keep in mind, Google decided to discontinue support for Nearby Notifications. They'll stop serving Nearby Notifications on December 6th, 2018. Learn more.


Should i block Yandex

Why?
First, if the bot is a legitimate search engine bot (and nothing else), they won't hack you. If not, blocking a User agent won't help, they'll just use another one.
If your password is good, fail2ban is configured, the software is up to date etc., just let them try. If not, you need to fix that, independent of any Yandex bots.

To make sure the problem is actually Yandex, try disallowing it in robots.txt and see if it stops.
No => not Yandex.

(Did set up a new webserver some weeks ago. One hour after going online, had not even a domain yet, a "Googlebot" started trying SQL injections for a non-existent Wordpress. It was fun to watch, as there were no other HTTP requests. But I did not block Google because of that.)


how to compile a generated exploit in metasploit into a C program

The code is already 'compiled' machine code. Just do something like this in main():

int *ret;
ret = (int *)&ret + 2;
*ret = (int) buf;

Just make sure you disable non-executable stack with -z execstack flag while compiling.

EDIT:
Breaking down the code -

int *ret;

We are declaring an int pointer named ret as a local variable in main(). Being the first and only variable, it lies immediately below the old frame pointer in the stack.

ret = (int *)&ret + 2;

Next, we are adding 2 to the address of the ret pointer and storing it back in ret. If you look at the figure, the return address lies exactly 2 dwords above ret. So we are basically storing the address of the return address in ret.

*ret = (int) buf;

Finally, we are dereferencing ret to replace the existing return address with the address of buf (our shellcode - presumably declared globally).

main() will therefore be returning to buf instead of where it was supposed to. The bytes in buf will be interpreted as code and will be executed happily. This is what typically happens in a vanilla buffer overflow exploit. The control flow is hijacked by causing a buffer to overflow and making it overwrite the return address with something that the hacker has control over (usually injected shellcode).

Do note that modern OSes usually store additional stack canaries to detect overflows. Therefore the offset '2' might not hold true. For simplicity, use the -fno-stack-protector flag while compiling in gcc to disable stack canaries.


Strange traffic on my NAS, need to worry?

UDP port 123 is for NTP- Network Time Protocol. That IP is in the pool of public NTP servers. Your NAS is simply keeping its clock up to date.


Spectre/Meltdown - Does memory deallocation erase the actual RAM contents?

Rather than give you a direct answer, because it's mostly going to be "it depends", I thought it might be more interesting to take you through a recent discovery of mine that describes the behaviour of memory allocation on Windows, so that you've got some context behind all of it. I don't know enough about the Linux memory management model so I won't comment on that side of things, although I am told that it is quite similar.

Recently I was thinking about W^X memory protection features offered by the Windows kernel, known as "dynamic code policy". The idea is that once a page mapped into an application has been marked writable, it can never be marked executable. This is a powerful exploit mitigation because it prevents almost every class of exploit involving delivery of shellcode. You can't just do a buffer overflow, gain control of the instruction pointer, ROP to VirtualProtect, mark your payload as RWX, and execute it - the VirtualProtect call fails because memory cannot be writable and executable.

My thought for a generic bypass here was that you could VirtualAlloc some read+write memory, VirtualFree it, then VirtualAlloc again as read+execute, hoping to get re-allocated the same pages. As it turns out, this doesn't work. The reason why is relevant to your question.

There are three cases where Windows memory management will scrub pages to zero:

When a page is committed to a process
When a page has been marked as MEM_RESET
When a page has been freed and is marked as dirty

The first one thwarts my plan. Processes can be allocated virtual address space without committing them, e.g. via calling VirtualAlloc with MEM_RESERVE. The reserved address space isn't directly mapped to any physical memory or swap, but it is kept for use by the process in case it needs it. In order to actually use the memory the pages must be committed, e.g. by calling VirtualAlloc with MEM_RESERVE | MEM_COMMIT. Upon being committed a page will be zeroed if it has not already been by some other means. As such my trick of allocating writable data, freeing it, then allocating it as executable is broken because the memory manager zeroes the page.

The second one is also interesting. If you're done using a block of memory for now, but will use it again later, you can reset the page using MEM_RESET. This indicates to the memory manager that it should not decommit the page from the process, but it should not bother swapping them out to disk as the data contained within is no longer interesting. The system will zero these pages in the background when there is free time. However, the application can request to undo the reset flag if the system has not yet zeroed out the page, using the MEM_RESET_UNDO flag.

The third option is that you decommit and release a page, and it is completely free to be reused by the memory manager with any other process. If the page contains data it is marked as dirty. The system will either scrub it in the background or actively zero it when committed again.

These are the case for system level memory management. Process-level management is much different, e.g. using HeapAlloc, library allocators (malloc), or a completely custom allocator. These designs may allocate and commit a memory page and perform their own management of memory use on top of that committed block. As such, a libc free() call may not actually decommit underlying memory pages. It is also totally possible for a malloc() call to return pages that have not been reset - this is why calloc() exists.

The next part of the question is whether browsers have any active defenses against this. I don't know if they do. It's certainly possible that their memory allocators explicitly zero all new allocated pages (or set them to some magic value, e.g. 0xDEADBEEF) in order to limit the potential for and better identify cases of uninitialised memory reads. Also, for example, Microsoft Edge's memory allocator is specially designed to offer increased security against memory corruption, so resetting allocations is part of that.

In summary, it depends!


I'm not specifically familiar with how the Plus works, but I can comment on the first two questions.

To identify a card, you can look at its SAK and, if applicable, its ATS. MIFARE card identification procedures are shown in this document, on page 7. This webpage has some additional information.

To interact with the card, you'll need an NFC reader, such as an ACR122U, as well as libnfc. Libnfc's nfc-list command will print out some basic information about any cards it detects, including the SAK and ATS (if applicable) needed to identify the card. I also made my own tool to print out basic information about a card and roughly identify it, and you can see how that works here.


Can a school look through your messages on a personal account if you logged in on your school computer?

Technically, anyone with administrator privileges can log your keystrokes and duplicate your username and password. They could also copy browser cookies or other data to continue your session.

This is one reason why many security professionals discourage accessing personal or company data on public terminals.

Whether it is legal depends on a number of details.

In the US, if there is a warning or a user agreement that indicates monitoring may occur, it is usually permissible to observe anything that occurs on the machine. Organizations that are highly secure (or paranoid) can install applications like ObserveIT with screenshot capability.

Poking around and stealing credentials isn't usually allowed, however---unless there is justification for an investigation. Schools in the US have complicated rights and responsibilities when it comes to student safety and privacy, so it is best to have a lawyer review the details if the issue is serious.


Authenticated sessions and Man in the middle

it simply can avoid leaking username/password. in your scenario MITM can avoid security. in other word fooling users.

however there may be some mitigation, such as session id is per IP/Country. so if someone from another ip(probably someone who MITMed the id) request page, session expire.


Encrypted E-mail requires a bit of work by somebody.  You've done the work for your users.  Now the question is what's going on at the other end.   The person on the other end will need to create (or have created for them) an SMIME certificate and private key.  Then the folks at each end will want to exchange SMIME certificates.

Many mail clients can be configured to send out the user's SMIME cert as an attachment so that their correspondents will have a copy of it after receiving a single unencrypted message.  This allows the folks at the other end to use that cert to send an encrypted message to the user.

The tough part is getting folks on the far end to generate their own keys & cert and getting that cert into the hands of your users so that they can send encrypted messages outbound.  Sorry to say, but getting that cooperation from the far end may not be easy...


Are there risks associated with connecting to a public hotspot?

As long as the user connects as a public network, there isn't any more connection connecting to an open WiFi network than there is connecting to an unknown wired connection.  If the user says it is a private or work network, then a lot more issues can occur.

Ultimately, it is the job of a firewall to prevent access to a system when it is attached to a network and a well configured firewall should prevent an issue when attaching.  Exactly how you handle that configuration is significantly more complicated.

The trick comes down to what services the computer makes available when connecting to a network.  Services like remote desktop, file and printer sharing, telnet, or whatever services might be on the system may be running.  If they are, then any system that can connect to the computer will be able to try to access them.

Disabling those services or firewalling the system prevents that, but you need to make sure you don't block necessary services while dealing with the unwanted services.


Practical usage of CRL(Certificate Revocation List)

Does the CA need to mandatorily publish the new CRL file even though there are no new certificates that have been compromised since the last CRL published?

yes. CRL has fixed validity period determined by ThisUpdate and NextUpdate fields. After NextUpdate timestamp, CRL is considered expired and client application will return RevocationOffline chain validation status.

If CA needs to publish the CRL's periodically, how do I identity whether there are new records added to the revocation list or not?

by periodically checking for new CRLs and examining them.

Is timestamping the CRL file a mandate or an optional feature?

in practice -- mandatory requirement.

Do All CA certificates need to use EKU(Extended Key Usage) set to CRLSign for the purposes of issuing the CRL's in the future?

yes.

Also, If the CRL validity is a week and published every Sunday, what would be implications on security if a certificate is compromised on Tuesday

then this will be detected by clients no later than upcoming Sunday.

As an end device, the next CRL will be only looked at after Sunday and so I would have accepted the connection from the compromised party for the last 5 days.

it highly depends on client implementation. Most clients will cache once downloaded CRL for the CRL validity duration and won't download it again until it expires. Some clients, such as Microsoft CryptAPI client implements E-tag and Max-age HTTP headers that allow HTTP CDP endpoint polling without having to download CRL if it wasn't changed on HTTP server. Once new CRL is published to HTTP endpoint, E-tag will change and CryptoAPI client will forcibly re-download CRL, so detection of newly revoked certificates occurs faster. It is
Another option is to use Delta CRLs that include only revoked certificates since last Base CRL was published. Delta CRLs are meant to be smaller in size and can be published frequently, say every day.
Depending on use case, clients may utilize OCSP stapling (when we talk about online TLS connections), when TLS server obtains OCSP response for its own certificate and staple in response during handshake. But this vary between certificate usage scenarios (hence certificates are not only TLS, there are miriads of other usages).


Attacks on RSA without knowledge of either key

I don't think anyone has ever demonstrated finding the entire public key—all (say) 2048 bits of n—but cryptographers demonstrated distinguishing public keys (popular exposition) by solving the German tank problem on ciphertexts to break the privacy claims of PLAID, the Protocol for Lightweight Authentication of IDentity developed by the Australian Department of Human Services.
The basic idea of PLAID is an identification protocol for smart cards:  When you put your smart card into a legitimate hospital terminal, the terminal proves to the smart card that it represents legitimate hospital, and the smart card identifies you to the terminal, and then the terminal dispenses health care at you like a vending machine.
PLAID is intended to provide privacy from malicious terminals:  If you put your smart card into a malicious terminal which cannot prove to your smart card that it represents a legitimate hospital, the terminal should be unable to distinguish your card from any other card.
However, in the protocol, the smart card sometimes reveals RSA ciphertexts under a public key n stored on the smart card—even to illegitimate terminals.  Every ciphertext under the key n is a nonnegative integer c < n, but since n is different for each key, the upper bound on ciphertexts is different for each key.
Specifically, a malicious terminal can use the same methods used by British statisticians during World War II to estimate the number of German tanks by examining the serial numbers c of captured tanks which are all less than the total number n of tanks.  The granularity of this estimate turns out to be enough to distinguish two smart cards' public keys simply by examining a sufficient number of ciphertexts made by them.
Not all public-key cryptosystems have this property—for example, most public-key encryption and signature schemes that rely on the difficulty of computing discrete logs in a single standard group, like X25519 or Ed25519, tend to naturally provide the various related notions of key privacy for public-key encryption, anonymous signatures, or key indistinguishability for signatures (paywall-free).


Understanding ret2libc return address location

This is because on x86, stacks grow downwards (towards lower addresses), but buffers are filled upwards (towards higher addresses):
When writing out of the buffer, you are clobbering the return address of the stack frame above, at a higher address.
The ret instruction will then pop the return address off the stack and continue execution at the beginning of system. Then, system will pop its arguments off the stack, and upon returning, pop the address of the next function off the stack, i.e. the stack shrinks as you go through the chain, and the stack pointer grows larger.
The reason that the address of /bin/sh can be written on the stack lies in the calling convention used by gcc on x86_32 linux, which is very close to the System V calling convention (see Figure 3-15). In contrast, on x86_64, the first arguments are passed in registers (rdi, rsi, rcx), so you would need a pop rdi; ret gadget before you can return to system.
To understand the order of the values written to the stack, let's look at a single stack frame:
         high addresses

       +----------------+
       |                |
       | arguments      |
       |                |
       +----------------+
esp -> | return address |
       +----------------+
       |                |
       | locals         |
       |                |
       +----------------+

         low addresses

Putting this together to a payload, we get:
         high addresses

       +----------------+                -+
       | arg0           |                 |
       +----------------+                 | stack frame of system
       | return address | exit            |
       +----------------+                -+
esp -> | return address | system          |
       +----------------+                 |
       |                |  ^              | stack frame of victim
       | buffer         |  | overflow     |
       |                |  +              |
       + . . . . . . . .+                 :

         low addresses

The buffer being overflown is a local buffer in the victim function, and its return address gets overwritten. The ret instruction will pop the return address off the stack into eip, so execution will continue in system.
At this point, the stack looks like this, with space below esp usable by system for its locals (actually, the diagram is not quite correct, as system pushes locals, the stack pointer will of course decrease):
         high addresses

       +----------------+                -+
       | arg0           |                 |
       +----------------+                 | stack frame of system
esp -> | return address | exit            |
       +----------------+                 |
       |                |                 |
       | locals         |                 |
       |                |                 |
       + . . . . . . . .+                 :

         low addresses

To access the argument, system will use the [reg+displacement] addressing mode, to access [esp+4]. At the end of its execution, it will call ret, which will continue execution in exit.


Should I change the default SSH port on linux servers?

The Internet is a wild and scary place, full of malcontents whose motives range from curiosity all the way to criminal enterprise. These unsavories are constantly scanning for computers running services they hope to exploit; usually the more common services such as SSH, HTTP, FTP, etc. The scans typically fall into one of two categories:

Recon scans to see what IP address have those services open.
Exploit scans against IP addresses who have been found to be running a specific service.

Considering how large the Internet is it is typically infeasible to look on every port of every IP address to find what's listening everywhere. This is the crux of the advice to change your default port. If these disaffected individuals want to find SSH servers they will start probing each IP address on port 22 (they may also add some common alternates such as 222 or 2222). Then, once they have their list of IP addresses with port 22 open, they will start their password brute force to guess usernames/passwords or launch their exploit kit of choice and start testing known (at least to them) vulnerabilities on the target system.

This means that if you change your SSH port to 34887 then that sweep will pass you on by, likely resulting in you not being targeted by the followup break-in.

Seems rosy right? There are some disadvantages though.

Client Support: Everybody who connects to your server will need to know and use the changed port. If you are in a heavily managed environment, this configuration can be pushed down to the clients, or if you have few enough users it should be easy to communicate.
Documentation Exceptions: Most network devices, such as firewalls and IDSes, are pre-setup for common services to be run on common ports. Any firewall rules related to this service on this device will need to be inspected and possibly modified. Similarly, IDS signatures will be tweaked so as to only perform SSH inspection on port 22. You will need to modify every signature, every time they are updated, with your new port. (As a data point there are currently 136 VRT and ET snort signatures involving SSH).
System Protections: Modern Linuxes often ship with an kernel layer MAC and/or RBAC systems (e.g. SELinux on RedHat based or AppAmor on Debian based) and that are designed to only allow applications to do exactly what they're intended to do. That could range from accessing the /etc/hosts file, to writing to a specific file, or sending a packet out on the network. Depending on how this system is configured it may, by default, forbid sshd from binding to a non-standard port. You would need to maintain a local policy that would allow it.
Other Party Monitoring: If you have an external Information Security division, or outsource monitoring, then they will need to be made aware of the change. When performing a security assessment, or analyzing logs looking for security threats, if I see an SSH server running on a non-standard port (or an SSH server on a non-UNIX/Linux for that matter) I treat it as a potential backdoor and invoke the compromised system part of incident handling procedure. Sometimes it is resolved in 5 minutes after making a call to the administrator and being told it's legitimate, at which point I update documentation, other times it really is badness that gets taken care of. In any event, this can result in down-time for you or, at the least, a nerve racking call when you answer your phone and hear, "Hi, this is Bob from the Information Security Office. I have a few questions for you."

Before changing your port you need to take all of this into account so you know you're making the best decision. Some of those disadvantages may not apply, but some certainly will. Also consider what you're trying to protect yourself against. Often times it is simply easier to just configure your firewall to only allow access to 22 from specific hosts, as opposed to the whole Internet.


See this question for a sense on how secure VMs really are. How secure are virtual machines really? False sense of security?

A good general rule is to not allow the VMs to communicate with each other through networking. This means proper measure to segregate network access should be enforced.

If you notice a compromise on any of the VMs, immediately nuke the VM and setup again from a known safe point. This should be relatively easy to do with virtualization compared to an actual server.

Besides that, make sure that your hypervisor is kept up-to-date to prevent any known exploits against the hypervisor from allowing a compromise to break out of the VM and affect the host or other VMs.