Fax over VoIP (which is normally what eFax means) is not any more secure than Fax over pure analog lines.  To clarify, eFax isn't a technical term, it's a marketing term.  The underlying Fax is still an inherently analog technology, and the VoIP technology underlying it is merely trying to emulate the analog lines.  Normally the other end of the call is often going to be an analog line connected to the PSTN.

Futhermore, the VoIP portion of the call isn't encrypted, is sent over un-encrypted RTP and hopefully T.38 and can pass through multiple carriers before arriving at the destination.  There's no reason to think tapping these lines is any more secure than tapping an analog line.  Wireshark has nice tools to intercept this traffic if you have a place to sniff.

Without using some sort of proprietary technology on both the sender and receiver, it's not possible to encrypt Fax.  If you're concerned about someone intercepting the transmission, the short answer is don't use Fax, use some form of digital communication that's encrypted.


In your example it looks like you're trying to config iptables which is different than Arno IPTables. Check out this link for more info on the different types of firewalls.

To see the iptables rules you're running you can type (which you're already doing):

iptables -L

To block the ports you've listed specifically in iptables, since they're both typically TCP traffic, you can use:

-A INPUT -p tcp --dport 1863 -j REJECT
-A INPUT -p tcp --dport 5190 -j REJECT

Warning: Make sure you're leaving your access open before running something like this, but to reject all non-allowed inbound traffic with iptables you would use:

-A INPUT -j REJECT
-A FORWARD -j REJECT

The trick with iptables is that you'll need to actually save the ruleset since anything that you type via command line is usually flushed on restart.

Arno's IPTables Firewall

For Arno IPTables you can reference the file /etc/arno-iptables-firewall/firewall.conf for additional configuration beyond the scope of the debconf dialogs. To start/stop/restart the firewall from the shell, use the command /etc/init.d/arno-iptables-firewall [start|stop|restart]

According to the firewall.conf file:

  Put in the following variables the TCP/UDP ports you want to DENY(DROP) for
  everyone (and logged). Also use these variables if you want to log connection
  attempts to these ports from everyone (also trusted/full access hosts).
  In principle you don't need these variables, as everything is already blocked

  (denied) by default, but just exists for consistency.

DENY_TCP="" DENY_UDP=""

If Arno IP Tables is running, in theory those ports should already be blocked. Since they appear as though they're not blocked you may only be running iptables.

You can double-check the ports with netcat or try to telnet to them to see if it's a false positive from nmap.

Netcat example:

nc -z your_server 1-6000

For telnet it if the ports are blocked, they'll say:

> telnet your_server 1863
telnet: Unable to connect to remote host

If the ports are still open, then you'll see:

Connected to your_server

This will be followed by the server response.

You should be able to see what's running by typing top.


Cloud application Vulnerability assessment

Whilst it might be the case that Amazon have done proper configuration testing of their servers, and have full security auditing in place, do you really want to risk your operational stability and security by not testing it for yourself?

The bigger question is why you want to use "cloud" anyway, if you've got anything that's worth keeping secure. The single positive thing that comes from cloud computing is that it's cheap. Everything you hear about improved uptime is a fallacy - just look at how many long blocks of downtime major sites have had due to S3 outages. Then, from a security perspective, you have these issues:

You're outsourcing blame, but not responsibility. Amazon have no contractual agreement with you to provide adequate security testing in a way that's applicable to you specifically as a customer. You can blame them for security failures as much as you like, but they will not be held contractually responsible.
You're putting incident response in the hands of another company. You'll have absolutely no luck getting full-disk images that'll stand up in court if you get hacked. Amazon don't have the resources, inclination or legal clout to provide forensic-level copies and logs to customers.
Once you put data on the cloud, it may not even be yours any more. Various governments, including the USA, have passed legislation saying that "cloud" data no longer carries ownership, and can be taken or removed.

Real security and competitive uptime costs money. If you want proper security and high uptime, get a dedicated server with an SLA and have the full stack tested by a competent security tester.


How can I programatically keep track of number of certificate warnings in browser?

I'm unsure of a easy browser add on but there are web content inspection systems that should be able to count this for you in logs. You would then consolidate and perform counts on the logs if it's not native in reporting. Alternatively, you could group policy something like WinHTTP logging on each individual system in a spool and then you could extract based on error codes.


Allowing clients to authenticate by generating their own JWT

It sounds like you're basically just trying to re-implement mutual TLS ("mTLS", or TLS with Client Authentication). Security-wise, it's a great approach; no passwords / hashes / etc. to leak from the server (incidentally, HMAC by itself is not a suitable password hashing algorithm) but very strong authentication. You can also use a unique key for each client, even if they're owned by the same user, which makes it foolproof to tell, in the event of a compromise, where it occurred. Also, pretty much all standard operating systems and browsers, mobile or desktop, support secure storage and use of private keys, and support mTLS. Finally, while most OSes and such will secure the private keys pretty well and at least recommend putting a password on them (which never leaves the device), you can still add additional server-side security mechanisms to require true multi-factor authentication.

However, it runs into a problem when you try using it in practice: it's a hassle to move the secret key between devices, or set up new key pairs on different devices. Essentially, the user must either export, transfer, and import a key file (losing the advantage of "unique key per client" in the process, unless they then rotate the key on that client alone), or go through what amounts to full re-registration with each new client. This makes it inconvenient for anything with multiple clients (such as web browsers, different PCs, PC + mobile, multiple IoT units, etc.) shared by one user.

You also still need some out-of-band authentication option (email being the usual, or sometimes SMS, but both are less secure) or you have a problem whereby you can't ever restore access to somebody's account if they lose their private key (and also may have a bootstrapping problem; how does the user prove their identity in the first place?) For some systems that's a permissible limitation, but the typical user won't put up with it for the typical app. The out-of-band auth is also useful if you want to make it relatively easy to add unique keys for different users (otherwise, you need to use an already-authenticated client to authorize a new public key for that user).


One solution would be to use a utility such as ngrep(http://ngrep.sourceforge.net/usage.html) and pass it the .pcap file along with a regular expression.

EX: ngrep -q -I file.pcap|grep -i user

An example of this can be found on the web HERE

Snippet from trustwave.com

  5) Search for text strings using ngrep

  This is useful to look for any specific string or regex you want e.g
  look for "password", "card","username" etc....This will normally find
  FTP, HTTP, or POP passwords as examples. Although this is a simple
  example, ngrep can be used for complex regex's.

  ngrep -q -I file.pcap|grep -i user

  e.g

  ..........< TRUNCATED>..........

  en" id="secure_username" name="username" value="" />......

  ..........< TRUNCATED>..........

  6) Find emails using ngrep ...

What regex to use:
I would encourage learning how to craft regular expressions if you haven't already as they are very useful.
(Not tested): ~JOIN

EDIT: If you must use wireshark and not ngrep then I believe wireshark uses perl style regular expressions


How do digital signatures on PDF documents work?

Don't be sure that you digitally signed the document. Adobe Reader and related products also include echoSign features. EchoSign is an electronic (not digital) signature system.

If you still have the "signed" PDF, then open it in Adobe Reader. If you see a colored bar across the top that includes a button for the "Signature Panel," then the PDF is digitally signed.

In that case, open the Signature Panel (use the button) and see what it tells you about the document’s signature(s). The screenshot below shows a digitally signed PDF opened in Reader

Added Re your questions:

  What crypto lib was used?

[Adobe Reader is a huge piece of locally installed sw. So it would not be a big deal for it to either use an OS crypto lib or include one for platforms that don't have what it needs.]

  The person receiving this document does not even have my public key; how do they know it is me who filled it out? Does the document get sent along with my public key?

[Yes, digital signatures include a copy of the public key of the signer. However having the public key of a signer does not establish trust, as you mention. Trust is established by having a trust relationship with the key that signed the signer's key.

If a public/private key pair are being created on the fly locally on the signer's machine then they are most probably self-signed. In that case, there is no way for the relying party (recipient) to have a pre-existing trust relationship with the signer's key since it doesn't have an issuing parent that guarantees it.

The recipient can manually establish a trust relationship with the signer's key if desired.]

  In case the public key does get sent along with the document, there would still be no mechanism to associate the key with my identity (in the same way a CA would do it). So what benefits exactly does this kind of signing provide?

[You're confusing the availability of a public key with the potential trust relationship from a CA or someone else who issued the key.

Digital signatures include the public key of the signer.
The signer's key can be self-signed. In that case, the digital signature ONLY guarantees that the document has not been changed since it was signed. And even that guarantee is weak since you can't easily tell if someone else has impersonated the original signer and changed the document.
If the signers key was issued from another key (either one that is chained back to a CA, or one that is chained back to an organization's master key), then there you can create a much stronger case that the key should be trusted. In addition, if the key is chained back to a key that is already pre-trusted by your software (Reader), then the sw can automatically verify the trust relationship between you and the signer.)

Bottom line: self-signed digital signatures should be avoided by anyone serious about their signature. Self-signed signatures are easily forged by someone else since there is no possibility of having a trust relationship with the key's issuer since there is no issuer, per se. The key guaranteed itself.

Last comment: for a digital signature to be strong, its private key must be stored in a Secure Signature Creation Device such as a tamper-proof appliance or a smart card. Storing the private key on a regular computer or server is very weak beer and does not provide a legally binding signature in many use cases around the world. (But is fine in other use cases.)
]


How to evaluate a wireless network risk level?

The only sensible way to approach this problem is to assume that any public wireless network you connect to has hostile elements connected to it.  You should ensure that all traffic is encrypted either using SSL for specific sites, or using a VPN to encapsulate all traffic over the local wireless network.

Many potential risks are passive (e.g. sniffing attacks) or not easy to detect, so it isn't likely a sensible approach to attempt to assess trustworthyness on a network by network basis.


From Cloudflare Support - SSL FAQ:

  What do the SSL options mean?

  Your domain's SSL option determines how Cloudflare connects to your server either using encryption or not.

  Flexible SSL:

  SSL is terminated at the Cloudflare edge servers. Everything between your client and Cloudflare is encrypted, but between Cloudflare and your origin server is not encrypted. You would not need a certificate directly installed on your server for full encryption.

  SSL Full:

  SSL is terminated at the Cloudflare edge server. Then it is encrypted again, and sent back to your servers all encrypted. You would need an SSL certificate installed directly on your server for this option. You can also use a self-signed certificate for this option.

  SSL Full Strict:

  Same as SSL Full, but you must have a trusted certificate that is signed by a valid Certificate Authority (such as GlobalSign or DigiCert).

  Custom SSL (Business/Enterprise ONLY)

  Customers on these plans are able to upload their own SSL key and certificate, so CloudFlare's name will not show if a visitor checks the certificate.

So as long as your domain is using the "SSL Full" or "SSL Full Strict" option, the traffic should be encrypted from Cloudflare to your server.

To set this option, go to the Cloudflare Dashboard for your domain, select the "Crypto" panel, and change the SSL Option from the default of "Flexible" to "Full (strict)". Since you're using Let's Encrypt on the origin server, strict mode should be acceptable for you.


Duplicate subject names for intermediate and root certificates

It is the combination of Subject Name and Public Key which makes a certificate unique. If either of those change, it is a completely different certificate as far as verification is concerned.  It can be either or both.

It just confuses us humans when only the Public Key changes while the Subject Name remains the same.

Therefore, in your case, the names are the same; but the keys aren't.  That is, they are two different certificates that belong to the same CA.

To aid the comparison process, many CAs add a Subject Key Identifier (SKI) and Authority Key Identifier (AKI) extensions to certificates they sign.  The values in these extensions are derived from the Public Key (of the Subject for SKI and Issuer for AKI); usually in the  form of a SHA-1 hash. With these in place, it's now a matter of comparing a relatively short hash rather than the much longer public key.


Reading the MailWatch interface - 'From' address

The From address can be set to pretty much anything you want it to be.  It's arbitrary text.

Other headers, such as Envelope-From, Reply-To, Return-Path, Sender, and Errors-To may provide more accurate information about who sent the mail, especially - as appears to be your example - in the case of a mailing list.

Mailing list software will often leave the original sender's From address but insert Reply-To to make replies go to the list by default.  However, in your case, you've indicated (via comment) that MailWatch was paying attention to Envelope-From.  That header was likely injected by your mail server; it noted the SMTP "MAIL FROM" value that way.  The mailing list sends mail with that "bounce" address as the SMTP "MAIL FROM" so that any bounces will go back and be handled by the mailing list manager, but normal user agent replies to the mail will use the (From, Reply-To) headers to send to (the list, or the original poster, depending on list policy).

The specific weird in the address (234567-91eb-recipient address) allows the mailing list to determine which address it sent mail to that caused the bounce.  After a few bounces, it will either pause email to that address or remove the address from the list.


Are there state-of-the-art techniques or theory specifically for attacking passphrases over passwords?

I don't know how "state-of-the-art" this is, but the password recovery software Passcape uses a dictionary attack against passphrases.  This is very similar to a simple brute force character-permutation attack against a password, except permutations of dictionary words are used instead (once common phrases and quotes from movies, books, and poems are exhausted).

As it says in the linked article:

  It wouldn't be an overestimation to say that 99 percent of the success in the recovery of a password with a dictionary attack depends on the quality of the dictionaries.

As such, it seems like a simple defense against this type of attack would be to include words that wouldn't appear in any dictionary.  Mis-spell words, leave out vowels, substitute letters, etc.


How do I ensure that my computer is 100% worm-free?

It depends a bit on what you mean by "100% verified".
With virus scanners, it's always possible that there is a malware program that the virus scanner fails to pick up (false negative). Also, the code might contain vulnerabilities that are not yet public (0-day exploits).
It is mathematically impossible to determine in advance for every program how it will respond to input; this is known as the "halting problem". So automated verification is not enough, for any non-trivial program there will be the need for verification by a human expert - who, of course, may make mistakes, accidentally or deliberately.

You haven't mentioned Bluetooth; there might be buffer overrun vulnerabilities in the code for Bluetooth communication, so you should switch that off as well.

Apart from that, I think you should be safe... but you might as well leave the computer off.

And, of course, this assumes that your computer has no floppy drives through which malware may enter :-)

EDIT: I just realized that malicious code may also be present in data - macros in Office documents being the most likely example. So assuming you're getting data from outside the system somehow, that too is suspect.


Is unrestricted query access to dedicated DNS server considered an insecurity?

Is this an insecurity?

It is not an insecurity by itself but it is needlessly increasing the attack surface. And this can cause security problems.
It can lead to availability problems due to DoS attacks possible from the internet. It can lead to sensitive information leaks since anybody could query the DNS server and gain information about hostnames and IP used inside a company. And if there are security issues in the DNS server they can be exploited directly from the internet, i.e. there is no need to be inside a trusted network already.


blackbox pentest newbie - find valid internal IP adress from unknown range

What I would do is start a packet capture (in promiscuous mode to get the maximum information by preventing the IP stack to drop packets not for your subnet) and wait for some ARP requests to be broadcasted, after a while you'll have an idea of the subnet on your segment.

If you never receive a broadcast, then there's probably some kind of Network Access Control (NAC) disallowing your mac address or just waiting you to send some kind of specific packet to announce yourself.

If you get broadcasts:

You'll first be able to guess roughly the subnet and its class (ARP who has requests).
Next you pick an IP in this range, try to keep close of any detected IP to avoid falling out of "weird" CIDR subnetting.
Now you can try to nmap the network you're on to get a better idea.

If you capture long enough you'll find "interesting" targets, unless there's workstations sharing files or servers in the same subnet the IP requested the most often should be the gateway of the subnet.
Anyway an address frequently requested will denote a server, hence an interesting target to scan deeply.


Is it ok to delete SSH configuration files?

If you don't want a SSH server running on your system at all, the better approach is to remove the package that provides the SSH server software. Doing so will remove it cleanly, though it is possible (depending on your distribution) that packages depend on the SSH server packages for some reason. If you just remove its configuration files, odds are good that the system will try to start it anyway, and it will start logging errors (which will clutter up your logs and ultimately might hide something actually interesting).

To do this, use your package manager to remove whichever package provides the SSH server. On Debian and Debian derivatives, you'll likely want to remove openssh-server as seen by searching the list of packages for OpenSSH packages: dpkg -l '*openssh*' by running sudo apt-get remove --purge openssh-server Other systems are likely to be different, so adjust accordingly.

Removing the SSH server shouldn't break anything else as long as the package manager doesn't want to remove additional, unrelated packages; and you can always reinstall it later if you want to.


What is the risk of downloading files from a non-secured sites

The download over HTTP is not a problem by its own but it depends on what you do with the file after the download is relevant:

If you just delete the file: no problem.
If you download an executable from a seemingly trusted site and run it: bad idea since it might have been manipulated during the transit or the attacker made  you access a different server than intended.
If you know from a secure source that the file has a specific hash or signature and verify it successfully after download: the problem of manipulation in transit or wrong server is gone.

In your specific case the files might have some signature which is checked by the program they are intended for. If you do something else with these files and don't check the signature you don't get the related benefits but have to deal with the problem that the download might have been manipulated.

Apart from that: just because something is downloaded over HTTPS it is not automatically safe either. Only the problem that the download might have been manipulated in transit or that you've accessed the attackers server instead is gone. It is still possible that the file was already bad on the trusted server because the server was hacked or that you've blindly connected to some arbitrary server to download some files.


PKCS#1-1.5 encoding - is there a reason to use 00 in block type?

PKCS#1 only defines two "old-style" paddings (aka "v1.5" because these were the two paddings defined in PKCS#1 v1.5, while more modern versions add other options, known as "OAEP" and "PSS"). These two paddings are the "type 1" and "type 2". There is no defined "type 0" padding; of course, any byte can conceptually have any value in the 0 to 255 range, but PKCS#1 defines only two paddings, not three or more.

The two paddings do not differ only by the "type byte" (of value 0x01 or 0x02). The subsequent bytes (the "PS" string) are very important for security. In the "type 1" padding, the "PS" string consists only of bytes of value 0xFF; it is fully deterministic. In the "type 2" padding, the "PS" string consists of random bytes (the bytes must not have value 0x00, but otherwise they must be generated randomly in the 0x01..0xFF range). They cannot be used interchangeably. The type 1 padding is for signature, the type 2 is for asymmetric encryption. If you use a type 2 padding for signatures, then you obtain a very weak signature scheme (because of the malleability inherent to modular exponentiations). If you use a type 1 padding for asymmetric encryption, then you obtain a weak encryption scheme (because of the determinism of type 1 padding, allowing a brute force attack on the plaintext).

The "BT" byte that identifies the padding type is there chiefly (and mostly) to make the two paddings unambiguously distinct. Otherwise, one would have to worry about attackers using a signature as an encrypted message or vice versa. Thus, the two paddings should have a distinct "BT" value; the PKCS#1 authors could have chosen the two values to be 0 and 1, or 1 and 2, or 17 and 42, or any other pair of distinct values; they chose 1 and 2. This is arbitrary.

In any case, the importance of the padding is not in the "BT" byte, but in the bytes that follow (the "PS" string). It is not recommended to use a "type 0" padding because there is no such thing as a type 0 padding.


Evaluate the signature of an X509 certificate in .NET

X.509 certificate validation is a complex process. With .NET, you are supposed to use the X509Chain class to perform such a validation, which entails path building, verifying signatures, revocation status, and a gazillion of other things. See this answer for an example.

X509Certificate2 also has a Verify() method, but that one checks the certificate with regards to the machine defaults: the user's trust store, the user's policies... which may or may not map well to your specific case. To have full control on the process, use X509Chain.

(Extracting the signature value, and the exact byte sequence which is signed, is not overly complex if you know a bit of ASN.1/DER, but the point is that there is much more to certificate validation than mere signatures. Doing things manually is a path which I have personally walked several times, and it entails a lot of suffering. Using the implementation already provided by .NET will save you a lot of time; and that implementation is X509Chain.)


Although Conscrypt has code to support Certificate Transparency there doesn't seem to be an easy way to use this in an app as Google don't expose the API. It is possible to use Conscrypt as a dependency however this isn't necessarily right for every app with its use of native libraries that need bundling and the need to set custom system properties.

I have been involved in writing the open source https://github.com/Babylonpartners/certificate-transparency-android to alleviate some of these issues whilst providing easy configuration for use with OkHttp, HttpUrlConnection and Volley. You simply specify the domains you want CT to be enforced with and the library takes care of everything else, such as getting hold of an up-to-date log list.


Hydra HTTP Form Post with parameters containing a colon ":"

According to the documentation: colons should be escaped with backslashes \


If most companies do not enable TLS for SMTP and IMAP, should we consider email not secure at all?

Email is not secure. By default, it is not authenticated. SSL/TLS on SMTP and IMAP, at best, protect the emails while in transit, not when they are at rest; and you cannot be sure that such protection has been applied.

To some extent, when sending emails within a given organization, you might know that SSL/TLS was enforced on both SMTP and IMAP, and the confidentiality issue is "just" a matter of storage on the server side. But you cannot have the same kind of guarantee when the email must cross organization boundaries.

To get proper end-to-end security for emails, look up S/MIME and OpenPGP. The tools themselves won't ensure absolute security, because part of security is what the users do and understand, but at least these tools allow the achievement of secure emailing.


http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-interactive-voice-response-assessment.pdf

The paper above gives some explanation of an audit of such a system. The first place they start is by using an API to automate the calls (skype in this case), and working on fuzzing the DTMF based interface. It seems like few of these systems are purely voice recognition based, and that many exploits can be found just by automating the touch tone bits.

http://www.securitytube.net/video/4255

also has some information on breaking such a system.

So for 1) You don't necessarily have to fuzz the voice directly.

Now, if you decided that had to fuzz voice, I don't think there is a library in existence that will do it for you. I would start with a dictionary of recorded words - perhaps http://shtooka.net/ - and write a script to play likely combinations of words. You would use the skype api to make the call, and then play the sentences you came up with to test the system.

It might also be profitable to shoot random noises / sine tones at the system. You might find some kind of testing frequency that opens up the system like the old phone phreaks used to do. There are literally tons of programs that will help you script up testing tones. You could even write that part in javascript with the web Audio API if you like.

Then, you might want to use voice recognition software to detect the failures and successes.

None of this will be possible without you thoroughly mapping out the system before hand. The testing plan I linked above suggests that, and I think that's where you should start.


Phonegap/Cordova InApp pinlock, difference if its on Java Layer/HTML5 layers?

Once the attacker has physical access to the device, it's game-over as far as software solutions go. You may be thinking that a Java-enforced PIN code is hard to break, but even a C or ASM enforced PIN code can be broken given enough time and effort.

What you need to do is to put whatever secret you're trying to protect either on a remote server (where you can implement bruteforce protections) or behind strong encryption (but a 4-digit PIN is a piece of cake to break even with good key derivation functions so make sure to use a strong password).


How does Putty derive the encryption key in its .ppk format?

Gotta love open source!  The following code is from the stable Putty-0.63 release.

sshpubk.c

/*
 * Decrypt the private blob.
 */
if (cipher) {
unsigned char key[40];
SHA_State s;

if (!passphrase)
    goto error;
if (private_blob_len % cipherblk)
    goto error;

SHA_Init(&s);
SHA_Bytes(&s, "\0\0\0\0", 4);
SHA_Bytes(&s, passphrase, passlen);
SHA_Final(&s, key + 0);
SHA_Init(&s);
SHA_Bytes(&s, "\0\0\0\1", 4);
SHA_Bytes(&s, passphrase, passlen);
SHA_Final(&s, key + 20);
aes256_decrypt_pubkey(key, private_blob, private_blob_len);
}

Your password is hashed twice using SHA1 with "\0\0\0\0" and "\0\0\0\1" as separate salts.  The resulting hashes are concatenated to form the AES 256-bit key.  I am not completely up on all the current password attacks, and while I don't believe this is the best password hashing scheme it's not the worst.  Yes, SHA1 was recently deemed not secure, but I don't believe that this scheme would be trivial to break.

Something to remember about password guessing is that the attacker has to know when there is a success.   In this case the private key bytes themselves are encrypted with a key generated from a password.  So for each password attempt the attacker needs to do an AES 256-bit decrypt in addition to the hashing.  There is an integrity check for the entire keyfile.  For the PuTTY key-file we have the following HMAC:

    SHA_State s;
    unsigned char mackey[20];
    char header[] = "putty-private-key-file-mac-key";

    SHA_Init(&s);
    SHA_Bytes(&s, header, sizeof(header)-1);
    if (cipher && passphrase)
    SHA_Bytes(&s, passphrase, passlen);
    SHA_Final(&s, mackey);

    hmac_sha1_simple(mackey, 20, macdata, maclen, binary);

    smemclr(mackey, sizeof(mackey));
    smemclr(&s, sizeof(s));

Now after already performing 2 hashes and 1 AES decrypt the attacker now has to perform another SHA1 hash and a keyed SHA1 HMAC.  Just to verify if one guess was correct.  If it wasn't a PuTTY keyfile then the following else occurs:

else {
        SHA_Simple(macdata, maclen, binary);
    }

Obviously not as secure as using a PuTTY keyfile, but that would still total 3 hashings, 1 AES decrypt... and a partridge in a pear tree.


How to transform an hash into a usable password?

For a good hashing algorithm (and unless you've rolled your own hash, you're probably using a good enough one), all of the bits should be pseudorandom.

A 20 character password is indeed weaker than an 60 character password, but one  20 character password is equally secure as another if they're equally random. Combining a 60 character hash into 20 characters would not add more randomness than just taking the first 20 characters.

When it comes to password design, the main threats (strategic guessing of your password, brute force, trying your password against all of your online profiles) can be mitigated by just using a different, long, random password for each website. The level of randomness provided by truncating a hashing function is enough.


What's up?  Here's the meat and potatoes:

nurf@sessmacheen $ ssh -f -L localport:localaddress:remoteport \
    user@remoteaddress sleep 10; nc localaddress localport

This is assuming that sshd is listening on the remote box, which I think I can infer from your post.

Ok! So ssh is passed -f, which just backgrounds it after the connection is made, and -L.  I remember -L as 'Link'.  It creates a tunnel, wiring up a port locally to a port on the remote host (the localport:localaddress and :remoteport user@remoteaddress parts, respectively).

So ssh is reaching out and holding hands with sshd on the remote host (for 10 seconds, anyway), and it's sitting locally with it's hand outstretched waiting for something else to grab hold.  So we nc localaddress localport.  Et voila!

Granted the one liner above doesn't actually do anything except establish a connection and then run sleep 10 on the remote box.  Here's a more practical example, totally ganked from this article.

## let's pull a back up image  over the wire!                   ##
## first we set up the image for grabbing on the remote machine ##
## by piping it to nc which then starts listening on port 9000  ##

dude@remotebox $ cat backup.ico | nc -l 9000

## and now we tunnel! locally, ssh opens up on 9001, and        ##
## connects to 9000 on the remote machine where nc is waiting   ##
## with cat, ready to go.                                       ##

nurf@sessmacheen $ ssh -f -L 9001:127.0.0.1:9000 dude@remotebox \
    sleep 10; nc 127.0.0.1 9001 | pv -b > backthatthangup.iso;

## this is pretty sweet because after nc gets done with the     ##
## connection, ssh finishes running sleep and closes it so you  ##
## don't have to fool with it.  nice and tidy.                  ##

## pv is a handy little utility that tracks data across a pipe  ##
## and will show you a progress bar and whatever else you want  ##

Naturally, to create this connection in 'reverse', you just, you know, do it the other way 'round.  Backwords, if you will.  Let me know how it works!

Oh yeah, also: nc won't bind to 22 because sshd's oh-so-privileged self is already sitting there.  Hence the use of arbitrary ports outside the reserved ports range (i.e. anything above port 1024).  Since 22 is one of the reserved ports, you'd have to be root to bind to it anyway.


When a party authenticates itself using certificates it essentially proves that it can make use of the private key associated with the public key in the certificate - since it assumed that the private key is secret and only known to the owner of certificate.

To prove access to the private key the authenticating party signs a challenge which is at least partly determined by the peer (to deter replay attacks). The peer then can verify the signature using the public key inside the public certificate.

Since a successful signature only proves access to the private key for a specific certificate the peer also has to verify that the certificate matches its expectations, i.e. typically that it is signed by a trusted certificate authority (CA), has a specific subject, is not expired or revoked and has the correct key usage extensions.

Within TLS typically only authentication of the server is done, the signature is part of the ServerKeyExchange message and is done over various data which also include the client-determined ClientHello.random. The client typically requires that the correct hostname matches the server certificates Subject Alternative Names (SAN) or (older and obsolete) matches the certificate subjects CN.

With mutual authentication the server also requests the client to authenticate itself. This is done using the CertificateRequest message. This message can also a list of CA the server is willing to accept as issuer of the client certificate so that the client application can choose the expected certificate. If a client received this CertificateRequest and has a matching client certificate it will send a Certificate message with this certificate. Additionally it will  send a CertificateVerify message which includes a signature created with the client certificates private key and covering all handshake messages send so far - which include the server-determined ServerHello.random.

How exactly the client certificate is validated and associated with a specific client is not defined but it is common that any certificate issued by a specific CA will be accepted and that the clients name or email will be extracted from the certificate subjects CN.


.... ASN1_mbstring_ncopy:string too long:a_mbstr.c:158:maxsize=2
                          ^^^^^^^^^^^^^^^               ^^^^^^^^^

It is not about missing values but about an invalid value

When reading the documentation you'll see that using prompt=no changes the interpretation of the values in the config:

  prompt
  if set to the value no this disables prompting of certificate fields and just takes values from the config file directly. It also changes the expected format of the distinguished_name and attributes sections.

This means that it will not take your countryName_default field to fill in the value but it will actually take the countryName field directly. But this field has the value Country Name (2 letter code) which is clearly larger than the maxsize.

See also OpenSSL Config error when generating self-signed certificate string too long.


Choose a good password for full disk encryption

Here's a new method I've started using recently:

Pick 4-5 random words: piano, abstract, ruler, ivory, stream
Put them together with spaces in between: piano abstract ruler ivory
stream
Make some letters uppercase: Piano abstract ruleR ivory stream
Substitute some letters for numbers:
Pia4o abstract r0leR ivory
stream
Substitute some letters for symbols:
Pia4o abs#ract r0leR ivor! stre&m

New password:
Pia4o abs#ract r0leR ivor! stre&m


Password stretching using concatenation of hashes

"Long" does not make "strong". What matters is the entropy, a tricky word which means "that which the password could have been". A weak password is weak because it is part of a small set of possible passwords. The attacker is in your head; when you select a raw common English word he knows that he just has to try all common English words; there are about 10000 of these.

Now suppose that you have "stretched" your password. How many distinct stretched passwords can you end up with ? Still 10000. The attacker still has only 10000 passwords to try in order to break into your system. The stretching has make the passwords longer but not stronger because entropy has not changed.

At best, you can try to make each attacker's try as expensive as possible, and that's the role of bcrypt.


What is the purpose of the expiration time in signed S3 urls?

It is useful in the following scenario:

You want to serve, say, video files, but only to certain users. You want to make it harder for them to share URLs.

Bob signs in to your site, selects a video. You generate and HMAC the URL with the expiry time, set to say 5 seconds. The page loads in 1 second and the embedded video player makes the request to AWS. The URL is still valid.

Bob looks at the HTML source, finds the video URL, copies it and sends it to his friend. The friend opens the URL but it has expired.


is pkcs#7 suitable for signing and encrypting zip files?

PKCS#7, now known as CMS, is a generic format for message with some content which is signed and/or encrypted. The content is any sequence of bytes so you can fit any kind of file in it, including Zip archives.

Of course CMS is just a tool. Using it won't magically sprinkle security everywhere. You will need to use it with some public-key infrastructure which will take care of distributing the public keys (as X.509 certificates). 95% of PKI is management procedures, not software.


When I receive data in this scenario, how many times is it encrypted?

When using HTTPS, only the contents of the requests and responses are encrypted. The size of each message, the hostname of the web site you are visiting, and the fact that you are using HTTPS are not kept secret. If you use HTTPS over a VPN, the hostname and protocol are encrypted, but the message size can still be observed.

The traffic over a WPA2 WiFi is indeed encrypted, but it can be read by other people on the network that have the WiFi password.

So while the request content may be encrypted three times, this does not really provide "three times the security". It depends on what you are trying to hide from whom.


Technically "cracked" only means that a method was found that reduces guessing from random guesses to slightly less than random guesses.  The flaw that was discovered is one such minor crack.  A perfect crypto-system would require making 2^127th guesses on average to crack a 128 bit key.  The attack against AES allows it to be done on average in 2^125.1th guesses.  Sure, it is over 1/4 faster, but 1/4 of now to the heat death of the universe is still far longer than we need to worry about.

And if you are truly worried, up the bit depth of your key and it's even more unlikely to be cracked.  This is basically what the approach is for when 3DES is still used.  There are significant compromises against DES, but upping the key length and using 3 DES operations back to back results in preserving a relatively secure algorithm out of something that has actual significant weaknesses to cryptanalysis.


Computer-Related Risks by Peter G. Neumann classes preplay attacks as part of the "Playback attacks" category of risks and defines it as "preplay of a not-yet used message", to help understand this a little more I have included two real world examples.

Web Application example;
I would argue that a CSFR (Cross-site request forgery) attack is a form of preplay as you do not have to capture the user’s traffic, but instead are using their own session to play a valid sequence of activity.

Kerberos example;
An example of this would be if the attacker were able to compute a valid response to a kerberos challenge and send the expected reply before the real user. This could result in the attacker gaining access to the server within the context of the valid user’s rights.

So a pre-play attack is where an attacker is able to guess or compute a valid response to and send the reply before the valid user can. It is different to a replay attack, where the attacker would capture the whole challenge and be able to replay at a later stage.


Identifying documents by hash: what are the security implications?

DocBot would allow a malicious user to learn information (read documents) if DocBot is not designed to prevent brute force attacks.

Specifically, if knowing the hash is all the proof that is needed, then iterating a stream of hashes could, in principle, give up Alice's documents.


Determining network topology from the outside

Natting can help, but there are places where information leakage is common.  If you have internal mail servers you may be exposing your internal DNS naming conventions through mail headers.  IP addresses could even be listed in those headers depending on your configuration.

Error pages on servers in the DMZ could expose the internal (ie DMZ) addresses of hosts, and sometimes can even expose information about systems with interfaces internal to the network.

How much should you work to mask this information?  It depends on the sensitivity of the information you're protecting internally.  If you're extremely worried you'd want to look at application level firewalls that can strip that sort of information on the fly, as a double check to your configurations.  Further some systems just can't have these pieces of information hidden, and an inline solution could help cover the gaps.


Determining httpd PHP Scripts with Auditd

auditd cannot perform a stack trace or gain other information because it's only invoked on system calls or file access.  The stack trace is only accessible from userspace, and would require unwinding the stack, which would incur significant overhead.

As mentioned in the comments, you can add %P to the access log config to get PIDs for correlation with auditd, or log the full requests from mod_security.

You could also modify mod_php or use an LD_PRELOAD to add information to relevant requests on file open.


How secure are Google (Drive) Web Forms?

Assuming the school has a valid need for this information, and you are happy to provide it, this is probably one of the better ways to collect it. Compared it to asking for this via email, or paper form that then gets entered into a school computing system. Email is sent in clear text, anyone sharing the same network can see this traffic, including your ISP and the schools ISP. A paper form could get lost on the way to school or in the post, and once entered into the computer probably will get put in the rubbish, not shredded.

Googles servers themselves are very secure, the web forms are also very secure. I would be much more worried about the schools information security, irrespective of how it is collected.
The following are the questions you should be asking the school.

Why are they collecting this information and what use will it be put to?
Who have they given permission to view this information?
Do they require all those people to have two factor authentication on their
Google accounts?
Do they require all those people to only access
their Google accounts on fully patched computers?
Do they require all those people to run up-to date
anti-virus and anti-malware programs?

If I was a bad person wanting to get hold of this information I would not attack Google I would attack the machines/accounts in the school which have access to the information. This would remain the case no matter how the data was gathered as long as it was stored electronically.


The exception handler does not check the integrity of the canaries since the check code is called only when the function terminates. The attacker sould make sure that before the program reaches that code, an exception should be thrown!
Without further protections, the program continues to execute a manipulated exception handler because it does not know that it is malformed.
Corrupting a canary will not trigger an exception, the program will not know that the canary has changed until the integrity check. Overflowing a buffer, on the other hand, MIGHT trigger an exception (If, for example, the attacker overruns a pointer and points it to an area that is unreadable/unwriteable and then tries to read/write with that pointer).
Assuming that the shellcode is on the stack, we do not place the address of the shellcode in the address of the exception handler because Windows has a some basic defence mechanism that prevents exceptions from jumping to addresses on the stack. SEH was abused commonly and repeatedly, and so it was created.
Therfore, we use pop, pop, ret because we can easily find this code in the text segment (an area the exception handler CAN jump to).
For more details about the mitigation techniques please read about:

SafeSEH which defines exact addresses that allow exceptions to jump to them.
SEHOP which verifies the integrity of the exception handler list.

I also asked a question on the subject, you might want to take a look at it


Do any crypto libraries take advantage of Windows GPU API "Direct Compute"?

As Paulo quite rightly says in the comments, many encryption operations do not lend themselves well to parallelisation. For example, consider the two AES modes ECB and CBC. ECB consists of applying the AES transforms to each data point using various elements of the key schedule according to the position of the data modulo the key schedule length. Essentially, once you've generated the key schedule, you could easily parallelise AES in ECB mode.

Except that ECB is not a great mode of operation security-wise, because for larger amounts of data you begin to reveal patterns in your ciphertext. Wikipedia explains all of this much better than I can.

CBC mode can basically be described as "take the output of the last operation, xor it with the plaintext and encrypt the result". Typically, you start by xor-ing the first plaintext with an IV. For encryption, you must calculate each block at a time and so the operation is not at all suitable for parallelisation; however, for decryption, you can parallelise the process since a pair of blocks are all that are required to decrypt a block (i.e. if you have block 1 and block 2, decrypt block 2 according to its position in the key schedule and xor with block 1).

These are just some examples; some algorithms do lend themselves to parallelisation. Consider you want to try many passwords against some hashed password you have. Each hash calculation is hard to parallelise, since each block must be fed into the hash function by turn; however, what you can do is to do many hash operations at once - imagine setting off a thread for each hash attempt. Graphics processors are good at this kind of work as they're essentially designed to transform whole sets of co-ordinates in 3D space according to a mathematical result - basically, to do 3D graphics.

A good paper on this topic is Cuda compatible Gpu as an efficient hardware accelerator for AES. Bruce Schneier covers speeding up password cracking. Distributed hash cracking tools have also been studied and google turns up a number of implementations.

I expect that as more work is done, more and more methods will be found to take advantage of parallelisation, both in terms of cryptanalysis and in terms of cryptography. I am not a cryptographic researcher, however, so you'll have to take that with a very large dose of wariness.


As other people have already mentioned the practices you mentioned should be avoided, to stay on the safe side of things.

However, some companies have bug bounty programs in place that basically encourage and reward the report of vulnerabilities discovered on their platform (e.g. Google.) Also, there are platforms like HackerOne that aggregate bug bounties from different companies.

Of course companies that set up these bug bounty programs are usually very robust, so you'll have to try much harder to discover potential vulnerabilities.


Hack-resistant hosting solution for non-profit?

If the only thing you expose to internet are non-interactive web pages and do not need to run server-side components, then you can substantially lower your risks by using a static web site.

You are then left with the web engine itself and to some extend the underlying OS. Apache or nginx are not simple to harden so you could have a look at Cherokee or publicfile.

You can go one step further by either hosting your static files on an existing environment which accepts them (Github Pages for instance) or move to a site you build with blocks like Google Sites (which are free for non-profit organizations).


How did piratebay.se search engine get in Chrome as an "other search engine"

Chrome will automatically add search engine configurations any time you visit a site that has a compatible search box. If you don't want it to be there, then remove it.

How did it get there? The user went to the pirate bay, and chrome added it.

The answer to all of your probability questions is: not very probable given the fact that Chrome will helpfully add the search engine entry on its own for you. It is, however, very probable that the user has been using the pirate bay site.


Brute Forcing Password to a Truecrypt-encrypted file with Partial Knowledge

http://www.autohotkey.com/board/topic/86586-tcbrute-2-truecrypt-bruteforce-password-recovery/ seems like exactly what you're after.

The other one to try is OTFBrutusGUI - which can be had from http://www.tateu.net/software/ - though it has little documentation beyond scattered forum posts (such as http://www.tateu.net/forum/index.php and http://www.wilderssecurity.com/showthread.php?p=1834959).

More generally - John The Ripper (http://openwall.com/john/) is a generic brute-force tool often used and adapated to these sorts of scenarios. And TrueCrack (https://code.google.com/p/truecrack/) is specifically for missing TrueCrypt passwords. It goes almost without saying that these aren't effective at all against passwords you have no knowledge of (assuming a reasonable password strength).

Edit: Modern versions of oclHashcat are also capable of cracking Truecrypt headers; see https://hashcat.net/forum/post-15509.html also.


Help! My home PC has been infected by a virus! What do I do now?

What do I do now? How do I get rid of the virus?

The best option is what is referred to as "nuke it from orbit."  The reference is from Aliens:

The idea behind this is that you wipe your hard drive and reinstall your OS.  Before you do this, you should make sure you have the following:

A way to boot your computer off installation media. This can be in the form of the Install CD that came with your computer, or a DVD you burnt from an ISO file (Windows can be downloaded legally here). Some computers do not have CD-ROM drives anymore.  Microsoft provides a tool to convert their ISO files to bootable thumb drives. Do not create the install media on the infected computer.
Your Original Windows License Key. This can either be on a sticker on the side of your computer or you can recover it from your computer a program like The Magical Jelly Bean Keyfinder (which might contain malware, but it really doesn't matter because you are wiping it all after you get the key anyway). Or an official tool supplied with Windows called slmgr.vbs.
Drivers. If you don't have a second computer, you are really going to want to have at the minimum video drivers & network card drivers.  Everything else can be obtained online after you reinstall.
Any files you want to save.  You can back them up to a thumb drive for now, and scan them before putting them on your freshly installed machine (see below).

Do I really need to do a full reinstall? Can't I just run a couple of virus programs, delete some registry keys, and call it a day?

In theory, it is not always necessary to fully reinstall. In some cases you can clean the virus off the hard drive without a full reinstall. However, in practice it's very hard to know that you have gotten it all, and if you have one virus it is likely you have more. You might succeed in removing the one that causes symptoms (such as ugly ad popups), but the rootkit stealing your password and credit card numbers might go unnoticed.
The only way to kill everything is to wipe the hard drive, so your best option is always to nuke it from orbit. It's the only way to be sure.

I really don't have time to deal with this right now.  Is it dangerous to keep using the computer while it is infected?

You may not have time for it right now, but you really don't have time for your email getting hacked and your identity being stolen. It's best to take the time to fix it now and fix it right before the problem gets worse.
While your computer is infected all your keystrokes might be recorded, your files stolen, it might even be used as a part of a botnet attacking other computers. You do not want this to be going on for longer than necessary.
If you really don't have time to deal with it right now, power down the computer and use another one until you have time to fix it. (Be careful with file transfers from the infected to the uninfected computer, though, so you do not contaminate it.)

I don't have backups of my family photos or my master thesis from before the infection occurred.  Is it safe to restore backups made after the infection occurred?

Any backups made after the virus infection occured could potentially be infected. A lot of the times they are not, but they could be. Since it is very hard to pinpoint exactly when the infection occured (it may be before you started to notice symptoms) this applies to all backups.
Also, Windows restore points can be corrupted by a virus.  It is better to archive copies of your personal files on external or cloud storage.
If you are restoring them from external or cloud storage on a computer that has already been nuked from orbit make sure you scan all the files you are restoring before you open them. Executable files (such as .exe) can contain viruses, and so can Office documents. However, picture and movie files are likely safe in most cases.

Do I need to worry about peripherals getting infected? Do I need to do anything about my router or other devices on my home network?

Peripherals can be infected.  Once you have re-installed your OS you should copy all the files off your thumb drive, scan them with antivirus, format the thumb drive, and restore the files to the thumb drive as needed.  Most routers will be fine, however, it is possible for DNS settings to be compromised either through a weak password or malicious use of UPnP.  This can easily be resolved by resetting the router to factory defaults.  You may also want to configure your DNS settings to either google dns or OpenDNS. If you have some type of network attached storage, you should do a full scan of it with antivirus before using any of the files on it.
See Also: Help! My information has been stolen! What do I do now?
THIS IS WORKING DRAFT FEEL FREE TO WIKI/EDIT AS NEEDED


To expand on Thomas's answer and my comment, in this particular case:

Exporting AES-256 encryption to certain customers is restricted by the US Government.
For example, if you are selling to the government of China, you need an export license. But you can sell to a private entity in China.

You can not get a license to sell to certain embargoed countries and persons:

These include Cuba, Iran, Iraq, Libya, North Korea, Serbia, Sudan, Syria, and Taliban-controlled areas of Afghanistan.
Some countries, including China and Russia, require an import permit (or prohibit import) for encryption products.

Which doesn't give you a definitive answer where the cloud is ill-defined, so the solution will be to use a cloud provider who will agree under contract to limit the geographical distribution of your cloud. Many already do this - e.g. IronMountain allows you to choose the exact locations you want your data to be in, and cloud providers in the EU are supposed to keep customer data within the EU.


Is it Possible for a Java Applet to Record Cursor Movements Inside the Applet?

Yes, it is possible to track mouse movements with Java:

http://docs.oracle.com/javase/tutorial/uiswing/events/mousemotionlistener.html

Or

https://stackoverflow.com/questions/18321877/tracking-mouse-movement-in-java

Or

http://mrbool.com/creating-a-simple-mouse-analyzer-with-java-swing/24507


Does a hardware generated pin plus SMS verification count as two factor authentication?

Strictly speaking 2FA only means two factors are used to authenticate a user.

What we usually see is a password based authentication coupled with an SMS or app (e.g. RSA Secure ID or Google Authenticator) generated OTP (One-Time Password) code.

In your example, two factors are used.

Hardware generated PIN
SMS verification

However this doesn't comply with the best practice where at least two of the following principles are considered.

Who you are (Identification), like just giving your username.
What you know (1st Authentication), like giving your password.
What you have (2nd Authentication), like giving an OTP from a token/app.
What you are (3rd Authentication), like giving IRIS-scan or fingerprint (although this is debatable because some state that bio-metrics is a means of Identification).

Both the SMS and the hardware generated PIN are in the category 'What you have'. If you use two 'What you have' factors, both are equally likely to be stolen [Remember why noting down passwords is a bad practice.]


Is running wp-cli as root in docker container dangerous?

Whilst it isn't generally a good idea to run as root, doing so in a container is generally less dangerous than on the host and if you're using Docker => 1.10 with user namespaces enabled, the concern doesn't really apply as root in the container is not root on the host.

Without user namespaces there are risks in running a container as root as if an attacker is able to break out of the container isolation they will be root on the host.  That's not to say that it's necessarily trivial to break out of the container.  Docker uses linux features like namespacing and capabilities to reduce the rights of the running process.

With User Namespaces, the root user in the container is mapped to a non-root user outside the container, so in the event that the container is breached the user would just be an ordinary low-privileged user.  Software which isn't container-aware will likely still complain as it doesn't realise that it's not using the "real" root user.


How to MiTM insert an iframe using burp or another tool?

You can do this using the Proxy tool (tab) of Burp. Just be sure that you added the host (msn.com in this case) to the Scope and check the "Intercept server responses..." check box on the Options tab (under Proxy).

This way all the server responses will be displayed on the Intercept tab where you can place arbitrary content in them.

You can also use the automatic Match and Replace feature under Proxy/Options.

http://portswigger.net/burp/help/proxy.html


How to configure a VM to protect all my hardware fingerprint from guest OS and softwares?

As the other answer has pointed out, emulating another architecture tends to be slow. This would tip off a would-be attacker there's something going on by short and simple code that tests execution timings.

Beyond installing a virtual machine with all the defaults selected, you could fake the processor and motherboard information. This again wouldn't hold up to any serious or rigorous poking by an attacker.

A simpler method would likely involve "blurring" or "fuzzing" the fingerprint your machine gives. An easy way to do this would be by rotating through virtual machines in a given day, all setup differently from one another.

Regardless, even if you could truly and hypothetically defeat fingerprinting of your machine's components, ad companies spend a large amount of effort on user tracking across devices. You would have to change your browsing habits across many devices to have some tangible effect. This is one of the many reasons I cite for "serious anonymity isn't for casual users".


Will CA's still validate internal IP's in SSL certs?

For public IP it must be checked that the IP is actually owned by the one who requests the certificate. Issuing certificates for private (reserved) IP is deprecated because obviously the ownership cannot be checked.

For more information see CA baseline requirements Sect 9.2.1.


Most phones have the cellular network interface share some memory with the main processor (I wonder if it's cooperation between manufacturers and carriers/law enforcement to give them potential access to the phones?). As a result, a compromised/malicious cellular NIC could take over the entire machine.

There are ways to mitigate this without completely disconnecting from the cellular network though. For example, this guide explains how to harden an Android tablet, and they use an external cellular modem connected over Wi-Fi (which limits its ability to do nasty stuff). USB dongles are also safe assuming you protect against BadUSB (if the dongle suddenly decides to turn into a "keyboard" and starts typing in malicious stuff). A separate mobile phone used as a hotspot would also be safe.

Basically all you need to do is get an "external" cellular modem, something that doesn't directly have access to your system's memory. Once that's done, the rest is standard network security techniques which are fairly well understood and there are many questions on the subject already (and a phone in this case is no longer that different from a standard networked computer).


PuTTY does not store its configuration in a file. However, PuTTY can use a "proxy command", as described here.

In your case, the example config file shows that there should be two encapsulated SSH connections:

The outer SSH is done to host login.nets.***. When that connection is done, the command nc is run on that host: it basically forwards data bytes to port 22 on the inner host zeus.nets.***.
The inner SSH is done again from your machine, to host zeus.nets.***, with all data bytes sent through the outer SSH.

In the ProxyCommand option, the ssh login part is the invocation of the outer SSH when the user (or your GUI application) tries to connect to "zeus". It is not obvious whether PuTTY itself can be invoked that way: there is a command line but you also need the "inner PuTTY" to forward all its bytes to the "outer PuTTY", and it is unclear whether that "outer PuTTY" will accept the bytes on its "standard input" (Windows is not Unix, and, moreover, PuTTY does not expect to run in a terminal or on raw bytes; it more tries to open its own window).

Possible alternatives:

Try to use port forwarding. In that case, you manually start a PuTTY to login.nets.***, with a port forwarding from local port 5000 (that's an example) to remote host zeus.nets.*** and remote port 22. Then you configure your GUI to talk (with PuTTY) to localhost on port 5000. When the GUI launches the PuTTY which connects to localhost on port 5000, the other PuTTY (the one you started manually) forwards the bytes to host login.nets.*** with instructions to open a connection from that host to zeus.nets.*** on port 22.

This may or may not work, depending on the configuration of the SSH server on login.nets.*** (support for such tunnels can be enabled or disabled by the sysadmin).
Use a more Unix-like SSH client, e.g. through Cygwin. Since this is the usual OpenSSH, it will be able to read and use the provided SSH configuration file, and do the nested invocation. Of course, there is no guarantee that your "SourceTree" application can be configured to use such a SSH client.


If you want to replay the exact request you have in the file as plain HTTP you can simply use netcat:

cat request.txt | nc host 80

If you want to replay it as HTTPS instead of HTTP you can use openssl s_client:

cat request.txt | openssl s_client -connect host:443 -servername host


Credential encryption scenarios using certificates

Your approach seems sensible from the point of view that a given server will be able to pull a file (presuming each file has only one password), decrypt it and extract a password. Knowing that other servers will be able to pull the same file but won't be able to decrypt it. And whoever holds the set of public keys will be able to decrypt the files if they can extract them.

There's caveats that you should be aware of however:

Trusting that only local admins can access the certificate is simplistic. For example if the file system can be read off a snapshot or by cloning a VM or in some other way outside of the environment of the running server, this information will be accessible and the code tasked with pulling the file and decrypting the password will be visible;
The way the actual password is handled on the server will dictate how much of it is left behind in memory or on the registry, etc. This would include decrypting the file [left in memory or on the file system], running the task that uses the password [password shown in cmd line and left in memory whilst and after the process terminates], closing/deleting the decrypted file [left behind on the file system], etc;
Passwords are also exposed at the time of encryption, where all the information is (very likely) available to obtain the password, decrypt the file and possibly extract all keys and decrypt all files to extract all passwords;

All these things, depending on how you implement the details of the system, could have a manageable risk. It's entirely up to you and your business to measure and assess what's acceptable.

Generally, unless you run a very careful audit of the code that implements the powershell module, I'd be wary of using it to handle sensitive data. The chances of it being broken or easily hackable will vary from very low to trivial, so until you know, I'd err on the side of caution and assume it is trivial.


How could malware disable third party security software?

So in the event of a malware infection, what's the stop the malware from simply disabling the firewall the same way as the user?

Nothing.

If the malware is coded to do such things (which some samples are to some extent) they absolutely will.

If you are logged in with an account with local admin privileges, then this could explain why you can make changes without elevation. This is a bad security practice and a significant advantage for malware, which most samples are known to absolutely exploit local admin privileges to do make changes and ensure persistence.


Can websites send WhatsApp messages without my permission through the WhatsApp API?

No.

It no way possible can they do this with out having you security token (Lets call it your login credentials).
The PHP API you saw is an unofficial API and requires logging in when starting it up.

What can a website do?

There is something called WhatsApp URI which lets websites build a custom link that upon pressing will redirect you to WhatsApp so you can share their content (See more here).


As mentioned in the comments, try and IDS or IPS. My favorite and free one is hostbased and called  OSSEC.

It will alert you of break-in attempts and other irregularities on your machine.


Can using emojis make someone's password safer?

The difficulty of cracking a password is measured by the entropy in the process used to generate it. This can be measured for most passwords by taking the base-2 logarithm of the number of symbols raised to the power of the number of symbols used. For instance, a randomly-chosen password consisting of 8 lowercase letters has log2(26 ^ 8) ~ 38 bits of entropy in it.

This method can be extended to "correct horse battery staple"-style passwords. In this case, each word is itself a symbol, chosen from a dictionary of the 10,000 most common words. A password generated randomly this way would have log2(10,000 ^ 4) ~ 53 bits of entropy, and be significantly harder to break.

Hopefully by seeing these two examples, you can see that dramatically increasing the base has a far, far smaller effect on password entropy than modestly increasing the exponent. This is important, because by adding additional symbols to choose from (uppercase letters, digits, symbols, and at the extreme, non-Latin Unicode code points like emoji, RTL markers, kanji, etc.), you're increasing the base and not the exponent. This will generally make your password harder to crack, and may even make it more memorable to you, but increasing the length (and thus the exponent) will help even more.

For instance, by including lowercase letters (26), uppercase letters (26), digits (10), common symbols (32), and a handful of emoji (say 200, for example's sake), a random eight-character password will have log2(26 + 26 + 10 + 32 + 200) ^ 8) ~ 66 bits of entropy. On the other hand, simply doubling the length of a password consisting only of lowercase letters would result in a password with log2((26 ^ 16) ~ 75 bits of entropy, which is over five hundred times more difficult to crack.

While adding emoji can make a password stronger, it's not as effective as simply increasing the length. It won't turn a terrible password like Password15068 into something meaningfully more difficult to crack. And it simply won't work in many real-world password input fields (some will reject it outright, and worse, many others will silently ignore the character). Furthermore, a two-character password like  will never be secure, for the simple reason that there are only a handful of emoji to choose from; even if you assume ten thousand of them, you're left with a password with only log2(10,000 ^ 2) ~ 27 bits of entropy.

Your best bet is to simply use a password manager. Humans are terrible at memorizing complex passwords, but computers are great at it. Password managers give you the benefit of strong, unique passwords for every site you visit and remove the weakest component from the chain: the human.

Update: I didn't make this clear in the original post, but linear increases in entropy represent exponential increases in difficulty to crack. A password with n bits of entropy requires 2^(n-1) operations on average to crack, so each time the entropy increases by one, the effort required to break the password doubles.


Not really.  You could use some proprietary DRM that does something along these lines and works with browsers, but you are probably better off decrypting on the server side and transporting the video content over TLS to protect it from interception.

To clarify based on your additional information you would have a web application server that decrypts the videos on the fly as it loads them from the cloud storage.  This should be achievable by streaming data from the cloud storage and then streaming the decrypted output over HTTPS to the browser.  Getting this to scale may be quite tricky though as you'll be held back by the latency of the cloud storage.  You may want to prefetch of cache popular segments of videos on your web application edge or go with a video-capable CDN (content distribution network) if your cost model permits that.

If you can do decryption in JavaScript and you can use WebSocket or WebRTC to send binary data streams, then you can decrypt the buffers as they arrive.  Feeding the decrypted data into a player of some sort incrementally is the next step.


What is the difference between local file inclusion (LFI) and remote file inclusion (RFI)?

Your confusion stems from your over-broad understanding of directory traversal.

Traversal means one can read from another directory. Not specifically that one can read a file.

LFI is reading a local file, either in the current working directory or, using traversal, a file in another directory.

RFI is including a file from an external source.

It is possible to have an LFI vulnerability without there being a directory traversal vulnerability (files local to the current context). And, technically, it is possible that there can be a traversal vulnerability that does not result in a LFI.


Simple, malware-resilient, automatic Windows backup (or: How should the average small company protect their Windows server?)

Apart from the new-ish requirement for malware resistance (specifically ransomware resistance), what you describe is the definition for backups though it is missing the requirement for backups to be in multiple locations.

Backups aren't really Backups unless they are fully automatic. They need to be capable of operating for years without manual intervention.

The malware issue is dealt with in two ways:

Backups need to be versioned so that if one or more files have been encrypted by ransomware, you can reach back in time to a previous version. Of course, the additional requirement is that the backup media itself must either be versioned or immune from ransomware.
Backups must not be susceptible to corruption or deletion by malware (or by anything else for that matter!)

Any decent commercial backup tool will give you all of your requirements. Where things get tricky is where you are trying to shave costs and use semi-pro or consumer level backup tools. In that case, you may need to take some steps for yourself and this appears to be what you are describing here.

An example of a consumer solution that delivers all the requirements of a secure backup service both in the cloud and on private servers is CrashPlan. An example of a client tool that can be used with multiple storage locations is SyncBack Pro. There are many others.

SyncBack Pro can be used with many different storage locations including Amazon, Azure and others but do watch out for the backups becoming susceptible to corruption from malware, don't mix backup locations with file-sync locations for example. It also allows you to keep versioned backups though you have to remember to configure this yourself as it isn't the default.

You should be aiming for at least two different locations for backups no matter what tool you use. Ideally backup locations should not be accessible directly as file-systems as this leaves them vulnerable to a lot more malware.

As an example, for myself and family, I use CrashPlan to backup both to the cloud and to a local NAS. In addition, some critical files are also copied to versioned filing systems, generally both locally (NAS again) and in the cloud.

Bottom line is that, if you value the data, back it up using a recognised, trusted, commercial backup tool to multiple locations which are not accessible as a filing system and make sure the tool lets you keep multiple versions.


How can antivirus companies analyze the large amount of samples that they receive?

Ok, I've found the answer. AV companies use clustering/classification techniques in their propietary analysis tools. These are some examples:

Kaspersky uses Astraea [1]: a machine-learning based malware analysis system. Astraea automatically analyzes notifications from protected computers and helps uncover previously unknown threats. By using the threats’ metadata (like age, origin, filename, file path and more) the system is able to fully detect threats without information about the file contents (only static features?).

Comodo uses Valkyrie [2]: it's a cloud based file analysis platform providing static, dynamic and even human expert analysis for submitted known and unknown files. Valkyrie processes over 200 million unknown file submissions each day. Some of the Machine Learning techniques Valkyrie employs include support vector machines, naive bayes, decision trees and random forest classifiers. Additionally, Valkyrie will employ linear discriminant analysis, stochastic gradient descents, hidden markov models and neural networks, just to name a few.

Avast uses Medusa [3]: a GPU-powered classification system. Every Medusa node uses two or four Nvidia GPUs. Each sample is represented by a constant-sized feature vector consisting of approximately 100 attributes. Taking into account the nature of the attributes, they ended up with several distance operators and a weighting scheme that equalizes the importance of the attributes. They use a kNN classifier. Their internal systems handle around 250,000 new PE files every day. They claimed to use complete linkage, this means their algorithm to find the clusters could be the agglomerative hierarchical algorithm.

Avira’s Cloud Protection [4]: Avira uses big data analysis to automatically determine if a newly discovered sample belongs to a known family of malware. At any given minute, they are processing 1.3 Million malware updates on their servers worldwide. In one day alone, their Avira Protection Lab honeypots will receive more than 130,000 new malware samples to analyze.

Microsoft Azure Machine Learning [5]: They use probabilistic machine learning to find patterns in the data that may have been undetected by the more blunt deterministic technique. The algorithm runs without human intervention and produces a map of sorts. The map shows populous clusters, less populous clusters, and perhaps a few outliers or very sparsely populated clusters. At this point, a human expert is called in to look at the clusters and decide if a cluster is a normal process or malware.

BitDefender [6]: uses several machine learning techniques (Perceptrons, Neural Networks, Centroids, Binary Decision Tree, Deep Learning, etc.) for several tasks: filtering URLs, identifying malicious files and to classify emails.

Symantec uses Cynic [7]

References (I haven't enough reputation to put them as links):

[1] usa.kaspersky.com/about-us/press-center/press-releases/2016/Kaspersky_Lab_Number_of_the_Year_2016_323000_Pieces_of_Malware_Detected_Daily

[2] enterprise.comodo.com/valkyrie/

[3] avast.com/technology

[4] blog.avira.com/virus-hunters-catch-bad-guys-part-2/

[5] microsoft.com/itshowcase/Article/Content/618/Improving-network-security-using-big-data-and-machine-learning

[6] businessinsights.bitdefender.com/machine-learning-apt-detection

[7] symantec.com/connect/blogs/myth-busting-next-generation-threat-protection


ISO 27001 scoping for small company using all cloud-based services

Unfortunately, it is not possible right now to certify a company to ISO 27001 without a physical location in scope @Santhosh.

While @Tom is right by stating there is nothing in the ISO 27001 standard that mandates a physical location, you will have a really hard time finding a certification body willing to accept such a scope.

This is because the document:

"ISO/IEC 17021-1:2015
Conformity assessment -- Requirements for bodies providing audit and certification of management systems -- Part 1: Requirements." that is available here: https://www.iso.org/standard/61651.html states in clause 8.2.2 a) that a geographic location is required for the certificate.

With no geographic location to place on the certificate, no certification body I have been able to contact is willing to certify the ISMS.


JavaScript eval() to parse JSON after sanitizing with regexes — is XSS possible?

My immediate reaction to this was not positive, for a few reasons.

Trying to use regex to parse complex language constructs is a bad idea. Regular expressions just aren't suitable for such constructs.
Security through blacklisting is a bad idea because you will always be, by definition, one step behind the attackers. You should use a positive security model.
There are a huge number of XSS filter evasion techniques that can be used on top of standard vectors. You cannot possibly detect and block them all.
Javascript parsing of JSON via eval() is considered a security vulnerability.
Modern browsers have support for proper native JSON parsing, via JSON.parse() and JSON.stringify().
If you have to support old browsers, there is a safe JSON library you can use that does not use eval() for decoding.

All in all, your regex approach is over-engineered, insecure, misguided, and redundant. You're attempting to solve a problem that has already been solved. Don't be a Dave. Use the proper JSON parsing functions and libraries available to you.


Why are AMD processors not/less vulnerable to Meltdown and Spectre?

Only Meltdown is specifically an Intel vulnerability / design flaw.
update: it seems AMD is mostly resilient to Spectre.  It's not clear why that would be the case.  But according to AMD:

(from early January, now replaced, see update 2 below)
Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 (Branch Target Injection) has not been demonstrated on AMD processors to date.

Note that it's only a "near zero", unlike the "zero" for Meltdown.  (And that the "bounds check bypass" Spectre v1 attack (conditional direct branch before an array access) still needs to be fixed in software.)
update 2: AMD may have underestimated Spectre, because they are still releasing microcode updates, and their web site now says:

GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.

While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat.

It's still not clear what microarchitectural design feature / difference makes AMD CPUs any more resilient than Intel; they do still have a large out-of-order window and AFAIK are not significantly more limited in what can be in flight at once.  But their branch predictors are designed differently, and are maybe harder to mis-train or are somehow insulated across privilege boundaries?  But the latter would make them immune to Spectre v1 as well, and AMD CPUs are just as vulnerable to the bounds-check bypass version of Spectre.

Spectre (v2) affects any "normal" CPU design with branch prediction + speculative execution for indirect branches.  In Spectre, the attacker primes / trains the branch predictor to mispredict the target of an indirect branch in kernel code or in another process.  Until the mis-predict is discovered, the privileged process will speculatively execute some instructions that change the micro-architectural state of the machine in a way that depends on secret data.
(Then the attacker uses a cache-timing attack to read that microarchitectural state, the same as in Meltdown.  When attacking the kernel, you'd ideally choose a "gadget" that uses the secret data to index an array your attacking user-space code also has read privilege for.  If you can't, you might have to use a cache-eviction timing attack to look for which set of cache had a line evicted instead of looking for a line that became hot.)
Defeating Spectre in HW might take something as costly as flushing the branch-predictor caches on every transition across trust boundaries.  Or at least the indirect-branch target prediction buffers.  (kernel / user is one the HW is aware of, but into sandboxed JIT-compiled code (especially Javascript) is a problem.)

The key to Meltdown is that Intel CPUs (but apparently not ARM or AMD) don't squash under-privileged TLB hits.  The load executes, and so do following instructions, and it only actually faults when the faulting load tries to retire.  This allows unprivileged code to directly cause changes in the microarchitectural state itself, based on data it doesn't have permission to read, instead of (Spectre) tricking a privileged process into doing it.
(Note that you only get actual data if the line was already hot in L1d cache;  It seems that on CPUs even repeated Meltdown attacks on the same line won't cause the CPU to bring a line into cache if it wasn't there already.)
;; run this in user-space
;; (and suppress or catch the fault somehow so you can do it quickly/repeatedly)

;; clflush all the cache lines in local_array (which you have permission to read)

;; create a long delay before following instructions can retire, but with few uops so OoO exec can see past it
times 30  sqrtpd  xmm0, xmm0     ; high latency per uop

movzx  eax, byte [kernel_byte]    ; eventually faults, but OoO exec continues first
shl    eax, 12
mov    eax, [local_array + rax]   ; the cache-line this touches depends on the secret data
;; after the movzx faults, the cache-line touched by the mov will still be hot

; then check which cache line of local_array is already hot.

(And BTW, I emailed the authors of the Meltdown paper about this.  They were in a rush to get it published by the public disclosure date which apparently moved up by 1 week unexpectedly.  They are planning to clarify their section on the microarchitectural details to make it clear that this is the real design flaw that enables Meltdown.)
(Meltdown depends on the kernel keeping its pages mapped into the virtual address space of the process, but with a bit set in the page table entries that flag them as kernel-only mappings.  This makes system calls and interrupts cheaper, because they don't have to modify the page tables to allow access to kernel memory: the CPU just starts allowing those kernel-only mappings to work when running in ring 0.  See this Q&A for a diagram of the x86-64 page-table entry format.  The U/S bit (user/supervisor) is the one that controls whether a mapping is kernel-only or not.)
The fault that's eventually raised is either handled (catch SIGSEGV), or suppressed (run the transient sequence inside a TSX (transactional memory) transaction, or as a result of mis-speculation).  So in Meltdown, branch mispredicts are only relevant as part of making the attack efficient and reliable by suppressing the fault on the load from a kernel virtual address.  Speculative execution past a faulting load is key, though, even for dependent instruction.  (Not just for independent instructions executed before a load-address is ready or anything that simple).

Presumably AMD's load execution units / TLB are designed differently, with privilege checking for loads applied earlier or differently.  Either a load from a virtual address with a kernel-only mapping is treated the same as a load from an unmapped page, or the physical page bits used for speculative execution are set to all-zero or all-one or something.  Or maybe it just squashes the load without triggering a page-walk (like a load from an unmapped page would).
Note that x86 doesn't require TLB invalidation when changing a page table entry from invalid to valid, so the address-translation hardware isn't allowed to do "negative" caching.  Or if it does, it would have to be coherent with page table writes that make previously-invalid entries valid.  Intel CPUs do a kind of TLB shootdown to maintain coherence for TLB entries that were only speculatively loaded, going beyond what the x86 manuals require to avoid breaking old code that existed before the current TLB-invalidation rules were published (e.g. Win95 through ME).

The point is, a different microarchitectural design choice could totally block the thing that Meltdown depends on.  And such design choices are plausible on their own, not specifically to avoid Meltdown.

A related question: why does Intel's delayed permission check design choice make sense?
Until Meltdown / Spectre, CPU designers were only worried about making sure memory protection applied to the architectural state (non-speculative values in architectural registers, not physical registers used by out-of-order execution).  i.e. this side-channel wasn't on anyone's radar.  The results of instruction execution don't become architectural state until retirement, so that's the point when everything has to be correct (in pre-Meltdown thinking).
As a CPU designer, you want everything to execute as efficiently as possible, with as few special cases as possible.  Or especially, with special cases in as few components as possible.  It's simpler for the overall design if an execution unit can never stall, so that a pipelined section of logic doesn't need any flow-control, just simply always accept one new input per clock.
(Update: an alternative to stalling is to report failure.  Load uops in Intel CPUs can already report failure back to the OoO scheduler and need to be replayed.  This happens on L1d cache misses, and on detection (during address calculation) of a cache-line split (to get data from the other cache line), or if the load port tried to use the 4c latency special case for simple addressing modes but the actual address was in a different page than the base register.  And even replay of other uops dependent on a load that were dispatched in anticipation of a load producing its result in a certain cycle.  Cache misses cause that, too.  So in theory under-privileged loads could use this mechanism to effectively not produce a value.)
It looks like Intel's current load execution units don't have a way to squash the load on a TLB hit.  The TLB itself is a CAM (Content-Addressable Memory).  Managing TLB entries with speculative (prefetch) page-walks involves some more active hardware, but the TLB itself has to be fast to support 3 lookups per clock (from ports 2, 3, and 7).
Most code doesn't page-fault by trying to load from kernel addresses, so optimizing for that case wasn't a consideration.  If such loads are seen by out-of-order execution, they usually happen as a result of mis-speculation (running a load instruction with the wrong data in register).  (Not necessarily maliciously induced mis-speculation (Spectre), just the regular kind from imperfect branch prediction.)  Not doing anything about a TLB-hit faulting load until retirement is a good design decision if most of the time it never reaches retirement because a branch mispredict or other mis-speculation is detected earlier in in-order retirement.  Wasting load bandwidth and causing cache pollution is questionable, but (other than Meltdown attacks) this is probably a pretty rare case so keeping the hardware simple was the most valuable thing.
Usually page-faults happen because of access to an address which isn't mapped at all: the page table entry is marked Invalid, not just kernel-only.  Or even a higher level of the 4-level nested page tables is invalid, e.g. the page-directory entry.  As mentioned earlier, negative caching isn't architecturally allowed (and AFAIK isn't done with snooping for correctness either), so such PTEs will never appear in the TLB.  A page-fault for an unmapped page will be raised only after a page-walk (which finds the mapping for that page doesn't exist).  x86 has dedicated page-walk hardware so the page-table loads can happen in the background while the execution units run other uops.  (Skylake even has two HW page-walk units).  But anyway,
So a page-fault from trying to read a kernel-only mapping is a special case, very different microarchitecturally from the unmapped-page case.   (It's actually similar to trying to store into a read-only mapping, which presumably also has delayed faulting.  Stores don't become globally visible right away; the store buffer makes speculative store execution possible by keeping them private until after retirement, at which point they can commit to L1D).

How could Intel fix Meltdown in future hardware?
Fixing Meltdown is relatively easy (compared to Spectre), although it probably can't be done with a microcode update.  As well as setting a fault-if/when-this-reaches-retirement bit on the uop, a TLB lookup could gate the page-address bits (to all ones) with the privilege-check.  e.g. a load in user-space from any kernel page could micro-architecturally execute as a load from the very top physical page.  (And systems with less than the max amount of RAM wouldn't have any physical RAM at that physical address.)
Or a failed privilege check could maybe still allow the load to happen microarchitecturally, but mask the result to all-zero in the load port.  (Remember, the Meltdown problem isn't that an unprivileged load can bring kernel data into cache, it's that the secret data load result can be used to make another load with a data-dependent address.  Continuing speculative execution with a zero result for any under-privileged load that hits in the TLB wouldn't allow any data-dependent microarchitectural effects).
The TLB lookup happens in parallel with indexing the VIPT L1D cache, but the TLB result is needed for the tag-check part of an L1D cache load.  So requiring the TLB lookup result is already needed to select the right way from the set indexed by address bits 6 to 11.  (L1D is 8-way set associative).  So also requiring the TLB permission check to be ready this early shouldn't introduce any extra latency.  Masking with the permission result would introduce one extra gate-delay, but one clock cycle has time for many gate delays.  (e.g. 64-bit add latency is only 1 cycle, 64-bit imul latency is only 3 cycles on Intel Sandybridge-family.  http://agner.org/optimize/).

You could even design it so a load that would fault (if it reaches retirement) doesn't complete execution at all, and no load result is forwarded to dependent instructions.  Maybe even squash it so it doesn't send a memory request down the hierarchy towards outer caches if it wasn't in L1D cache.  (i.e. don't even check L1D for it).  This might be a more tricky design.
(But some CPUs do work that way, according to Henry Wong's tests: e.g. AMD CPUs don't produce a result at all for Meltdown tests, vs. some non-vulnerable CPUs like Via Nano producing zero or Pentium Pro producing some random internal value.)
This design could make it impossible(?) for a user-space process to even detect whether a kernel address was mapped or not by any kind of timing attack, because the micro-architectural effect of a load to a kernel-only mapping would be the same as to an unmapped page.  (But actually only the same if it also triggered a page-walk.  An under-privileged TLB hit wouldn't trigger a page walk, and you could probably detect that directly.)
This might be valuable to stop processes defeating KASLR, if the kernel uses anything smaller than 1G hugepages to map any of its own memory.

Further reading about CPU internals:

Modern Microprocessors
A 90-Minute Guide!.  Why out-of-order (and speculative) execution is a thing in the first place, and the difference between CPUs with / without it.
David Kanter's Haswell microarchitecture write-up
What Every Programmer Should Know About Memory by Ulrich Drepper.  And a 2017 review on minor changes since it was published in 2007.
Agner Fog's optimization guide and microarchitecture guide

Meltdown-specific details:

The Microarchitecture Behind Meltdown - Henry Wong's detailed tests.

Encouraging the CPU to perform out of order execution for a Meltdown test - I think data is only vulnerable to Meltdown when something that is allowed to read it has brought it into L1d. (Directly or via HW prefetch.)

https://stackoverflow.com/questions/50191769/does-the-meltdown-mitigation-in-combination-with-callocs-cow-lazy-allocati - speculative execution into kernel code from user-space isn't possible.  i.e. a page-fault handler can't speculatively execute, because CPUs don't rename the privilege level.  See that for more about how CPUs take exceptions.

Out-of-order execution vs. speculative execution