How does a company achieve compliant PCI MFA?

All access from out-of-scope environments to the in-scope environment needs to use MFA. Typically, businesses deploy a jump (bastion) host in a VLAN which is accessible from the out-of-scope environment. MFA is implemented to access the jump host. Once the end user has authenticated using MFA to the jump host, they can have direct access to other in-scope systems using username/password only. Alternatively, one could implement MFA on access to any in-scope system but this is not as simple.

Who checks this compliance?

Depending on the volume of transactions your business handles and your merchant or service provider level, the validation can be through self-assessment or through on-site technical validation by a QSA. Your acquirer should indicate if you can self-assess or need an assessment by a QSA.


What the most trustworthy way to demonstrate digital File Integrity?

It depends on what whether you really mean the "most trustworthy". As with many aspects of digital security, there is a sliding scale of strength / reliability vs usability / feasibility. I think some important questions to consider are:

Who are your users? To what extent do they care about proof of file integrity?
Even if the users don't care, how important is it to you or your service that files are transferred completely and unaltered?
How can you balance the usability of such a system with security? (If the users have to go through some elaborate private key / certificate generation hoop jumping process, this might not be worth it for the added security, or it may well be depending on sensitivity)

Verifying the integrity of transferred data is an incredibly involved science, and it scales from the most basic checksum all the way up to the most complex methods. It all depends on what your needs are.


SSL/TLS: Version Change during Renegotiation or Resumption?

The current TLS standard is not very clear on how versions should be handled. Annex E.1 contains some information, from which we can see that the implicit idea is that the selected version depends on what the client and server support, not on what the client and server may elect to use on a whim. If a client supports up to TLS 1.2 and a server up to TLS 1.1, then they should use TLS 1.1, always. As such, there should be no question of "changing the version" when resuming a session, or renegotiating.

There are several version fields:

Each "record" has a version field.
The ClientHello message contains the highest version supported by the client.
The ServerHello message contains the version that will be used on this connection.

Supposedly, the client will send its first ClientHello as a record bearing a version number 3.x for some value of "x"; 3.0 will maximize interoperability. Once the server has responded with a ServerHello stating that version 3.y will be used, then both client and server must use 3.y records. This makes version jumps somewhat delicate during a renegotiation. Also, CBC-encrypted TLS 1.1+ records are not compatible with SSL 3.0 / TLS 1.0 records (because of the additional per-record IV), so record-level versions are important once the first ChangeCipherSpec has been sent/received.

For a session resumption, annex E.1 states that:

  Whenever a client already knows the highest protocol version known to
     a server (for example, when resuming a session), it SHOULD initiate
     the connection in that native protocol.

from which I infer that if the previous session used version 3.y, then the client should use records with version 3.y. However, nothing prevents it from advertising an higher version number in the ClientHello.

Also, derivation of the master key into encryption and MAC keys uses the TLS PRF, which depends on the protocol version (TLS 1.0 and 1.1 use the same PRF, but not SSL 3.0, and neither TLS 1.2). Resuming a session with a different version is looking for trouble.

The whole area is murky. See for instance this Mozilla/Firefox bug report. In my experience, the following rules should be followed to minimize issues:

Rules for the client:

Send the first record as version 3.0.
Always advertise in the ClientHello the maximum supported version (e.g. 3.3 for TLS 1.2).
When the server responds with a ServerHello, use the version sent by the server as new version for all subsequent records, cryptographic computations, and protocol details.
Once the server has sent a ServerHello, enforce incoming record versions: subsequent records from the server should use that version. If a record from the server advertises another version, abort.
When renegotiating, if the server tries to use another version than previously, abort.

Rules for the server:

Ignore the version on incoming records, during the initial steps of the connection.
Once you have sent your ServerHello, enforce record versions: all subsequent records from the client should use that version.
When resuming a session, reuse the same version, as long as the version in the ClientHello allows it; otherwise, do a full handshake (e.g. if the previous session was TLS 1.1 and the new ClientHello says 1.2, resume with version 1.1; if the previous session was TLS 1.1 and the new ClientHello says 1.0, do not resume, do a new full 1.0 handshake).
When renegotiating, verify that the version advertised in the new ClientHello is compatible with the current version -- but do not change the current version. If the first handshake was 1.1, the second handshake will be 1.1, even if the new ClientHello says 1.2.

It is pretty much guaranteed that there are some widely deployed implementations which get it wrong at some point.


Recovering data on unallocated space from FAT16 USB drive

Unallocated space of all zeroes is common in a new or cleaned drive. A used drive will generally have left over fragments and deleted files.

Zeroes are zeroes, there is no recovering a previous value. When people speak of recovering files, they are referring to reconstructing actual data from the unallocated space. You apparently don't have any data to recover.

Concentrate your efforts on the data you do have.


Non-standard OIDC flow: How safe is this?

I can't see a vulnerability in the described flow. However, a lot of much smarter and competent people work on standards, such as OIDC. And there is probably a reason why they designed it the way they did. So I would argue using a non-standard flow is dangerous, even if the problem is not immediately obvious to us.


GHOST bug: is there a simple way to test if my system is secure?

It appears you can download a tool from the University of Chicago that will let you test your system for the vulnerability.

This does not repair or restart anything it will only tell you if your system is vulnerable.

$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]

Running this on one of my remote servers I get:

user@host:~# wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
--2015-01-27 22:30:46--  https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
Resolving webshare.uchicago.edu (webshare.uchicago.edu)... 128.135.22.61
Connecting to webshare.uchicago.edu (webshare.uchicago.edu)|128.135.22.61|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1046 (1.0K) [text/x-csrc]
Saving to: `GHOST.c'

100%[============================================>] 1,046       --.-K/s   in 0s

2015-01-27 22:30:48 (237 MB/s) - `GHOST.c' saved [1046/1046]

user@host:~# gcc GHOST.c -o GHOST
user@host:~# ./GHOST
vulnerable

The source code of that script looks like this next code block but you should inspect the origin code first anyway. As others have pointed out, if you are arbitrarily running code off the internet without knowing what it does then bad things may happen:

/*
 * GHOST vulnerability check
 * http://www.openwall.com/lists/oss-security/2015/01/27/9
 * Usage: gcc GHOST.c -o GHOST && ./GHOST
 */

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

Edit:
I've added an ansible playbook here if it's of use to anyone, if you have a large number of systems to test then ansible will allow you to do it quickly.

Also, as per discussion below, if you find your servers are vulnerable and apply available patches, it is highly recommended that you reboot your system.


Shared hosting-- whose responsibility is dealing with known vulnerabilities?

On most shared hosting:

it's the responsibility of the host to configure their machine so that one tenant can't interfere with another tenant
it's the responsibility of the host to update any shared infrastructure, like the OS, routers, etc. If the shared hosting have shared web server or database, it's also the host's responsibility to keep them up to date.
it's the responsibility of the tenant to keep their web applications (e.g. Wordpress) up to date.
it's generally the responsibility of the tenant to implement WAF rules when necessary
it's usually the tenant's responsibility to set their file permissions correctly, for instance if you set your PHP files chmod 777 or if you write sensitive data to shared directory like /tmp, then you're just asking for a lateral attack. Some better configured host configure each tenant to have their own /tmp, but you shouldn't rely on this being the default.


Could a hardware keylogger be detected through measuring USB micro voltage?

In theory, it's possible, but is very, very hard:

USB is, by definition, a serial bus. So you can have more than one device on a single USB bus. This defeats any measurement.
Monitoring minute changes on power consumption on a bus is not easily done, and it's easier to just open up the keyboard and search for a keylogger.


Is AIK from the TPM publicly accessible?

Actually, AIK's are not sent to generic servers for authentication. There is an extra level of indirection: the AIK is used to sign a CK (certified key), and the CK is used for authentication. See TPM: signing key or Attestation Identity Key? But if a computer with a TPM authenticates using the TPM to some remote server, then the remote server does learn the AIK. (The public key, of course — an AIK is actually a key pair and the private part never leaves the TPM.)

Note that an AIK does not identify a TPM in a way that allows tracking it across different usages. A TPM can generate multiple AIK's. The expectation is to generate a separate one for each service that the computer is enrolled in (e.g. one to validate connections to the enterprise network, one to authenticate to a bank, etc.). Different AIK's from the same TPM cannot be identified as related (unless the AIK enrollment service did a bad job).

Also, note that the TPM itself does not communicate. The TPM makes integrity measurements of the system state (i.e. it verifies that the CPU and memory are in an approved state), and it holds keys with which it can encrypt and sign these measurements and other data. What gets transmitted over the network is the responsibility of applications running on the CPU's operating system. Choosing which AIK to use for which communication partner is the responsibility of the application (and possibly the operating system's, which performs access control so that applications can only make certain requests to the TPM), it's outside the hands of the TPM.


What is the added security of “PermitRootLogin no” alone?

The setting PermitRootLogin no alone does not prevent su - after
logging in as a normal user.

Your statement assumes that any system is configured in such way that all users in this system are allowed to use sudo and that any user is allowed to executed any command via sudo. This may be the case in some systems if administrators don't care about security. But if administrators do care, sudo is configured very fine grained, only some users are allowed to use sudo, and in via sudo they are allowed to execute only some commands. The number of users that are allowed to execute su via sudo will be kept as low as possible, and this sudo permission will be given for a relatively short period of time. In case of on premises server one would login locally as a root and give sudo su permission to some user. In case of remote or virtual server an administrator would give sudo su permission via corresponding remote control tool. After the work that required su permission is done, this permission would be revoked again.
Thus, if an attacker was able to log in via ssh using some non-root account, and this user has very limited permissions in sudo, or even no sudo permissions at all, then the potential problems will be usually relatively limited compared to what an attacker with root permission could do.


Publicly available Botnet Traffic dataset

One malware that I know is available and used for building botnets is kaiten.c


How secure is GnuPG conventional encryption (with defaults)?

It depends on the quality of your pass phrase really. If that is long enough, generated securely and kept secret such as 128 bits from a random device, very secure:

> dd if=/dev/random of=- bs=1 count=16 | md5sum
d41d8cd98f00b204e9800998ecf8427e  -

GPG will, in this mode, encrypt with CAST5, but you can use a different cipher, such as AES256. (To make use of 256 bits, take two MD5 outputs as the key, or create 32 Bytes of random data some other way.)


Securing data transfer between public network and personal accounts

This is the classic use case for a Virtual Private Network (VPN).

If you're technically savvy, you could set up your own VPN server at home. Strongswan is the one packaged with Ubuntu.

Or, you could use a third party VPN provider. Obviously though you have to find one you trust with your data. Note also that they won't typically get you inside your home network, they'll just get you to their network.


Protecting Password Hashes with Stored Procedures?

The scheme you describe is similar in concept to making a dedicated password verification server (local server, not open to the world at large) with its own, completely distinct database for the storage of hashed passwords. This can work. Actually you already have that under the guise of "system integration" when the user accounts are mapped, for instance, to an Active Directory server, or local Unix accounts.

Using a stored procedure in the database for that, relies on the database enforcing appropriate isolation -- a somewhat risky bet, since you are envisioning a situation where the attacker gets to include his own SQL statements.


Is there a criteria for allowing or disallowing the execution of bash scripts as root with sudo?

A few options:

Read through the script once, make it r-x, change ownership, and add
the script to the sudoers entry for the developers
Require that the
developers use sudo in the script, rather than on executing the
script, and whitelist commands in the sudoers file
Trust your developers and accept the risk

As far as extracting commands, there's only one right way to do that: read the script. You could turn on auditing or read the command history or something, but if it's truly malicious, those can't be relied upon.


Why is it said that we can obtain a digital signature from a CA when all we obtain from the CA is a certificate?

It is a bit oversimplified and mixed together here.
We need to distinguish a few things:

The CA issues a digital certificate with a digital signature to you
You can use the signed digital certificate to sign other data (depending on the certificate, that can be TLS handshakes, e-mail signatures and so on).

You can obtain a digital signature from a reputable certificate authority such as Sectigo

What they mean here is that a certificate authority takes your certificate signing request (CSR), adds or removes certain fields from it, puts it into a slightly different format (a "to be signed certificate") and adds a digital signature to it, which makes it a valid, trusted X.509v3 certificate that you can use to sign other things.

Shouldn't I just be receiving the digital signing certificate from the CA and creating the digital signature by myself?

Yes, this is exactly how it works.


Why does GnuPG shrink my file after elgamal encryption?

GnuPG is applying compression before encryption for reasons of efficiency (compression is cheaper than encryption) and security (compression might prevent some attacks introduced by flaws in the OpenPGP design).

As you're encrypting a series of nothing, this can be compressed very well. Consider using /dev/urandom instead.

You can disable compression using --compress-algo none, but be aware this is not a reasonable default for all-day use.


What expertise is required to create an Windows intrusion report?

Since you mention you need to prove intrusion for legal purposes then it sounds like you may need to check into a certified computer forensics investigator.  Hopefully the system is turned off (to avoid damaging evidence) until you decide whether or not to pursue forensics.

Here are a couple of links that might be helpful:

http://en.wikipedia.org/wiki/Computer_forensics

http://www.computerforensicscompanies.com/


What are non-standard ports and protocols

A non-standard port just means a service running on a port other than its default, usually as defined by the IANA port numbers registry.

Running a service on a non-standard port doesn't really mean anything for security. It may reduce the amount of noise that a defender has to deal with in terms of automated scanning on the internet, where bots usually target common standard ports for vulnerabilities. Moving SSH from 22 to, for example, 55522 might reduce the number of drive-by brute-force attempts.

In order to find all services running on a system, one can use nmap or a similar tool. Here's an example command:

nmap -sS -A -Pn -T4 -p1-65535 <host>

Let's break these flags down:

-sS tells nmap to perform a TCP SYN scan.
-A enables a range of options related to OS detection, service detection, and script scanning. This is particularly important for identifying services on non-standard ports, as it actually talks to each open port to work out what the service is, rather than guessing based on the port number.
-Pn tells nmap not to use ICMP ping to check if the host is up. If the target blocks ICMP requests, this will result in nmap assuming that the host is down.
-T4 sets the speed of the scan. Valid arguments are 0 to 5. There's no reason to use anything but 4 here in my experience - anything less is just slower, and 5 reduces the accuracy of the scan because it doesn't wait long enough for TCP ACK replies.
-p1-65535 sets the port range. As we're hunting down both standard and non-standard ports, this is the only way to cover everything. You can also use -p- as shorthand for this.

The results of this command should show you any ports that are open and what services are running on them. From there it's an open question as to what protocols are considered a potential avenue of attack. SSH or Telnet might be useful, but unless they use a weak username and password it's probably not interesting. They might run a HTTP server on a non-standard port, with a vulnerable web application being served, and that might be of interest too. The possibilities are endless.


From some malware analysis lab. every day more then 68 % of malware goes undetected by any anti-virus.

How did you detect this one?

You may ask Fireeye an analysis of this malware.


Using unique email address for online signups?

What you are thinking of should provide better security than using a single email address for everything. However, it is a major pain to manage. Major inconvenience is the worst enemy of good security because you will eventually break down and stop following your system.

What you should do is separate your identities. For example, there is no sense in using the same email address for both your Facebook or Twitter account and your bank account. Even worse, there is no sense is using the same email address for personal correspondence and business matters. For example, this guy was using the same email address for both his personal Amazon account and his startup's AWS account. It is generally a good idea to keep distinct identities for this purposes.


Decrypt and then re-encrypt all requests to the internet at firewall level

There are lots of information about this topic on the internet and on this site, so it does not make sense to repeat everything:

a short introduction on how this works you'll find at http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/
and a discussion of the associated problems at What security risks are posed by software vendors deploying SSL Intercepting proxies on user desktops (e.g. Superfish)


I think you might be mixing a couple of risks up here.

If you are surfing a site and purchasing goods from them, then they will inevitably have access to any data you enter into their site.  This would include the username/password that they use on the site and likely any payment card details that you use to pay for things on their site.  This is because that data needs to be transferred to them to complete the transaction (no JavaScript needed)

As you say if they use a 3rd party site (e.g. paypal) to process the payment they your credentials for the payment site shouldn't be accessible by the shopping site, although it's here that if they were malicious they could try do something like redirect you to a site which looks like Paypal but isn't...

In terms of accessing your banking details, again, as long as you're not using the same credentials on the banking site as on the shopping site, they shouldn't be able to access your banking credentials.


Why does Authorization Code flow need the authorization code?

I suppose that this artictle should explain the most of your doubts.

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611

Shortly speaking if you use implicit flow you are vulnerable to token leakage through URL (because URLs are logged into HTTP server logs) or token injection (where client is not able to check if the sender of the token is the legitimate token issuer).

Including code removes access token from the query string (so the token leakage vulnerability), because, to get the access token, you need to make additional backend request to Authorization Server (AS) which you already know is legitimate. To secure more, you should use it with PKCE to ensure that noone have stolen the code PKCE is verified by Authorization Server and only if is valid AS will return access token to the client.

So in summary, token is sent only in backend. Token issuer (AS) is validating if client is legitimate checking the code_verifier (PCKE). Token is provided only as a response for a request to legitimate AS. Having this both sides are secured.


A hierarchical public key infrastructure is when some Certification Authority (CA) issues certificates to a lot of sub-entities: the CA signs certificates to guarantee the link between an identity and the public key owned by that entity. The PKI is hierarchical in that there are few CA and each CA signs certificates for a lot of people.

In a Web of Trust, everybody is a CA. Every user signs certificates for whoever he wants.

In mathematical languages, a hierarchical PKI naturally implies an acyclic certification graph, usually a tree: trust percolates down the tree from a single root CA, or a small set of root CA. Whereas the WoT is a super-connected generic graph with cycles and many paths between any two points.

Politically, the hierarchical PKI is a military-inspired structure, with a central chain of command; while the WoT is an anarchist hippy utopia in which trust emerges semi-magically from the assembled people (or the mob, from another point of view).


How does the password protect the data keys on an encrypted HDD / SSD?

I like the disk encryption wiki from valinux. It is reasonable to assume most disk encryption schemes work in a very similar manner, and may be implemented entirely based on well-established open standards.

I would go so far as saying that if you discover anything proprietary in a disk encryption scheme, to stay away from it since it could very well conceal a backdoor. PBKDF2 is a fairly popular and standards based key derivation function. AES is most likely the encryption algorithm of choice, preferably with 256 bits, and if you want one of its stronger variants, look for GCM.

Copied some informative diagrams below from the wiki.

╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                        ╭┈┈┈┈┈┈┈┈┈┈┈╮
┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key  ┊
╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯,───⎝   function  ⎠     ╰┈┈┈┈┈┬┈┈┈┈┈╯
╭──────╮            ╱                               │
│ salt │───────────´                                │
╰──────╯                                            │
╭─────────────────────╮                             ▼         ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
│ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊
╰─────────────────────╯                                       ╰┈┈┈┈┈┈┈┈┈┈┈┈╯

                          ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
                          ┊ master key  ┊
  file on disk:           ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
 ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐        │
 ╎╭───────────────────╮╎        ▼          ╭┈┈┈┈┈┈┈┈┈┈╮
 ╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊
 ╎╰───────────────────╯╎                   ╰┈┈┈┈┬┈┈┈┈┈╯
 ╎┌───────────────────┐╎                         ▼            ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
 ╎│ encrypted file    │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file  ┊
 ╎│ contents          │╎                                      ┊ contents       ┊
 ╎└───────────────────┘╎                                      └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
 └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘

In a nutshell:

Passphrase you will need to remember, and enter in order to mount the disk or partition.
Passphrase churned through key derivation function to generate master key. There should be enough iterations such that it takes the function ~1s to process on your computer.
Master key then be used to decrypt a keystore file, which contains a file key that is actually used to actually decrypt or encrypt your disk data.

Q. Why not have a master key that directly encrypts your data, why separate master key and file key?

A. If you decide to change your passphrase you have then have to re-encrypt your disk for the master key only scheme. On the other hand, if you have a separate master and file key, then if you change your passphrase you only need to re-encrypt the file key.


I'm new to this, so any help would be greatly appreciated

This is actually an issue were not only newbies despair. The issue is complex and depends on specific implementations and bugs in the TLS libraries involved. Thus it is not really your fault that it does not work as expected. I hope the following explanation can be understood:

There are actually several trust path to a trusted certificate. What the server sends as certificates is this:

#0 CN=www.google.com SAN=DNS:www.google.com
#1 CN=Google Internet Authority G2
#2 CN=GeoTrust Global CA

The last certificate is signed by #3 OU=Equifax Secure Certificate Authority which is not included in the chain sent by the server.

The NSS library used in Chrome and Firefox starts at the top and checks for each certificate if it can find a trusted CA which signed this certificate, i.e. a certificate which exists in the local trust store. It will stop with the validation at certificate #1, because it has a local certificate for GeoTrust Global CA which can be used to validate certificate #1. Thus it is done with validation and ignores certificate #2.

OpenSSL up to version 1.0.1 (at least up to 1.0.1p) works different. It will look at the whole chain and try to find a trust anchor for the last certificate in the chain. Since often servers send the root certificate inside the chain (which is wrong) it will eliminate all self-signed certificates from the chain before it will look for the trust anchor (since root certificates are usually self-signed).

In this case the certificate #2 for "GeoTrust Global CA" is not a self-signed certificate (signed by Equifax) and will not be removed. It will thus try to find the issuer for this certificate #2 "GeoTrust Global CA" in the trust store to built the trust chain. If you included the certificate #3 (Equifax) in the trust store (file name in verify parameter) then all is fine and the validation succeeds. If you only include the "GeoTrust Global CA" in the trust store the validation fails because this is not the correct trust anchor for certificate #2. OpenSSL 1.0.1 is too dumb to realize that this would be the perfect trust anchor for certificate #1 and thus the validation fails.

The situation was changed finally (more than 3 years after I reported this kind of bug) in OpenSSL 1.0.2. If the first attempt to validate the chain fails it will remove the last certificate from the chain (certificate #2) and retry. In this case it will succeed. That means if you would use a version of Python built with OpenSSL 1.0.2 then it should be fine. For more details about the different ways of validating the trust path see the last comment at OpenSSL bug#3621.


Ordering of the PATH environment variable

If there's a directory in the search path where someone you don't trust could write files, then the directory should not be in the path, period.

The order only matters if a command is present in more than one entry in the list. So the only case to consider is when someone trustworthy arranged to have one entry shadowing another, deliberately or not.

If it was deliberate, then the order should be to search the directories in order of local management: typically this means first ~/bin or equivalent if running under an account that has such a directory (not applicable to most system accounts), then /usr/local/bin, then the directories managed by the package manager /usr/bin/ and /bin.

In principle, there should not be any shadowing between sbin and bin directories. sbin directories are for commands that are only useful to a system administrator (this is why these directories are normally not in the path of users other than root). In principle there could be a command name for which you want to run a different executable as root, so sbin directories should be ahead of the corresponding bin directory — otherwise …/sbin/foo would never be executed since it would be shadowed by …/bin/foo for everyone.

The only case when there is an ambiguity is if there may have been accidental shadowing. In that case there isn't an obvious answer. Generally, it doesn't make much sense to put /usr/local/bin after /usr/bin: if you don't want the local administrator's choice of commands, then don't put /usr/local/bin in the search path at all (and remove /usr/local/lib from the library search path, etc.).

Between /usr/bin and /bin, in principle, one might want to shadow an executable from /bin (small version for boot time only) with one from /usr/bin (large version from a separately-mounted /usr partition), but tiny root partitions with a separate /usr are a very uncommon practice these days. It was a more common practice in the days when operating systems used significant disk space, but even then shadowing utilities in /bin with versions from /usr/bin was uncommon. The other order, putting /bin first, has a slight performance benefit (/bin is usually a lot smaller). On most systems there's no strong reason to prefer one order over the other. (On some systems /bin and /usr/bin are the same directory, but you shouldn't assume that unless you only ever work on recent versions of one of the distributions that do this.)

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin (or PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin) is usually the right setting for jobs running as root, and PATH=/usr/local/bin:/usr/bin:/bin for jobs not running as root. I don't see any good reason to deviate from that (except for the /usr vs. / inversion) except to cater for local variations (e.g. a site-specific directory on *BSD distinct from the packages installed to /usr/local). Security-wise, it doesn't matter, but functionality-wise, putting /usr/local ahead of /usr and / is either indifferent or necessary.


how to arpspoof when the AP prevent clients from seeing each others?

Except for very specific cases (TDLS) all traffic between clients will go through the access point. So arp spoofing will never make a client send data directly to you.


Is it safe to use SHA-512 to identify credit card?


Is Certificate validation done completely local?

It is almost true. :) But not entirely.

A certificate can be revoked in case of a compromise. The only way to discover if a certificate is revoked at any given time is basically contacting the CA that issued it. Any info signed in the certificate itself (fit for offline validation) will be valid for a revoked cert.

There are two protocols for checking revocation, CRL and OCSP. A CRL is just a list of revoked certificates published by the CA, and OCSP is kind of a web service, but the idea is the same, any client doing cert validation should have a look and check if the certificate happens to be revoked.

In fact, a fairly common flaw in cert validation implementations is that they don't check revocation.


Self-signed certificates in mobile and desktop applications - are they enough?

For the safety of the data your key matters. As most people do not know your (public) key certificates are a way that some trusted instance can verify your key and sign a certificate "the key indeed belongs to domain X".

For when you don't need a public CA, it is to costly, or unavailable for other reasons, you have the option to create a self-signed certificate which is signed with the key itself. Users have no direct way to verify it as they do not know the key and have no indication if it is your self-signed certificate or some rogue one.

But there IS a way to trust the certificate and that is validation via another way. Look at the certificate details: There is a fingerprint which can be compared against the fingerprint of the right certificate. If they match, everything is okay.

When you use self-signed certificates just for yourself it is easy to do this verification as you know both sides of the connection. When you are writing an app you can use a hardcoded fingerprint to verify the certificate, which may even be more secure than checking against a CA (because you only need to trust yourself).

What you lose is flexibility. When you want to change the key you need to change the certificate fingerprint in your application. Using the CA system you just let a CA trusted by your application sign the new key and the application will accept it.

To answer your question: They are safe as long as you verify them in some other way which works without a CA. When you disable checking certificates you are way less secure.


How is the stack protection enforced in a binary?

On a linux box with an Intel CPU, lets say I compiled by binary with -fstack-protect-all.

Since it is not explicitly stated, it will be assumed that this refers to ELF binaries compiled using GCC with the -fstack-protector-all argument.

GCC Stack Protection Mechanisms

-fstack-protector-all is an extension of -fstack-protector:

  -fstack-protector

  Emit extra code to check for buffer overflows, such as stack smashing          attacks. This is done by adding a guard variable to functions with vulnerable objects. This includes functions that call alloca, and functions with buffers larger than 8 bytes. The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, an error message is printed and the program exits.

  -fstack-protector-all

  Like -fstack-protector except that all functions are protected.

The aforementioned "guard variable" is commonly referred to as a canary:

  The basic idea behind stack protection is to push a "canary" (a randomly chosen integer) on the stack just after the function return pointer has been pushed. The canary value is then checked before the function returns; if it has changed, the program will abort. Generally, stack buffer overflow (aka "stack smashing") attacks will have to change the value of the canary as they write beyond the end of the buffer before they can get to the return pointer. Since the value of the canary is unknown to the attacker, it cannot be replaced by the attack. Thus, the stack protection allows the program to abort when that happens rather than return to wherever the attacker wanted it to go.1

Now to the first set of questions:

  How is this encoded into the binary? (Can I see this info using readelf? ). Is it encoded into every page/segment or is it added to the binary in one place and the loader picks it up?

The -fstack-protector-all causes the compiler to generate code in which a guard variable is pushed to all functions and checked prior to return. In other words, additional machine instructions are generated that have to do with pushing, checking and popping the stack canary.

This can be illustrated using 2 example binaries produced from the same source, in which one was compiled with the -fstack-protector-all argument and the other was not.

Source code:

int test(int i) {
    return i;
}

int main(void) {
    int x;
    int i = 10;
    x = test(i);
    return x;
}

Function from binary compiled without -fstack-protector-all:

$ objdump -dj .text test | grep -A7 "<test>:"
00000000004004ed <test>:
  4004ed:   55                      push   %rbp
  4004ee:   48 89 e5                mov    %rsp,%rbp
  4004f1:   89 7d fc                mov    %edi,-0x4(%rbp)
  4004f4:   8b 45 fc                mov    -0x4(%rbp),%eax
  4004f7:   5d                      pop    %rbp
  4004f8:   c3                      retq

Function from binary compiled with -fstack-protector-all:

$ objdump -dj .text protected_test | grep -A20 "<test>:"
000000000040055d <test>:
  40055d:   55                      push   %rbp
  40055e:   48 89 e5                mov    %rsp,%rbp
  400561:   48 83 ec 20             sub    $0x20,%rsp
  400565:   89 7d ec                mov    %edi,-0x14(%rbp)
  400568:   64 48 8b 04 25 28 00    mov    %fs:0x28,%rax     <- get guard variable value
  40056f:   00 00
  400571:   48 89 45 f8             mov    %rax,-0x8(%rbp)   <- save guard variable on stack
  400575:   31 c0                   xor    %eax,%eax
  400577:   8b 45 ec                mov    -0x14(%rbp),%eax
  40057a:   48 8b 55 f8             mov    -0x8(%rbp),%rdx   <- move it to register
  40057e:   64 48 33 14 25 28 00    xor    %fs:0x28,%rdx     <- check it against original
  400585:   00 00
  400587:   74 05                   je     40058e <test+0x31>
  400589:   e8 b2 fe ff ff          callq  400440 <__stack_chk_fail@plt>
  40058e:   c9                      leaveq
  40058f:   c3                      retq

Since stack protection is implemented via assembly code, the results of the -fstack-protector family of flags is best investigated using a disassembler like objdump. readelf technically shows this information, since the -x argument produces a hex dump of the selected section.

readelf hex dump of binary compiled without stack protection:

$ readelf -x .text test

Hex dump of section '.text':
  0x00400400 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI
  0x00400410 c7c09005 400048c7 c1200540 0048c7c7 ....@.H.. .@.H..
  0x00400420 f9044000 e8b7ffff fff4660f 1f440000 ..@.......f..D..
  0x00400430 b83f1060 0055482d 38106000 4883f80e .?.`.UH-8.`.H...
  0x00400440 4889e577 025dc3b8 00000000 4885c074 H..w.]......H..t
  0x00400450 f45dbf38 106000ff e00f1f80 00000000 .].8.`..........
  0x00400460 b8381060 0055482d 38106000 48c1f803 .8.`.UH-8.`.H...
  0x00400470 4889e548 89c248c1 ea3f4801 d048d1f8 H..H..H..?H..H..
  0x00400480 75025dc3 ba000000 004885d2 74f45d48 u.]......H..t.]H
  0x00400490 89c6bf38 106000ff e20f1f80 00000000 ...8.`..........
  0x004004a0 803d910b 20000075 11554889 e5e87eff .=.. ..u.UH...~.
  0x004004b0 ffff5dc6 057e0b20 0001f3c3 0f1f4000 ..]..~. ......@.
  0x004004c0 48833d58 09200000 741eb800 00000048 H.=X. ..t......H
  0x004004d0 85c07414 55bf200e 60004889 e5ffd05d ..t.U. .`.H....]
  0x004004e0 e97bffff ff0f1f00 e973ffff ff554889 .{.......s...UH.
  0x004004f0 e5897dfc 8b45fc5d c3554889 e54883ec ..}..E.].UH..H..
  0x00400500 10c745f8 0a000000 8b45f889 c7e8dbff ..E......E......
  0x00400510 ffff8945 fc8b45fc c9c3660f 1f440000 ...E..E...f..D..
  0x00400520 41574189 ff415649 89f64155 4989d541 AWA..AVI..AUI..A
  0x00400530 544c8d25 d8082000 55488d2d d8082000 TL.%.. .UH.-.. .
  0x00400540 534c29e5 31db48c1 fd034883 ec08e855 SL).1.H...H....U
  0x00400550 feffff48 85ed741e 0f1f8400 00000000 ...H..t.........
  0x00400560 4c89ea4c 89f64489 ff41ff14 dc4883c3 L..L..D..A...H..
  0x00400570 014839eb 75ea4883 c4085b5d 415c415d .H9.u.H...[]A\A]
  0x00400580 415e415f c366662e 0f1f8400 00000000 A^A_.ff.........
  0x00400590 f3c3                                ..

readelf hex dump of binary compiled with stack protection:

$ readelf -x .text protected_test

Hex dump of section '.text':
  0x00400470 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI
  0x00400480 c7c05006 400048c7 c1e00540 0048c7c7 ..P.@.H....@.H..
  0x00400490 90054000 e8b7ffff fff4660f 1f440000 ..@.......f..D..
  0x004004a0 b8471060 0055482d 40106000 4883f80e .G.`.UH-@.`.H...
  0x004004b0 4889e577 025dc3b8 00000000 4885c074 H..w.]......H..t
  0x004004c0 f45dbf40 106000ff e00f1f80 00000000 .].@.`..........
  0x004004d0 b8401060 0055482d 40106000 48c1f803 .@.`.UH-@.`.H...
  0x004004e0 4889e548 89c248c1 ea3f4801 d048d1f8 H..H..H..?H..H..
  0x004004f0 75025dc3 ba000000 004885d2 74f45d48 u.]......H..t.]H
  0x00400500 89c6bf40 106000ff e20f1f80 00000000 ...@.`..........
  0x00400510 803d290b 20000075 11554889 e5e87eff .=). ..u.UH...~.
  0x00400520 ffff5dc6 05160b20 0001f3c3 0f1f4000 ..].... ......@.
  0x00400530 48833de8 08200000 741eb800 00000048 H.=.. ..t......H
  0x00400540 85c07414 55bf200e 60004889 e5ffd05d ..t.U. .`.H....]
  0x00400550 e97bffff ff0f1f00 e973ffff ff554889 .{.......s...UH.
  0x00400560 e54883ec 20897dec 64488b04 25280000 .H.. .}.dH..%(..
  0x00400570 00488945 f831c08b 45ec488b 55f86448 .H.E.1..E.H.U.dH
  0x00400580 33142528 00000074 05e8b2fe ffffc9c3 3.%(...t........
  0x00400590 554889e5 4883ec10 64488b04 25280000 UH..H...dH..%(..
  0x004005a0 00488945 f831c0c7 45f00a00 00008b45 .H.E.1..E......E
  0x004005b0 f089c7e8 a5ffffff 8945f48b 45f4488b .........E..E.H.
  0x004005c0 55f86448 33142528 00000074 05e86efe U.dH3.%(...t..n.
  0x004005d0 ffffc9c3 662e0f1f 84000000 00006690 ....f.........f.
  0x004005e0 41574189 ff415649 89f64155 4989d541 AWA..AVI..AUI..A
  0x004005f0 544c8d25 18082000 55488d2d 18082000 TL.%.. .UH.-.. .
  0x00400600 534c29e5 31db48c1 fd034883 ec08e8f5 SL).1.H...H.....
  0x00400610 fdffff48 85ed741e 0f1f8400 00000000 ...H..t.........
  0x00400620 4c89ea4c 89f64489 ff41ff14 dc4883c3 L..L..D..A...H..
  0x00400630 014839eb 75ea4883 c4085b5d 415c415d .H9.u.H...[]A\A]
  0x00400640 415e415f c366662e 0f1f8400 00000000 A^A_.ff.........
  0x00400650 f3c3                                ..

Obviously this isn't very useful.

Discussion of pages and segments is not relevant since all the sections marked as executable in an ELF binary are mapped into the same segment (the text segment).

  How does the kernel/loader get this information when loading a page? How does it use it?

Use of -fstack-protector-all has no bearing on section or segment permissions.

For info about the kernel program loader see:

How programs get run
How programs get run: ELF binaries
How does the Linux kernel run a program

  What is the x86 instruction used to set the page to read-only?

Segment permissions are set by the link editor: Segment Permissions

1. "Strong" stack protection for GCC


Can the government monitor my online activity when I use VPN?

I also reside at a location, where the government blocks a number of websites related to security, and although the majority of their effort is around blocking pornographic content, I am sometimes bothered by the categorization of the content filter, or their choice of blocked sites. But it's not the blocking that bothers most, it's the fact that their Internet use is generally monitored and recorded in this country.

If your question is "can governments decrypt my VPN traffic", the answer is "depends". There is a concentrated effort by the Five Eyes intelligence agencies, and the effort (and partially its results) has been brought to us thanks to Ed Snowden (check out the Turmoil/APEX projects high-level info here (Der Spiegel magazine dumps), mainly focused on IPSEC). OpenVPN's TLS use also depends heavily on the implementation at hand, although 2048-bit RSA still is considered "out of reach" for the big guys.

Having said that, the other things that a government can do:

The government agency that monitors Internet communications knows you are using a VPN. They may interpret this as "this person has something to hide". So you've probably ticked the first box in the "surveillance target" selection scheme.
Using various techniques and patterns they would be able to ascertain and identify you from other VPN users across a variety of locations - a coffee shop, a friend's house, etc.
Using these patterns they will try and track your non-VPN activity to build a profile and to start using other methods to monitor your posts, etc.
They may try to run VPN disruptive techniques to bump you off the VPN, so your browser and/or other programs leak unencrypted packets in the immediate aftermath of the VPN going down. That will give them an idea what are you up to, e.g. hosts you're sending packets to, or even limited content.
There have been attacks on VPN traffic that may help them discover certain patterns (e.g. when do you come back home from work).

In general many commercial VPN providers do not provide you with measures that will ensure maximum protection - they're not going to give you the strongest encryption, because that's more overhead for their servers. Also, because of their commercial activities, they do attract a lot of undesired attention.

My general recommendation is to run your own server - rent a cloud server for something like $19 a month within a country that generally won't be as keen on eavesdropping on your funny cat pics surfing habits over social media. In addition to that, run a legitimate mail server on it, and a WordPress site, and if anyone asks - you're just securing your connectivity to your mail/business server. You'll be using the VPN for legitimate business reason. Not that it will be a deterrent, but may win you the benefit of the doubt.


blockchain.info exploit - Random number flaw

In many programming languages, the value of an uninitialized value is undefined but not random. When uninitialized memory would be an acceptable source of randomness, we wouldn't need actual random number generators, as we could just use uninitialized memory for that purpose.

Usually uninitialized memory gets the value which was previously written to that memory location the last time it was allocated. While it is hard to predict for the programmer what could be there, depending on how the program works and how the compiler interpreted it, it is possible that an uninitialized variable always gets the same value with every run of the program. It is also possible that the value always depends on the value of some seemingly unrelated variable. And even when neither is the case, some values are simply much more common in memory than others.


WebSockets are an upgrade of a HTTP request: they start with a "normal" HTTP request containing an Upgrade header field and after the server send a matching response the connection switches from HTTP to the WebSockets protocol.
The WebSockets protocol itself does not contain any verification of the peer, including no verification of the hostname. Thus any such verification need to be done at the HTTP level (there is none on the client side) or in case of HTTPS/WSS at the TLS level.

  Does the websocket protocol check for the host name only on start or is it controlled for each request?

Based on the information above there is no client-side hostname check for ws:// and there is only the check at the TLS level for wss://, i.e. the same check which is done for HTTPS. These checks are only done at the beginning of the TCP connection - there is no "requests" in WebSockets but there are only messages (i.e. no one response matching one request as in HTTP).

  Is it normal for a websocket or is it a bug?

It is not clear what exactly is going on but it might simply that ws:// is used and not wss://. Only wss:// contains the hostname check (during TLS handshake).


Today practically all of the information sent on the Internet is encrypted. There are only a few exceptions.

This encryption is typically unbreakable by an ISP (you see warnings in browser windows, or your applications don't work et al). They might be breakable by some governmental agents. There are only a few exceptions.

However, even an encrypted communication gives some information to a possible eavesdropper:

Only encryption still does not hide, with whom are you communicating. Snapchat communicates with some central servers in the USA.
Only encryption still does not hide, when and how many data packets did you sent.

These might be enough to collect a surprisingly many information from your communication.

If you use VPN correctly, they can't see that you are snapchatting, but they can probably see from (2) that you are chatting. They can also see that you use a VPN.

If you use snapchat without a VPN, they can see that you are snapchatting, but they can't see what.

Note, governmental security services have significantly more power than an induvidual ISP. For example, without a VPN, they can estimate with high probability, with whom are you snapchatting. Induvidual ISP can do this only if your partner is the customer of the same company (and it is mostly an irrelevant info for them - they want your money, not your chat messages).

Of course any governmental agent (or any agent with the same power) having power over the snapchat, can ask them to simply give them their logs. Thus, you have more reason to fear them. Snowden's surprising results is that they are doing it automatically, with practically all internet users of the world.


How to explain to traditional people why they should upgrade their old Windows XP device?

(updated, at the bottom - "The 1950 car")
Forget talking about security.
Don't take the "SECURITY" road. Because if you talk about "security" alone, then chances are good that they are right, and you are wrong, and they'll be clear-sighted enough to realize it.
There is no computer that is completely secure, and there is no computer that is completely insecure. It all depends on what the attack surface is.
This point of view I'm offering will be exceedingly unpopular for the IT crowd, but acknowledge that for your average elder home user (I'm of course not referring to anyone else):

the threat from an email (phishing, ransomware, etc.) is more or less the same whatever your base OS. It might be even be slightly less for 32-bit Windows XP, as the newer malwares are increasingly adopting the 64bit model. Granted, on XP a malware might be able to more easily self-elevate and wreck - in addition to everything the user deems important - also lots of things he cares not a whit about, from the OS itself to other, nonexistent users' and superusers' data. Here, the keyword is "BACKUP", not "fully patched OS" or "shadow copy" or "sandboxing". A backed-up XP is lots better than a non-backed-up Windows 10 Pro.

the threat of a local exploit is virtually nil. They probably have the password, if any, sticked to the monitor anyway.

remote exploits for XP are an extremely remote threat.

inability to access new things, sites, and services, or to install new apps, and do anything else that the user is not interested in doing anyway... is no discomfort at all.

Actually, by openly acknowledging the above, you'll probably come across as more aligned with their way of thinking, which will help getting through what follows.
So... "WHY SHOULD I ABANDON XP?"
For reasons that aren't good for the elder home user, but are so for the rest of the world, the world is moving away from Windows XP. That's a fact. It's leaving Windows 7 behind, even.
This includes applications (such as antiviruses) and web sites.
Windows XP cannot use the more advanced protocols that the new sites increasingly adopt, and there are fewer and fewer maintained antivirus databases that are compatible with Windows XP.
So, by continuing using Windows XP:

they will unable to access more and more sites (home banking ones, most surely).
they will very likely be left without antivirus protection, which is bad whatever OS you run.

It's like you own an old 1950 jalopy. It still drives, why should you change it? Well, imagine some roads no longer accept cars without the new safety measures that you cannot install. Then those roads are closed to your 1950 rust bucket. Yes, it runs, but it might not take you somewhere, for no fault of its own. Or you no longer find some spare parts. You get the drift.
If you use Windows XP in a way that's secure even under these conditions (which means "it never connects to the Internet"), for example you run the house accounting, do a little word processing, print, and have a phone or tablet for everything else... then by all means you can continue doing so.
If you're okay with being unable to access several sites, or find it no big trouble to restart after a large ransomware attack - for example because ten years ago your favorite nephew gave you a DBAN CD with one-click bare metal restore kit for Christmas, and the CD still works - then by all means continue doing so.
In all other cases one should consider to put up with a change in user interface and a usually reasonable expense, and get oneself a new PC with Windows 10.
On that note, you should also verify what applications are now being used and what their closest replacements are. The main real reason for "not changing" is in my experience unwillingness and fear of learning something new. The more the new system resembles the old, the more easily it will be accepted.
The 1950 car
Several commenters have raised very good points, and/or observed that I've been somewhat unclear. Thinking about it, the "old car" is an analogy worth expanding.
First of all no, I am not advising or condoning "no security". Gramps' car is kept in good condition and is equipped with working brakes, alarm and spare tires - a backup, and an updated antivirus.
And Gramps, being Gramps, only ever uses the car to move between the city and his summer cabin upcountry. He sees no reason to get the new Windows 10 Hybrid zero-emission vehicle; to the contrary, he's very much afraid he'll have to re-learn to drive. He doesn't drive for pleasure, to him a car is just like a hammer or a shovel - it's a tool that does its job.
To get him on the new car, I feel we need to understand and accept, first, that all the newfangled gadgets are actually worthless to him, and actually several modern threats will not run against his car because it's too ancient. He simply does too little with the thing to have a significant attack surface, and that surface is already covered by his existing system.
The arguments we have are rather that he still needs updates for something (at a minimum, the antivirus) and those updates are likely to disappear since the user base for 32-bit XP antiviruses is dwindling, and fewer and fewer companies find it profitable to cater to his demographic. When they stop altogether, his "car" will find itself with "brakes" working worse and worse. Until the day he has need of them, because a mail arrives with a new virus, and, well. At the same time, he already has access to less and less resources. What if his bank drops XP SSL browser support? It would be like the nearby gas stations more and more supplying electricity instead of gas.
Another point to consider is how to transition. The fear is having to learn an unfamiliar way of driving. But in this case the metaphor fails, because there are extensions and configurations that can make Windows 10 very close to Windows XP in look and feel. Once this stumbling block has been overcome, chances are that the transition will be actually eagerly embraced.
(I got several relatives off XP, and am only now weaning myself out of Windows 7 in Classic mode. I can relate to those elders :-) ).


What to do with .hash files when cracking WPA2

Short answer: this is the link you're probably looking for (-s specifies SSID).

Longer answer: Precomputed 'hash' files are used to accelerate password bruteforce when cracking WPA. They do this by eliminating the need to perform costly transformation of a password into an encryption key; instead somebody already computed such keys for common SSIDs and passwords and saved them into this hash file.

Note that hash table is computed for a limited number of passwords (~170K for 7 GB table in this case) and limited set of SSID (~1000 for 7 GB table).

This means two things:

They are only useful to you if your SSID is in that set;
They are only useful to check if password to your handshake is one
of the used while generating the table.

If you need to go beyond that (i.e. SSID isn't n the set or you ant to test some specific passwords) you're need to revert to bruteforce/dictionary cracking. Both aircrack-ng and coWPAtty can do this (although obviously much slower than just going through precomputed hash table).

oclHascat isn't working on your because it needs a GPU to work (a discrete one).

Precomputed hash file is orthogonal to .cap – don't try to convert them into each other, this makes absolutely no sense.


Exploiting CORS and storing the response to server

My code is working fine for reflecting the response to them. But what
  should I use to store their response to my server. Is it possible with
  javascript and html?

It should be possible with javascript.Write an Xml HTTP request in javascript and make a request to your web server that logs the request to file/database.


This isn't so much an authorization question as it is a fraud question.  The defrauder is taking advantage of the known offline condition to incur a debt that he does not intend to repay.

As a prior answer explained, there are two phases in using a credit card.  The first phase is authorization, where the merchant gives the account information and transaction amount to their payment processor.  The processor contacts the "issuing bank", who issued the card to the customer.  The bank examines the customer's account, makes sure the credit limit is high enough, that the bills are being paid on time, that sort of thing, and creates their approval in the form of a randomly generated number, called an approval code.  This number is proof that the authorization took place at the bank, and it is the signal that the bank is willing to accept the risk of this transaction not being paid in the future by the cardholder.  The approval code is sent back to the merchant, who prints it on the receipt.

In the second phase, the settlement process is where the merchant sends the day's transactions to the payment processor, and this will include all transactions, whether or not they have approval codes.  As a part of settlement, all the money from all those transactions, including the unapproved transactions, will be transferred from the banks to the merchant's account.  (The processor brokers these exchanges for a fee.)

The merchant (in this case the airline) may be willing to accept the risk of conducting credit transactions without authorization.  An airline would generally have only small transactions for in-flight goods and services (a few dollars for alcoholic drinks, a movie rental, or perhaps a more expensive upgrade to first class.)  It's not an amount that puts their business at risk, and the overall amount of money lost to in-flight fraud may be less than the cost of owning in-flight credit authorization terminals.  When they accept these transactions they are offline and obviously cannot get an approval code from the bank.  At the end of the flight, the airline sends them all to their processor for payment.

Later, the issuing bank will send a bill to the person, asking for him to repay his debt.  If he refuses, the bank will look at the transaction and say "this came from Pseudo Payment Processors, who got it from Mythical Airlines, but we never gave them an approval code saying we authorized the charge."  The bank will then issue a "chargeback" to the processor, who will in turn pass the chargeback to the airline.  A chargeback is simply a request to repay the money.  Since they have no approval code as evidence they received the bank's authorization to conduct the transaction, the money comes back out of the airline's pocket, and the airline is not paid for the goods and services they provided in-flight. The airline may then attempt to collect the money another way.

Make no mistake: taking the goods while misrepresenting intent to pay for them meets the legal definition of fraud.  The person "at the next table" was a thief.


There are headers explicitly defined for this sort of thing in the JOSE standards. You can use

JWK which is the actual public key -- you just have to make sure they match what you have locally.
KID which is just an arbitrary identifier of the key -- you could use a thumbprint of the public key and just do a local lookup.

In the first case you want to be careful and not just rely on the presented key, but rather use it to look up a local key.


Actually, isn't it bad to redirect http to https?

Redirecting from HTTP to HTTPS is not a bad thing. What is bad is relying on it as if it was a security feature.

This redirection is a lighthouse, meant to allow ships lost at sea in the storm to understood where they are and, with luck, give them a better chance to reach a safe haven. Nobody claims that lighthouses make storm disappear; they just improve probabilities of a happy ending for bad conditions.

The only bad thing that can be said about an automatic redirect from HTTP to HTTPS is that it breeds complacency. If a user errs, e.g. by trying to access the Web site as HTTP instead of HTTPS, the automatic redirect allows him to persist in his mistaken ways, hiding the fact that his inappropriate URL exposed him to the vindictiveness of Internet dwellers, some being quite proactively evil at times. Disabling this redirection could be construed as being more pedagogical. However, this point of view is somewhat unrealistic; most Web site owners are in no position to educate users. What they want is to grab the attention of potential customers. If you begin to make access to your Web site more difficult, then they will just go away; they will not be educated in the slightest way, and business will suffer.

"That which does not kill us makes us stronger." A catchy phrase from a more-than-half mad philosopher; but not necessarily applicable to the general public as an educational policy. The problem with making people stronger by trying to kill them is that sometimes you succeed -- to kill them, I mean.

As mr spuratic explains, to really makes things better, browser should use HTTPS by default; ideally, the whole Web would be HTTPS-only: if browsers try HTTPS first but fall back to HTTP in case of errors, then an active attacker can simulate the failure and force a fallback. DNSSEC coupled with appropriate SRV records could advertise, in a secure way, that a given server should be used with HTTPS only, but this will work reliably only when... it will work everywhere (same bootstrap problem as IPv6).

In the mean time, a redirect will bring stray sheep to the stable even when the sheep are completely unaware of the wild beasts who roam the night-time countryside. This is usually considered a more efficient method than trying to teach sheep not to stray.


How does the same origin policy apply to two different windows of a browser?

The --disable-web-security option applies to the entire Chrome application, not to a particular window.

If you enable this option when starting Chrome, then any site you visit can access data from sites you visited earlier.

For example if I was looking at my Online Banking account, and then closed that tab and navigated to a malicious site, that malicious site would then have the ability to access my Online Banking account, transfer funds, etc. Note that this risk survives even after the tab is closed, and continues so long as you are still 'signed in' to the Online Banking account.

Also, it can survive restarts. So if

I sign into Gmail.
I restart the browser, now enabling --disable-web-security
I visit a malicious site.

Chances are, you are still signed into Gmail, because it often will not sign you out as an Online Banking site would. In that case the malicious site can access your Google account and control all services, as long as you have not yet Signed Out.

  Will this window be able to access data on websites opened in other window??

--disable-web-security applies to the whole browser, not just one window.
The 'other window' need not be open to for 'this window' to access data from that site.

So if you must use --disable-web-security, you should first Clear Private Data, especially Cookies & Saved Passwords. Then get your testing done, and then use the proper Exit feature at your earliest opportunity to get back into a safe browsing environment. Make sure your browser is fully Exited (not even a tray icon) before you assume you are back into a safe browsing session.


How does one go about network forensics investigation with no prior knowledge?

OK. I promise I'm not trying to be mean about this.

To paraphrase the question: how do I go about performing forensics with no prior experience?

You don't. Seriously. There are dummies books available that will touch on the basics and there are a number of websites that will walk you through common situations but to perform any defensible forensic analysis you will need the proper training and documentation.

To the point of 'this hasn't been labeled a real "forensics investigation"'; maybe it hasn't, but it could and there is a very real possibility that you could alter evidential data in your analysis. Should this become a 'real' investigation you might find yourself in a bad situation.

-IF- you get it in writing that this is not ever ever ever going to move toward a legal issue, with complete indemnity for you, then grab a copy of Computer Forensics for Dummies and have a ball.


Website customer e-mail collection form getting spammed, why and what to do

You need to use an automated system to defend the form entry.

Currently, something like RECaptcha, also mentioned by @korockinout13 (+1) is probably the most common solution to do this.

You might also want to leverage something like Fail2Ban to block repeat offenders.

For certain businesses, larger scale whitelisting/blacklisting of IP's may be useful. For example, if you notice that the IP addresses causing harm are always from Tor relay IP address ranges blocking these might be helpful for you but do take into account privacy reasons that a legitimate user may want to connect to you via tor. If this is unlikely to ever happen then blocking these IP's may in some cases be helpful. Similarly, if you don't ever do business with some other country but 99% of the form attacks come from IP addresses in that country you might consider blocking that countries IP addresses for a while but do not do this blindly because some of your customers do travel and other countries may have valid business for you or legitimate reasons to visit your site.

Some website frameworks, like Django, have additional add-on anti-automation defences and honeypots that may also help.

Finally, it is wise to use more than one of these solutions as there are already tools like Bishop Fox's Anti-Anti-Automation Framework which can help attackers and penetration testers get around some of these systems. Ultimately, your goal is just to make it more expensive and time-consuming for attackers to the point they stop impacting your forms.

In any case, you want an automated solution that doesn't create a lot of work for you.


Does verifying identity by positions in passwords mean passwords are stored unhashed?

It is possible that the service not only computed the hash of the full password when it was created, but also hashed the 3rd and 7th character (or possibly every character) individually. That way, they technically wouldn't be storing the characters or the full password in plaintext. However this would be a terrible idea. A hash of a single character is essentially no better than plaintext since there are only perhaps 62 possible single character hashes per salt (if a salt is used).

Either way, if the service has the ability to recognize part of the password as opposed to only the full password it is bad news.


How do I use nmap to scan a range of IPv6 addresses?

I would assume that the range you are trying to scan is fe80:0000:0000:0000:0000:0000:0000:0000/112 which is the last 16 bits (the last section) of the address.  That range includes 65,536 IPv6 addresses, probably all of which are going to time out when scanned.  It will probably take most of a day (86,400 seconds - close enough to 65,536 at one second per timeout on average) just to ping that range to determine whether the machines are up or not.

But such small ranges are rarely seen.  ISPs are often handing customers a /64 range each, (and it seems this is what you have) meaning that the customer has 18,446,744,073,709,551,616 individual IPv6 addresses.  Scanning a single customer like this would take years.

There are discovery protocols that exist to allow you to find the exact IP address you need rather than scanning the entire range and these might be a better place to start.

There are some existing answers here that may still help: Which tool (apart from nmap) can I use to scan a range of IPv6 addresses?


Do Spectre(-NG) and Meltdown affect Mill?

Mill had published a sort of white paper on the extent of their vulnerability to Spectre and Meltdown. Since we don't know much about Spectre-NG yet (probably the first wave would come out on 7th May 2018), I am going to rely on my assumption that the new variants attack the Hypervisor and Intel's secure guard extension.

The attacks on hypervisor (using software level speculative execution) definitely can affect Mill's hardware or probably any hardware in general. Here is the relevant section from the whitepaper:

  There is little that a vendor can do about victim code that deliberately loads from an attacker supplied address without checking the validity of the address first; such code is a bug, plain and simple. Exploitable speculation introduced by the compiler as an optimization is also a bug of
  course, but more insidious because inspection of the victim source will not reveal the problem.

  The Mill is a very wide-issue machine, which allows the compiler to improve performance by carefully interleaving speculative execution using meta-data and predicated (conditional) instructions. For example, it is common for the two legs of an if-statement to be interleaved and both sides executed unconditionally but with one side masked out via meta-data or not used by subsequent conditional instructions.

As for attacks on Intel's secure guard extension:
According to the white paper, Mill architecture seems to be secure against such attacks.


Any TeX editor could do it without breaking a sweat.  There's a list of them here.


Why should the dh keylength match rsa length in tls?

In the "DHE_RSA" cipher suite, security is relative to both that offered by Diffie-Hellman, and that offered by RSA. "In general", the overall security will be that of the weakest of the two; so:

it is harmful if the DH key is weaker than the RSA key, because then overall security is lowered (compared to what the RSA key alone offers);
it is harmful if the DH key is stronger than the RSA key, because you do not get actual extra security (it is limited by that of the RSA key), but you still have to pay for the extra large key (larger messages, higher computational cost, and loss of interoperability with limited clients).

It so happens that DH and RSA seem to offer similar strength when used with keys of similar sizes, i.e. DH modulo a 1024-bit prime can be said to be somewhat as strong as RSA with a 1024-bit modulus (but a non-prime modulus, of course). So this gives the rule that the DH key and the RSA key should have the same length.

When you look at the details, things are less clear-cut:

In a DHE_RSA cipher suite, DH and RSA are used for different purposes. RSA is for a signature and its security target is limited to the present. Suppose that you do a SSL connection today. The attacker records it. Then he sets out to break the connection. Five years from now, after extensive computations and thanks to technology improvements, the attacker succeeds to break the DH key: the attacker can then decrypt the recorded connection and learn your secrets. However, suppose that instead of concentrating on DH, the attacker broke the server's RSA key. The attacker then... has nothing ! Breaking the RSA key gives him power to impersonate the server for future connection, but it won't help him a bit with the decryption of past connections. Meanwhile, you renewed your server's certificate at least once or twice, with a new key each time, so all the attacker's efforts went to naught.

For this reason, the security of RSA and the security of DH in a "DHE_RSA" cipher suite cannot be readily compared; they don't have the same scope or target level, and, overall, the security of RSA is less important than that of the DH.
DH and RSA have comparable security for the same modulus length only in a rough sense. The known best algorithm for breaking RSA is the General Number Field Sieve, and the known best algorithm for breaking DH is also GNFS. However, for big modulus (say, 1024 bits or more), the bottleneck of GNFS is the "linear algebra" phase, which is last in the algorithm: it is a mathematically trivial computation on a matrix of extremely non-trivial size. This is very hard to compute in parallel, and requires a machine with a tremendously huge amount of very fast RAM. In fact there is no existing computer which would be up to the task for 1024-bit RSA or DH (a dedicated machine can be envisioned without breaking laws of physics, but it would cost a pretty penny).

It turns out that the GNFS variant which breaks DH has the same linear algebra step, but with a "bigger" matrix; not with more elements, but the elements are now integers modulo p (the prime modulus) instead of mere bits. This means that the matrix for breaking DH is a thousand times bigger (conceptually) than the matrix for breaking RSA with a similar key size. This implies that, in practice, 1024-bit DH is harder to break than 1024-bit RSA.

(Also in practice, 1024-bit DH and 1024-bit RSA are unbroken within the current economico-technological context, so any robustness comparison must be considered with a grain of salt; an algorithm cannot be less broken than not broken.)
You cannot necessarily choose the DH modulus as you would like. Existing implementations can be limited, for a variety of historical reasons. Some clients may have trouble using a DH modulus longer than 1024 bits, even if they have no problem with a 2048-bit RSA key. Equality of robustness and security balance are fine things, but data must flow nonetheless. A failure to establish a connection is very secure but not very useful.

So while a systematic 2048-bit DH modulus will not hurt anything security wise, and will incur only moderate overhead (over a 1024-bit DH, this means 250 to 500 extra bytes per full handshake, and some extra CPU, but nothing critical), it may break compatibility with existing, old clients, so this calls for tests. At least, from the point of view of the standard, 2048-bit DH is fine, regardless of the size of any RSA key involved in the mix.


Caller 18777348472 had my name & last 4 digits of my credit card and indicated he was from fraud prevention

That looks like a legit number for State Farm Bank but, rather critically, phone numbers can be spoofed. The same goes for the sending number for SMS. The caller ID you see on screen is an arbitrary text field that can be overridden when a call is placed - this is very commonly used to provide a general call-back number instead of the direct phone number of the operative in a call center.

  I refused because if I do not know who is calling and I do not give out sensitive info.

Good. If the "bank" calls you, you should always ask for their name and a reference number if they have one, then tell them you will call the bank back on their advertised phone number. Banks will always be fine with you doing this; most scammers will get upset or annoyed at you and try to persuade you not to hang up. Never give any kind of sensitive information to someone who called you, no matter what their provided reason is. You call them, they don't call you.

As far as I'm aware your bank shouldn't usually ask for your CVV for verification. Check emails from your bank as they usually have boilerplate security advice (e.g. "we will never call you directly" or "we will never ask for card details") that can quickly indicate that the call was bogus.

In fact your first action should be to call your bank's fraud department, via their advertised number, and ask if they just tried to contact you. You should then ask them to read back your recent transactions to make sure if there was any unusual activity.

  Does the CVV enable escalation privilege (change address / phone / email)

Assuming the scammer has your full CC number and personal details except the CVV from a compromised website, providing the CVV would enable them to make purchases online. The CVV isn't much use aside from that.

  What are the 3 most common techniques for the phisherman to gain my name, phone-number and 4 digits of my credit card?

This is subjective and open to opinion, but in my experience:

A website that you provided your card details and personal information to was compromised.
You were infected with malware and it stole your details when you entered them into a site.
You unwittingly clicked a phishing link and provided your login details (e.g. for your bank, a retail site, your work's HR system, etc.) to an attacker, and they used that to get your details.

The first one is by far the most common from what I've seen. Another potential is that you had your card's magstrip skimmed at an ATM or at a restaurant, cafe, store, etc. and they got your card number and name from that but not the CVV (it's not usually encoded in the magstrip afaik), and they used OSINT to find your number to ask you for the CVV.

  Is it reasonable to assume that he has all 16 digits since he is asking for the CVV (time to change the card number).

Yes.

  If caller found a receipt with my name, how difficult would it to acquire my phone number?

Depends. This is all down to OSINT really. If you've listed your number on Facebook, for example, they might have found it there, particularly if you've got your privacy settings configured to allow friends of friends to see it. They could've gone the old fashioned way looked you up in the phone directory. They might have found your card details and email address on one compromised site, and your email address and personal details on another compromised site. There are any number of ways.


Is a self-signed SSL certificate much better than nothing?

Self-signed certificate means that:

You are still using SSL, so you use encryption, so you are defeating passive attackers: someone who wants to see your secrets will have to commit visibly to the effort, by mounting a fake server or a man in the middle attack.
On the client side, you can use "direct trust", i.e. specifically instructing your browser to trust the specific server's certificate. The first connection to the server is vulnerable to a MitM, but afterwards you are protected. See this answer for some discussion.

So yes, in many situations, SSL with a self-signed certificate is much better than no SSL at all. Of course, "better" and "good" are not the same thing...

A client-side certificate is about convincing the server of the client identity. A fake server is able to ask for a client certificate just like the genuine server, so no improvement here. A client-side certificate can help against MitM, though, if the genuine server is educated to require a valid client certificate (a true MitM is a double-impersonation: the genuine server talks to a fake client, and the genuine client talks to a fake server; if the server requires a client certificate, then half of the MitM won't work, namely the part with the fake client).


Using PDF instead of doc(x) or html: safer?

The reason PDFs are preferred isn't security so much as a combination of technical capability and user expectation.  The security of PDF and Word read only modes is about the same (which is to say, not very good, but good enough to prevent casual use.)  Both files require a viewer on the other side, and there is both a Word and PDF viewer app for free, while the tools to make both generally cost money, though some services will do either for free.

User expectation however is generally that a Word document is something they edit.  They feel like they are being blocked from doing something when they work with one that is protected and this can lead to a negative user experience.

The other factor is that Word is not a format that gives much control over the way the document flows.  You can make an OK layout in Word, but a variety of factors can end up impacting how it is rendered.  This is a simple side effect of the fact that Word is a word processor, designed for typing, not layout.  PDF on the other hand was designed specifically as a print production and document reproduction format.  It's sole purpose in life is to ensure a consistent viewing experience and printing experience regardless of the hardware it is displayed on or printed with.  This is the primary reason why people, especially document generation professionals prefer PDF as a distribution format.


Using history of two-factor codes found on a phone

In the short term, the tokens obviously expire very quickly, so if your attacker has only had once off access this isn't a problem. If your attacker has live access to your phone's messages as they come in, then they can request a new token themselves and use it immediately to pass authentication before it expires.

With only a history of tokens, it is possible (with difficulty) to figure out the backing pattern that makes your authenticator unique, and predict future tokens - however the algorithms behind these systems are designed to make this impossible or infeasable without first analyzing many thousands of past tokens.


Setting up a secure modem & router with ISP

Encrypt with WPA-2 with AES: Make sure the router you get has that capability. Most do, since WPA-2 has been around a while.
Hide your network name: A setting in the wireless router. Hide "SSID" or similar. Also, most wireless router will have this. Users will have to manually input the SSID however.
Turn off UPnP (is this easy to do?): Yes. Another setting in the router. Turn it off. Enabling UPnP is not advised, as you have surmised.
Setup a guest network for guests and IOTs: Good idea, make sure wireless router has these capabilities.
Turn off WPS: Just make sure WPA-2 is on for each wireless interface. If you select WPA-2/AES as the auth method, that's the only way anyone will be able to connect.
???: If you really are serious about security, put a UTM firewall behind the ISP equipment instead of a router. The SonicWall SOHO 250 Wireless N Base Security VPN Firewall can do what you want plus much more, and is reasonably priced.


The credentials are not part of the DNS query so they are not visible there. The credentials are included in the encrypted part of HTTPS so that the ISP cannot see these either.


Is this scheme considered to be text/linguistic steganography?

This is a substitution, not steganography.  One of the key goals of steganography is deniability.  In information security, deniability is a property which allows denial that information exists or that an action took place.  While the meaning of the message is somewhat disguised in your scheme, the presence of the general message is not.  Steganography is concerned with building a hidden channel which prevents detection of a message being exchanged covertly within an innocent and unrelated communication.

An early simple example might be the book dot cipher where small dots were placed on letters in a book to turn the book itself in to a message.  This primitive approach was not completely hidden, but at a casual glance, it would just look like someone who had a book, it doesn't appear to be any special communication.

To have a linguistic steganography, you would need to encode the information such that a seemingly normal conversation would actually convey some other information.  In your example, it is clear that you are talking about a meeting at some time, so the message, while the details are altered, is not hidden.

A better example of an extremely primitive linguistic steganography would be to have the time of day of a phone call encode some information, or perhaps have values assigned to different items to have for dinner.  If you called to ask when the chicken would be done cooking, that could mean that you needed to meet up later at a drop point.  The actual message is completely concealed by what appears to be a legitimate communication.

Borrowing from Steffen's excellent answer, it seems you may be getting confused by the concept of "synonym substitution" which is a common basic form of linguistic steganography.  With synonym substitution, words are replaced with their synonyms to encode information based on if the word changes or not.  This could either be through a simple binary encoding or a more complex code word system, but the key thing is that the message being sent is unrelated to the message it appears in.  The message that is apparently being sent must be deniable that any hidden meaning exists.

Now, in theory, you could use antonyms instead of synonyms for the substitution used to encode the information, but this runs in to a problem.  Synonym substitution works because the paraphrase will make sense and seem like a reasonable paraphrase or mis-remembering of a known quote.  If you instead start throwing in antonyms it becomes much easier to tell something odd is going on.  Since it looks odd, the deniability is greatly reduced and the message is much more likely to draw the attention of code breakers.  This renders antonym substitution to be a relatively poor means of encoding steganographic information as well.


One use of PGP is to provide message authentication; so if the chat messages were signed, you would have good confidence that the person on the other end has access to the corresponding private key.  The other party could still claim their key was stolen, however.


The short answer is that PBKDF2 is considered appropriate and secure for password hashing. It is not as good as could be wished for because it can be efficiently implemented with a GPU; see this answer for some discussion (and that one for more on the subject).

There are some arguable points, notably that PBKDF2 was designed to be a Key Derivation Function, which is not the same kind of animal as a hash function; but it turned out to be quite usable for password hashing as well, provided that you do not do anything stupid with it (meaning: be sure to keep at least 80 bits of output, and to use a high enough iteration count, ideally as high as you can tolerate on your hardware).

Don't try to make your own hash function; these things are surprisingly hard to get right, especially because it is nigh impossible to assess whether a given construction is secure or not. Use PBKDF2. If you really want SHA-256 (or SHA-512), then use PBKDF2 with SHA-256: PBKDF2 is a configurable construction, which is traditionally configured to use SHA-1, but works equally well with SHA-256 or SHA-512.


OWASP Top 10 style security guide for implementation in hardware devices

1. Backdoor testing accounts.

Engineers often include backdoor mechanisms and testing accounts in hardware for debugging purposes, with trivial or no security measures put in place to protect them. Unfortunately, a large number of devices make it to market without having these mechanisms and accounts disabled, allowing attackers to gain illegitimate access to the device.

2. Unsecured network management protocols.

Many devices implement SNMP or UPnP for remote management, but fail to implement even basic levels of security around them. Office equipment, networking hardware, industrial control systems, etc. often leak sensitive data (such as the routing table) via SNMP, and may provide various control functions via UPnP. Many UPnP-enabled devices implement the standard network interface management functions, which allow an attacker to disable a network interface. Further functions may allow an attacker to permanantly damage the device, or cause severe problems with functionality.

3. Buffer overflows.

Hardware implementations are notoriously bad for not checking target buffer sizes, and can allow complete corruption of the memory state. This may result in code execution, but more commonly simply results in a denial of service condition, where the device must be hard-reset before it can be used again.

4. Integer overflows / underflows.

These occur when an unsigned integer input is treated as signed, or a larger integer type is directly cast to a smaller integer type. Both of these issues may result in cases where a value is outside the expected range, which can cause array range checks and buffer length checks to pass despite the input buffer being too large. These can also result in read-what-where conditions, where a negative array index leads to memory operations accessing preceding memory regions.

5. Insufficient sanity checks.

Input values in hardware implementations are usually considered to have strong integrity, so sanity checks are often not performed. This might allow a malicious user to supply an unexpected value and change the behaviour of the device. A common example of this is when a set of bit-flags are used, and conflicting bits are set.

6. Shared, hard-coded secrets embedded in non-volatile memory.

Hardware designers are sometimes under the delusion that because something is stored in an EEPROM chip on a board, the data within it will not / cannot be read by someone who wishes to interfere with the device. It is common to find hard-coded cryptographic keys and other credentials stored in the firmware of a device. These might be used to compromise the device or its communications, and are often the same across all devices of the same model.

7. Poor quality, self-designed or missing crypto.

Often it is complicated to implement proper cryptographic algorithms in embedded systems, especially when working with less widesrpead microcontrollers and microprocessors. Reference implementations often assume x86-like or ARM-like architectures, which increase the work factor. Engineers also usually lack the knowledge and experience to properly implement cryptography. As such, cryptographic algorithms found in embedded systems tend to be poorly implemented, or are home-brew designs with serious security flaws. Many systems completely lack any form of hashing on passwords and other credentials. This type of data can usually be extracted from non-volatile memory using off-the-shelf tools.

8. Lack of strong integrity and authenticity checking on firmware upgrades.

The integrity of device firmware is often checked via a CRC32 or MD5 hash, but is rarely authenticated via any strong means. Many manufacturers rely on obscurity as a security measure. Whilst the cost of reverse engineering the firmware of a device may be considerable, it is becoming less so with the advent of common microprocessor architectures (e.g. ARM) in embedded systems. Once an attacker gains the ability to upload a firmware image, they may entirely subvert the system.

9. Various web-application flaws in control panels.

Many of the OWASP Top 10 web application flaws are disturbingly common in web control panels for embedded devices. CSRF, XSS and session theft feature highly in the list of common vulnerabilities, though SQLi is less common due to the relatively low number of systems that implement a full relational database.

10. Improperly bound network services.

Many network services on embedded devices are configured to bind to 0.0.0.0, rather than directly to a LAN IP address. This may allow an attacker to communicate with the device from outside the LAN. Appropriate segregation and firewall configuration may help to mitigate this, but it is still a concern.


Can there be a virus that uninstall itself?

Is there possible situation where a file contains malicious codes and after the code is executed, the virus attach itself to another file and delete the malicious code from the file where it comes from?

Yes, once the virus program is a running process (program loaded in RAM), it can easily access its own program file and delete its executable file from persistent storage.
The C code to do this self deletion is very simple, since the program file name is the zeroth argument of the argv input array pointer to the C main function. And, for example, the remove function can be used from the stdio library to delete a file by name.
For example:
#include <stdio.h>
int main(int argc, char *argv[]) {
    remove(argv[0]);
    return 0;
}

If you compile and run the above source code it will delete its own executable.
Injection into another process is also fairly straightforward, but the exact form of the source code to perform such functionality is more operating-system dependent.


I'm no expert, but I think what you're talking about will work. For keys A = current keypair, B = new signing key, and C = new encryption keypair on the VPS:

From whatever machine holds your primary keypair

gpg2 --edit-key A8675309
addkey <follow prompts to generate signing key>
gpg2 -K <list keys, find new key's handle>
gpg2 -a -o signingKey.sec.asc --export-secret-key B8675309

I think you only need to import the secret key on the other side, might be wrong on that. Next get your exported signing key to the VPS, then

From your VPS

gpg2 --gen-key
gpg2 --import signingKey.sec.asc
gpg2 -a -o vpskey.pub.asc --export C8675309

After that you just need to get vpskey.pub.asc to your main box and

gpg2 --import vpskey.pub.asc

and use that key to encrypt anything you'll need to send to the VPS. You need to be careful with how you get the keys moved between machines, but personally I'd feel safe using SCP.


Please have a look at the article Windows 10’s BitLocker Encryption No Longer Trusts Your SSD. While you can still make Windows to trust the drive hardware encryption, it may be preferable security-wise to do that at the software side. That would remove your need of a RAID controller supporting IEEE-1667, and would as well increase your recovery chances if the disk failed.


Is there a tool that puts on a webserver some .html or .php files filled with popular malware like java drive-bys or other browser exploit payloads?

The Social Engineer Toolkit (SET) has something like what you ask for.

It allows you to create websites with various attack vectors.

Check out the 'Tactical Nuke' option for a widespread test.

This is found on Backtrack and integrates with Metasploit.


if computer is compromised, does hardware key still protect in ssh?

When I am 'away' can the threat actor access the server (assuming I
logged out)?

This will largely depend on the setup of your hardware key, assuming it is left inserted. If your key is set to require physical touch every time it is used for authentication, this likely cannot be bypassed, even if your system is compromised. If the device requires a PIN, the attacker likely needs to steal that first. In the case of both features, the device may not require them again for a period of time, at which point you'd likely be exposed.

when I am 'sitting there using it' can the attacker move into the
server and plant access directly to the server so that they no longer
are impeded at all by the key.

If the attacker has root, they can typically manipulate all files and processes on the system. It is not infeasible that they could backdoor the ssh binary to run extra commands, or attach to it at runtime to inject extra stuff.
It would seem the hardware key is most effective when it is unplugged or requires additional, unforgable physical interaction in order to activate each time a sensitive operation is performed. However, as alluded to above, while a hardware key is a powerful tool as part of a defense in depth strategy, it does not remove the need to focus on securing the rest of the system.


What information is exposed in AD's Service Connection Points (SCP)

SCPs should be put in the Domain partition, under the host that provides the service, so that it is correctly replicated.

The SCP contains whatever information the service wants it to. Typically it has some identifiers for the service (so the client can find it) and then connection details for the service (like an IP and port number). But the service can put anything it wants in there, and can even extend the schema if need be - Microsoft don't know what some random service might need, so they kept it general. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms677947%28v=vs.85%29.aspx

It's secured exactly like any other Active Directory client lookup.

Lots and lots of applications use it: it's the way you do service discovery in AD. Certainly all the Microsoft apps will use it, so yes, Exchange and SCOM do. And so do lots of 3rd party vendors.