What files can I keep to reinstall an infected system without getting infected again?

I'm quite sure my Windows PC is infected beyond salvation and I want to format it and reinstall everything. However, I have a 128 GB SSD where I keep only the OS and a 1 TB hard disk where I have programs and all of my files. If I boot from Linux to save whatever I can save, what should I save and what should I be careful about completely deleting?

If you have backups from before you got infected that could not be accessed by this system after it became infected, just nuke everything and restore from those.  If not, continue reading.

  I guess all executables are better deleted as a malware with control of the system could've replaced them with malicious versions? And what about other kind of files?

Office documents and PDF's are the big ones to make sure and remove.  Both of them are pretty actively used attack vectors, and just loading an infected one is quite often enough to compromise the system.

Others include (but are not limited to) JAR files (which are Java executables), any virtual machines you might have on the system (they're probably infected), and anything inside C:\Windows.

  In particular I'm concerned about my emulators and ROMs of retro consoles. I'll probably delete all the emulators, but are ROMs at risk? Can they easily be corrupted to become malicious software?

The ROM's are probably safe.  While they actually are executable code, they aren't native code and they aren't highly portable, so they're not easy or attractive targets for malware.  Unless you can reliably determine that you were infected through one of them, you can probably safely assume they are not infected.

  And in general, can I keep documents, videos and music?

Documents other than plain text files should probably be wiped.  Videos and music may or may not be safe to copy over, they're not hugely common attack vectors (so the same argument as used for ROM's (if you can't determine that you were infected because of them, they're probably safe).

  And if any executable slips through and I don't manually execute it, could it cause any damage?

If you're doing this right, no executable files should remain from the old system, at all.  This is not a case where you should be using the built-in factory reset provided by Windows, you should be wiping the drive and doing a clean install from installation media (which should be prepared on a separate system if you need to create it).  In an ideal scenario, you should actually get a completely new system (or, at least, a new motherboard, CPU, RAM, hard drives/SSD's, and any add-in cards), not just reinstall, because you can't be sure the firmware isn't compromised.

Also, when copying out old data, make sure you copy just the file contents and filename.  If you copy things in a way that preserves any further metadata, you run the risk of accidentally copying contaminated data (malware likes to hide in NTFS alternate data streams).


Tracking sender of Email via email address ONLY

Only the address?  Not possible.  Even with the full headers of the email it can be difficult to trace, because it's possible to forge most of them.


Claim that Skype is an unconfined application able to access all one's own personal files and system resources

Why am I getting this message?

The idea of snap is to be an "app store for Linux", with much of the same benefits as app stores for other platforms, such as iOS or Android. One of the big advantages is that applications are rather confined, unable to interact with your OS unless the user gives it specific permissions.

In snap, there are several different "confinement" settings, as documented here:

  Strict

  Used by the majority of snaps. Strictly confined snaps run in complete isolation, up to a minimal access level that’s deemed always safe. Consequently, strictly confined snaps can not access your files, network, processes or any other system resource without requesting specific access via an interface (see below).
  Classic

  Allows access to your system’s resources in much the same way traditional packages do. To safeguard against abuse, publishing a classic snap requires manual approval, and installation requires the --classic command line argument.
  Devmode

  A special mode for snap creators and developers. A devmode snap runs as a strictly confined snap with full access to system resources, and produces debug output to identify unspecified interfaces. Installation requires the --devmode command line argument. Devmode snaps cannot be released to the stable channel, do not appear in search results, and do not automatically refresh.

The Skype app is most likely a "Classic" snap, which means you don't get the same benefits as from a strict confinement.

Can Skype really do anything on my system?

Skype can do as much as any other traditional binary can do, such as those installed via apt. It does not generally become "some kind of super user", but it could use sudo or other means to ask to become a privileged process. The easiest way to do that is to simply refuse running as anything but root.

However, Skype cannot magically bypass any file permissions, unless you specifically gave the binary capabilities to do so.

What does it mean by system resources?

Think about apps on your smartphone. Applications have to ask to access your files, your contacts, your microphone, your camera, your location, etc.

Snap in its strict confinement setting does allow applications to access these, but individual applications need to request access to these interfaces. Of course, you as the user can forbid an application from accessing them. Perhaps you don't want an application to access the network because you don't want to use network-enabled features.

What the installer is telling you is that, since Skype is a "classic" snap, you cannot stop Skype from accessing all these resources (network, camera, etc.), at least not in an easy way.

How is it possible to confine such an application?

You can, if you so desire, try to create a strictly confined snap yourself. I assume that this will be a difficult-if-not-impossible task, else Microsoft had done that. Or maybe it's super easy, barely an inconvenience, and Microsoft just didn't care.

You could also create a limited user and configure your system to run the application as this user, then restrict that limited user from accessing resources such as the network, the web cam, etc.


How to safely renew user and CA certificates in a PKI

The "right" way to think about renewals is to ask yourself why you want to renew.

As I understand it, you have a root CA which is hardcoded in some application installed in the clients. Moreover, the clients themselves own certificates, presumably issued (directly, or indirectly through an intermediate CA) by that root CA. This hints at some mutual authentication setup, e.g. some SSL with certificates on both the client and the server. The important point to remember is that when you own a certificate (i.e. you know the corresponding private key), then you don't have to validate that certificate; your certificate is for the benefit of other people, not you. In particular, clients don't need to trust or even know the root CA in order to use their own certificates; they need to trust the root CA to verify a certificate sent to them (e.g. a certificate presented by a SSL server to which the clients connect).

Therefore, the notions of "root CA update" and "client certificate update" are really unrelated to each other. It will be simpler to think about both kinds of renewals in a separate way.

For root CA update, we have the following setup: an application has been deployed, and contains the root CA name and public key, hardcoded in the application. This is called, in X.509 terminology, a trust anchor. The application uses that TA to validate incoming certificates (e.g. SSL server certificates).

For some reason, you want to change the TA name or key or both. The normal mechanism for that is an update of the application. It would be inordinately naive to believe that a given deployed application is free of bugs, and if it is involved in security-related actions, then bugs can turn into vulnerabilities. So you must have some update mechanism which allows the safe replacement of the application binary with a newer version. Some software distribution platforms (e.g. Google Play for Android, or the packages for a Linux distribution) provide such a mechanism.

By definition, the application binary is trusted (since it is that code that manipulates the sensitive data) so the update mechanism must be protected against hostile alterations. Thus, embedding the new TA in the application and pushing it as an update is the primary (and, really, the only) method by which you can "renew the root CA".

If the outer platform does not provide for a safe update mechanism, then you must build your own. This may be as crude as sending a new cdrom to each user... But if you want to automate things, you will need either a signature or at least some authentication. For instance, the application could connect to a specific HTTPS server (which implies some validation of the server certificate) to download the update, reputed correct since it comes from the specific update server.

The reason why you need to push a new root CA is important, especially with regards to timing. There are two main cases: either you need to react fast because the root CA key was compromised, or you have time (e.g. you want to change the CA key for a longer one because the one you used becomes a bit too short with regards to cryptanalytic advances):

If you have time, then you can sign the new application binary (which includes the new root CA) with the old CA. This will allow for a smooth transition.
If you do not have time (e.g. root key compromise), then you are in deep trouble. The best you can do is handle it as a "critical vulnerability" and make a lot of fuss about it so that users manually connect to some distribution server (protected with a "mainstream SSL certificate" that you buy for a hundred bucks) to download the new application.

This is still a very bad situation and you would prefer not to encounter it. The classic way to keep your root CA key safe is to keep it offline: never plug the root CA to some network. This means that your PKI must have an online intermediate CA to issue the users' certificates. You manually (i.e. with USB flash drives) obtain CRL from the root CA as a regular procedure (e.g. on a weekly basis).

Alternatively, apart from the root CA, you may keep in an offline machine an unrelated "update package signature key" which you use when you need to build and distribute a new version. The application binary would contain a copy of the corresponding public key, which has nothing to do whatsoever with your root CA key and certificates; it is like an "extra root" used only to verify application update packages. Being kept offline at all times, that machine should be safe from remote attackers, and thus you may work on the assumption that the package signature key will not be compromised.

All other things being equal, it is best if you never renew the root CA key. As far as we know, a 2048-bit RSA key ought to be good for a substantial number of decades, and may be broken only by yet undiscovered but devastating attacks. There is no indication, currently, that such attacks will be discovered in the future or even if they exist at all; and there is no indication either that a longer CA key would fare any better (that's the problem with speculation on unknowns: it is speculative and rarely yields any useful information).

For client certificate renewals, the problem is completely different. A client certificate is not something that the client itself trusts.

Since a client certificate contains the client identity and public key, a first "renewal" method is to simply have the CA renew the certificate on its own accord, by taking the old, changing the validity dates, and signing it again. The client key and name are thus unchanged. The "renewal issue" has been reduced to the question of pushing the new certificates to whoever needs to know it. Usually (but not necessarily), it is best if the client itself knows its own certificate, because it allows the client to send that certificate as part of some network protocols (e.g. in SSL/TLS, when the client uses a certificate for authentication, the server learns that certificate by virtue of the client sending it).

Certificates contain only public data and are signed, meaning that they can travel safely on the Internet. You just need to setup some regular, plain HTTP request by which a client may ask some server whether a new certificate exists, and obtain it. For that mechanism, the client may contain a copy of the issuing CA public key, or some higher CA, in order to check that the certificate is the right one -- the client does not trust the root CA, but you want to avoid wanton disruption by ill-intentioned attackers who corrupt renewed certificates while in transit: this would be a DoS attack. An altered client certificate will not be accepted by any server, but it is best if the client application notices the foul play upon certificate download rather than later, upon certificate usage.

The reason why you want to renew the client certificate is, again, important:

The official reason for enforcing end-of-validity dates in X.509 certificates is to make sure that revocation lists (CRL) don't grow indefinitely. The less official reason is that one-year certificates ensure yearly renewals, that can be turned into yearly access fees. If you renew client certificates for these reasons, then you can renew on the CA side as explained above.
If you need to change the client key, then you are reacting on some abnormal and exceptional situation, e.g. a client key compromise. In that case, the client has just lost its main method to demonstrates its identity to any server, in particular your CA.

At that point, you have to consider how you issued the certificate in the first place. A certificate binds an identity to a public key, so you had, at that time, a way to verify the purported client identity. The generic recovery method after a private key compromise is thus using the same initial authentication method again. At that point, the user is normally actively collaborating -- after all, the compromise is normally discovered by the user himself.

Details on the possible emergency recovery methods vary a lot, depending on your context. When the notion of identity that your PKI uses is "same user" (anybody can register and there is no formal physical identity, but a user should be able to demonstrate that he is the same user as previously), a practical method is to issue, along with the initial certificate, a "recovery code" that the user writes down on a piece of paper, and types again when he has lost exclusive control of his private key: either the private key is known to some attacker, or the user's phone broke down and he cannot use the key anymore, or both (typical case: the user's phone or laptop has been stolen). The recovery code is the method by which the user can demonstrate to the CA that he is the same user as the one who previously owned the certificate that is to be renewed.


Stored in .html (Ensure nothing can be injected by the DB or exploitable server-side scripts, such as PHP).

For this I would break everything down into modular components and work from there:

Harden your web server. An Apache Web Server Hardening Guide to get you started.
Restrict your web server directory (usually /var/www/):

# chown www-data:www-data /var/www/ -R
# chmod 555 /var/www/ -R

Most suggest using # chmod 750, and I agree, but do not give write permissions when not necessary.

Hardening your PHP client

OWASP PHP Configuration Cheat Sheet
While not comprehensive, it's a place to start.
PHP configuration hardening boils down to the same idea "If you do not need access (execute, read and/or write), do not give access"

Ensure PHP files cannot be loaded directly. E.g. the browser client cannot request example.com/login.php, but rather must go through example.com/login.html which performs an action.

One method is instructing the web server to not serve file(s) with the *.php extension.
Alternatively, it is possible to instruct PHP scripts to handle not allowing direct access. 5 Methods to Prevent Direct Access to a PHP File

Mitigating PHP inciting an SQL injection attack.

How can I prevent SQL injection in PHP?
PHP htmlspecialchars() Function

The htmlspecialchars() function converts some predefined characters to HTML entities. E.g. converts predefined escape characters before being parsed to SQL (sanitation).

Use an appropriate secure password hashing algorithm with respect to your hardware and database (hash rate per second) with a salt. Personally, for my usage, I am fond of Argon2id.

  File to only include HTML/CSS and some vanilla JS. With the exception of JS include from the payment provider. (No abundance of JS libraries that can't be easily checked for flaws also no dependency includes that could include malicious code).

Not much can be added to this, it is a good model, avoiding libraries ensures you vet the code, as you wrote everything. Although, take that with a grain of salt, Why is writing your own encryption discouraged?. I would suggest when a requirement can be achieved in either CSS or JavaScript, e.g. opt for a CSS slideshow of images or CSS hover selector, instead of using JavaScript where possible.

  Load iFrame on this page (the information is not getting posted to our site)

I cannot foresee this being a problem as you will be using HTTPS and will be using a domain owned by you. However, it would be amiss to not suggest it. Why are iframes considered dangerous and a security risk? and 3 Reasons You Should Never Use Iframes

I like the idea of loading more information on the client-side. With ProtonMail it not only increases security for the client but also reduces server resources.

  Retrieve payment amount from GET request in JS.

Why not use a POST request?

  POST is more secure than GET for a couple of reasons.

  GET parameters are passed via URL. This means that parameters are
  stored in server logs, and browser history. When using GET, it makes
  it very easy to alter the data being submitted the the server as well,
  as it is right there in the address bar to play with.

  The problem when comparing security between the two is that POST may
  deter the casual user, but will do nothing to stop someone with
  malicious intent. It is very easy to fake POST requests, and shouldn't
  be trusted outright.

  The biggest security issue with GET is not malicious intent of the
  end-user, but by a third party sending a link to the end-user. I
  cannot email you a link that will force a POST request, but I most
  certainly can send you a link with a malicious GET request. I.E: http://www.example.com/changepassword.php?newpass=Welcome123

GET vs POST which is more secure?

  Post token (received from iFrame in JS) back to the functional website.

Why? HTML supports iFrame.

  Host on separate AWS S3.

Anything Concerning AWS S3 I may make mistakes, as I am still new to this system. Merely a disclaimer!

So long as AWS S3 matches your OpSec, then this is fine. Just ensure your remote access to the server is hardened with strong passwords and 2FA where possible.

  Ensure AWS account is protected with MFA.

As discussed above, using two-factor authentication (2FA) is advisable. Although, if MFA is available enable it.

I have seen SSH botnets have an OpenSSH server with the following parameters below simultaneously enabled:

Password authentication
Public key authentication

Risk of compromise: stealing the corresponding private key.

Google Authenticator

Risk of compromise: stealing the device authenticator is stored on.

Unless it impedes usability, the stronger authentication the better.

  Place Cloudfront with custom SSL certificate to ensure the page is protected.

By custom SSL certificate I presume you are referring to issuing your own root CA with will sign the server certificate. If so, Jamie Linux has a very good article OpenSSL Certificate Authority, for configuring a public key infrastructure (PKI).

Amazon CloudFront seems like a good option for your requirements.

For deploying HTTPS on your web server consider the following parameters:

TLS 1.2 (or better)
HSTS
HSTS Preloading
RSA 2048 (or better)

Preferably if you can afford the performance impact use RSA 4096

AES-128 GCM (or better)

Again, preferably if you can afford the performance impact use AES-256

Allow (or enforce exclusively) forward secrecy (PFS)

Review your website using SSL Labs - Server Test

This is not a comprehensive review of attack vectors to produce a threat model. However, I hope it can serve to give a broader perspective. For further reading consider How do I deal with a compromised server?.


Why exactly is this MySQL query vulnerable to SQL injections?

Generally, SQL Injections happens when an unsanitized variable is used within a query, regardless of whether there is an apostrophe or not.

In PHP you want to use prepared statements. This will transform your query into:

$sql = "UPDATE `users` SET
        `user_age` = ?,
        `user_sex` = ?,
        `user_description` = ?,
        `user_sound` = ?,
        `country` = ?,
        `region` = ?,
        `custom1` = ?,
        `custom2` = ?
    WHERE `user_name` = ?";

// Prepare the statement
$statement = $mysqli->prepare($sql);

// Bind your variables to the question marks in the SQL.
// bind_param keeps variables bound, so if you prepare a statement, bind the params
// then change the value of the variable bound, then the new value will be used.
// The first parameter determines what type of value, 's' is a string, 'i' is a interger
$statement->bind_param("sssisssss", $my_age, $my_gender, $my_description, $my_sound, $my_country, $my_region, $mycust1, $mycust2, $me);

$statement->execute();

Note that you don't need apostrophies when using prepared statements, the s type definition in bind_param will add them for you when escaping the value.


So perhaps I could do all of this in memory without writing to /tmp? But there is still a risk here that the attacker could discover memory addresses that the data is written to by uploading a file themselves and then use ptrace to inspect and copy those memory addresses.

A properly installed SELinux configuration can mitigate the risks of a compromised machine by control of the application. Ultimately, you have to keep the machine secure.

  I can't think of a way to fix this problem as I will need the data in plaintext in order to do the encryption. Is there a way in PHP to make the memory inspection harder? Or is there a third party web service that would be better to use for this?

There's simply no way around the reality of having to have the incoming file in a cleartext state in memory at some point in the encryption process. Encrypting it in memory, however, is certainly the way to go.


What is "JTI/Suspect.131328" from McAfee?

McAfee's Rule Identifier 131328 is described in KB82925 on How to identify what rule corresponds to an Adaptive Threat Protection and Threat Intelligence Exchange event:

  Detect use of long -encodedcommand powershell

  Alerts on variations of the encodedcommand [base64] powershell usage

  WMI provides a way of executing code or moving laterally in an
  environment. Some legitimate software may use this way, so this rule
  should be behavior in your environment

It may or may not be harmful. That's why it's suspicious. Further investigation would require catching and decoding the base64 encoded PowerShell command and analyzing whether it's legitimate use or not.


How secure and private is the case where you use hushed app with a VPN on Android?

In order:

  If from the non sim card phone i turn on the vpn, then use a hushed number(burner number) and connect to my other phone which has a sim card and uses cellular network over a mobile hotspot wireless connection on the other phone , is the first phone protected and secure and private so that nobody can access the information i send over it?

Short answer: Sort of, yes. Let me elaborate and clarify. First, a primer on VPNs:

VPN tunnels are between two endpoints. If your VPN is on your burner phone, the other endpoint is usually the provider or VPS. (e.g. VyprVPN, ProtonMail, etc). This creates a tunnel of encrypted traffic between these two, meaning your ISP (and anyone else in the middle, like someone  on Wifi) cannot see your traffic. However, this does nothing to protect your other, non-burner phone. The only thing encrypted is packets sent and received on your non-burner phone.

However, if you set up and create a hotspot on non-burner phone, and use this hotspot on your burner phone, then connect VPN on burner phone, your burner phone will still remain anonymous (see bottom for note on this) and encrypted - but traffic orginating from your non-burner phone is not. Meaning anything sent/received from your non-burner phone is still visible, while your burner phone is (relatively) safe.

  Or does the data sent through the wireless hotspot connection become visible through the phone which is offering the wireless hotspot connection?

Short version: Your burner phone will remain anonymous, but your non-burner phone will not. As long as the data is only going through the hotspot with a VPN connected, you should be safe. If you want anonymous info on your non-burner phone, set up a VPN on that one, too.

Note on anonymity - VPN's alone are not enough to ensure true anonymity. Things like DNS leaks can compromise your IP, so if you want true anonymity, you will need a layered approach. Perfect anonymity is nearly impossible, however, and requires going through lengths most people will find annoying or even eccentric. I am not addressing those, I'm simply discussing the VPN traffic as you presented the question. VPN's are a huge step in protection, and will make it considerably more difficult to track you, especially for usta  casual user - difficult, but not impossible. I thought it important to clarify this distintion.


Can my mouse have virus and infect other machines?

USB devices as a rule, in principle, can carry viruses. But that doesn't mean that all USB devices are capable of carrying viruses, it just means that if you don't know where the device came from, then it you shouldn't plug it into your computer even if it doesn't look like a device that could transmit a virus.

That said, most mice (presumably including this one) don't contain any writable memory. So the mouse can't be modified by an infected computer. So if the mouse wasn't dangerous to begin with, then plugging it into a dangerous computer generally can't make it a dangerous mouse.

Interestingly, this particular mouse is unusual in that it does actually have some amount of memory in the form of programmable macros, actually stored on-device. This makes the device slightly more suspect -- a malicious piece of software could theoretically overwrite your macros. How that might translate into subversive behavior is anyone's guess, but for run-of-the-mill malware infections, transmission by way of this particular macro function is quite unlikely, if for no other reason than because this mouse is not very common.

There's some chatter about the possibility of overwriting the mouse's firmware so as to persist an attack. Flashing firmware was the basis for the Bad USB attack class. But this requires that the firmware be user-flashable. For most mice there's nothing to worry about. Adding a firmware modification feature to the USB connection is expensive and uncommon. But if you expect to see such a feature anywhere, it would be on overly complicated and expensive peripherals targeted at gamers.

The anatomy of such an attack would be, almost certainly, to emulate a keyboard and inject a script of keystrokes when you're not looking -- see the USB Rubber Ducky for how this works.


Secure browsing on any device without limiting the browser

You are ok with the endpoints getting infected, but you don't want the infections to spread. This has been done before in a variety of ways.

Network segmentation:

personal devices (uncontrolled devices) do not get access to anything within the network except for the internet
if personal devices need access to company resources, they do so from a public portal
all internal, controlled devices that can browse the internet can only access certain resources within the network
have reinforced network infection detection and rapid response procedures to isolate affected endpoints

I work with a lot of universities and we do this because we do not have control over what everyone does/can do on the network.

Application segmentation:

No internet browsing is allowed in any form from any device (blocking ports/protocols on the perimeter)
Browsing can only be done through remote desktops/virtual application servers, which are themselves segmented off from the network
The remote/virtual environments are rebuilt as soon as the person exits

I have done this at a financial services company. This makes it possible to allow for BYOD, because the user just logs into the remote server if they want to browse. It's an annoying extra step, but far more secure. Virtual application servers can make this far more user-friendly (the desktop icon is a link to a remote virtual sandbox), but only if you have control over the endpoint (not so easy on BYOD).

VMs, sandboxing:

Sandboxing and VMs require that you can enforce those things even on personal devices, which is not going to be easy, and it is easy to have gaps in protection unless you also end up doing one of the above.


Automatically insertion of 00 in EIP in Stack Overflow 64bit

The null byte is almost certainly from the end of your a filled string. if you're not trying for a partial overwrite the more common approach would be to send more characters and overwrite all of EIP with 0x61616161.... You can then alter the overwrite bytes to any value you want, including 0x555555555561.


This is still incredibly confusing. I'm running Chrome 40 and like you I've just spent far longer than I would have liked figuring out what's going on.

The CSP 2 spec says this about hashing <script> elements:

  For example, the SHA-256 digest of alert('Hello, world.'); is YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo=.

I've managed to generate that hash by running:

$ echo -n "alert('Hello, world.');" | openssl dgst -sha256 | base64
YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo=

But this does not work in Chrome 40.

The editor's draft of CSP says this:

  For example, the SHA-256 digest of alert('Hello, world.'); is qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=.

The example they give is generated with:

$ echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | base64
qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=

The addition of the -binary flag to openssl is the difference between the two commands.

This does work in Chrome 40 (stable) and Chrome Canary, but I believe it still has issues in Firefox 36.


How does ViewState protect against CSRF?

If you enable the ViewStateUserKey, then the server will protect the integrity of the view state by appending a random, unguessable checksum.  This checksum acts much like a random CSRF token.

In particular, ViewStateUserKey will compute a Message Authentication Code (MAC) on the view state fields.  A MAC is like a keyed checksum of the data, where the key is known only to the server.  Because the attacker does not know the key, the attacker cannot generate a valid checksum (MAC digest) for some other value of view state parameters.

If you use a ViewStateUserKey, then the key used is specific to the particular user.  This means that a malicious attacker Mandy cannot learn a valid value of the MAC digest for user Bob.  Mandy cannot guess it, because a MAC algorithm is designed to prevent guessing the MAC digest.  Mandy cannot learn it by contacting to the server, because if she connects to the server, the server will use her cryptographic key, not Bob's key, so the MAC digest that is sent to Mandy will be unrelated to the one used for Bob.

In effect, the MAC digest acts like a random 128-bit string that the attacker cannot guess.  This is what prevents CSRF.  Standard CSRF defenses involve including a random string in the request parameters (random, so that the attacker cannot predict it).  With a ViewStateUserKey, the MAC digest acts as that random string.

See also Microsoft on Securing View State
and Does ASP.NET Viewstate implicitly prevent CSRF attacks? What does this mean for MVC?.


Why handshake is not initiated for google webserver?? Is there any client side validation before handshake is initiated?

There could be a few reasons for this, but the most likely are HSTS, SPDY, and preloaded pinning:

HTTP Strict Transport Security (HSTS) is a mechanism by which a server can enforce that the server is only ever connected to via a secure connection (e.g. HTTPS) and that a valid certificate must be presented. Your browser will not allow the connection to initiate on an insecure protocol like plaintext HTTP, or if the presented certificate is not valid. You can't override this. If you're doing TLS MitM in Burp, your browser will reject the certificate as invalid unless you install the Burp CA in your browser.
SPDY is an alternative HTTPS protocol that Google uses a lot. It may well be that your browser is trying to initiate a SPDY connection, and that's perhaps why Burp isn't catching it.
Chrome comes preloaded with a set of server certificate rules for pinning. The idea is essentially that they preload HSTS rules for a bunch of common sites as part of the installer, but with the additional protection of including a fingerprint of the known certificate. This will cause any invalid certificates, even those with "valid" signatures (e.g. signed by a local CA), to be rejected.

My advice would be to install the Burp CA into your system's certificate store, and your browser if applicable. That should probably fix it.


Only allow the front-end to ask if it should show the 2FA UI after the password has already been authenticated.

This doesn't even have to be a separate API, it could be part of the existing login API. The login API could take a username and password, and return something like:

Invalid for invalid username or password, or nonexistent account
2FA required for second factor required
Success for successful login (no second factor required)


SQLMap Cookie Injectioin with Working Manual SQLi

First of MariaDB is supported through MySQL engine in SQLmap so the parameter you have there --dbms "MariaDB" is wrong. There are different reasons that each of your three commands are not working.

First one does not include an injection point.
Second the suffix you use is wrong as it misses the double quote that closes the escaped quote from the prefix.
The cookie format is wrong and the suffix is wrong as well.

The reason why it was suggested to use the -r flag is because it reads the request directly from a file and therefore there are less chances to make the mistakes you did.
Eventually you can make this work with a prefix/suffix or with an injection point or with the request from a file or even with a tamper script. Easiest thing would be the injection point so here is a command that should be working.
sqlmap --url='http://sandbox.local/' --cookie="wp_sap=[\"1650149780')) OR 1=2 *#\"]" --dbms=mysql --union-cols=10-12 --technique U

The * notes the position for the payload, the double quotes are escaped \" and I specified the --union-cols to be of that value as you show that the manual payload that worked has more than 10 columns and by default sqlmap reaches up to 10 without increasing the level.
Also in case the injection does not work with NULL values you might want to test it with --union-char=1 parameter!


Can PFS be used to prove that a file was transmitted/received at a particular date & time?

PFS could be used to guarantee that a given set of packets (e.g. containing a file) belonged to a given session, by using the following "protocol":

Client C (handling the requests of user U1) and Server S establish a TLS session with a key k_i. The entire session is captured and stored using tamper-resistant mechanisms.
C downloads a file from S.
Upon request of a third party with access to the packet capture (e.g. a court), C or S discloses k_i. The third party accesses the content of the packet capture and uses k_i to decrypt it, thus showing whether or not that set of packets belonged to that session.

Note, however, that this mechanism cannot prove that U1 didn't receive the file before that session, as:

1) the same plaintext encrypted with different keys can - and normally does - yield different ciphertexts. Without knowing the keys of all previous sessions with that server (since the very first one, which could have been years before), this problem is unavoidable; and

2) U1 could have obtained the same file previously and "out of band" in many different ways, for example by another server, by having U2 download the file using his account and copying the file locally (or for that matter, stealing U2's credentials), and so on.


The SHA-3 hash competition was an open process by which the NIST defined a new standard hash function (standard for US federal usages, but things are such that this will probably become a worldwide de facto standard). The process was initiated in 2007. At that time, a number of weaknesses and attacks had been found on the predecessors of the SHA-2 functions (SHA-256, SHA-512...), namely MD5 and SHA-1, so it was feared that SHA-256 would soon be "broken" or at least weakened. Since choosing and specifying a cryptographic primitive takes time, NIST began the SHA-3 process, with the unspoken but clearly understood intention of finding a replacement for SHA-2.

SHA-2 turned out to be more robust than expected. We do not really know why; there are some half-baked arguments (the message expansion is non-linear, the function accumulates twice as many elementary operations than SHA-1...) but there is also a suspicion that SHA-256 remained unharmed because all the researchers were busy working on the SHA-3 candidates. Anyway, with SHA-2 doom being apparently postponed indefinitely, NIST shifted its objectives, and instead of choosing a replacement, they defined a backup plan: a function which can be kept in a glass cabinet, to be used in case of emergency. Correspondingly, performance lost most of its relevance.

This highlights the choice of Keccak: among the competition finalists, it was the function which was most different from both SHA-2 and the AES; so it reduced the risk that all standard cryptographic algorithms be broken simultaneously, and NIST metaphorically be caught with their kilt down.

Let's not be hasty: not only is SHA-2 still fine (both officially and scientifically), but SHA-3 is just announced: it will take a few more months before we can get a specification (although we can prepare implementations based on what was submitted for the competition). What must be done now (and should have been done a decade ago, really) is to prepare protocols and applications for algorithm agility, i.e. the ability to switch functions if the need arises (in the same way that SSL/TLS has "cipher suites").


Is it safe to publicly expose key hashes?

As long as the keys contain as many or more bits of entropy than the number of output bits of the hash (ie keys are random and long enough), making the hashes public wouldn't result in any notable loss of security. To reverse a hash of sufficiently random data would require a preimage attack, and preimage resistance is one of the basic properties of a cryptographic hash function (even MD5 is still preimage resistant). Just make sure the keys are being generated with a CSPRNG.


Virus won't be picked up by Antivirus tools

Symantec's virus submission portal:
http://www.symantec.com/security_response/submitsamples.jsp?inid=us_sr_flyout_contact_submit

I have seen this kind of infection before over the years in various forms.

Was the 'driving itself' computer the same as the infected one, or a different computer? If it is different, you will have to nuke all machines and start from scratch, I'm afraid. You have a RAT.


How can I keep my identity anonymous as a website owner/administrator?

Buy gift cards in cash.

Bonus points for extra cloak & dagger shenanigans like buying cards in distant cities.
More bonus points for paying in advance to use up the card's value so you don't keep it.

Use a Live CD for all website activity. Don't mount any permanent storage devices.
Via anonymous proxy services (probably TOR) to establish a VPS or other hosting system.

Bonus points for buying it in a country that probably won't hand over info to your hostile country.

Register your domain via anonymous proxy.
Only access your system via the proxy.

That leaves no trace on your computer and no financial ties unless the card is found. If TOR traffic is suspicious to authorities, you might be able to use Amazon EC2 instances that are terminated after each session.


Is it secure to auth API requests using an RSA?

It is possible to create a secure system this way using RSA, but you're looking for a world of pain and it's likely you'll end up creating an insecure system.

RSA is a very low level cryptographic primitive, it's way too low level for an application developer to work with and using it exposes you to a lot of vulnerabilities if not used correctly. Leave writing cryptographic code to the experts and use higher level cryptography, either TLS or OpenPGP should be the level that you're looking at, not RSA.

  I know that there are a performance issue with RSA, but it is for very short messages, so it is not concerning me.

The issue with RSA isn't just performance. RSA cannot be used to encrypt data larger than the key size minus any paddings, which means that a 2048-bit RSA key has a maximum input size of 256 bytes (or 245 bytes if you use v1.5 padding). This means that if you want to encrypt data larger than this size, you need to implement a chaining mode, and chaining mode is one of the most easy things to get wrong when implementing cryptography. Additionally nobody had ever implemented or does any cryptoanalysis on RSA chaining mode (most chaining mode are analysed for symmetric ciphers), so you are on your own there.

Another problem is that all cryptographic primitives eventually need to be replaced as computers get stronger and vulnerabilities are find in these primitives. Therefore, all practical cryptography applications need to add metadata that allow negotiation and replacement of the encryption primitives and its parameters. TLS, S/MIME, OpenPGP, and the crypt password hash format all have this capability built into the protocol. This is also another aspect that's easy to get wrong.

Another issue that plain RSA doesn't do is replay prevention. For this, you need to add a salt or IV, and possibly a challenge. And the order you layer signing and encryption also comes with their own pitfalls.

I could go all days explaining the various pitfalls if you're trying to use plain RSA to implement any cryptography system.

High level protocols like OpenPGP and TLS uses RSA as the underlying primitive but when you use a high level cryptographic protocols, those issues have been thought out for you by expert cryptographers and their implementations have been highly scrutinized as well. All the remaining issues are either resolved or it's fairly easy to configure the system when there's a trade off.

OpenPGP in particular have a signing mode, which effectively does what you mentioned, using private key to sign a data to prove authorship, though in more sophisticated ways. An OpenPGP signature is created by encrypting a hash of the message rather than the message itself, thus avoiding the need to do chaining and it adds a number of metadata to protect against various attacks. TLS have similar properties during handshake if you use Mutual Authentication but they are implicit in the connection, so it may not be suitable if you want to store and/or forward the proof of authorship to another entity.

TL;DR Don't roll your own cryptography. If you need to persist the proof of authorship, use OpenPGP signature; otherwise just wrap the communication in TLS using Mutual Authentication.

  Why others not doing it? There is any security issue with it?

Because it's stupidly complicated to get it right, when you can just use TLS mutual authentication with just a few lines of code. Unless your scheme is going to be as massively scrutinized as TLS and OpenPGP, I can assure you your scheme will have weaknesses you would have practically no chance to discover.


Why is this website verified by Symantec if it's known for scam & theft?

Symantec is verifying only that the website is who they say they are.  They make no judgements based on whether or not the owners of the website are running a legitimate service or not.

CAs are not supposed to sign a certificate if that certificate could be misinterpreted as a different site:  https://www.citibank.com would be verified by the actual Citibank company; but https://www.citibamk.com should not be issued to anyone else because it's probably a thief using typosquatting in order to dupe people.  (Note that Citibank could in good faith register citibamk.com in order to redirect people to their real site; some sites will buy up typosquatting domain names in order to prevent these attacks.

So, if the site you visited was named https://www.ARealLegitStoreAndNotAScammer.com and you got scammed by them anyway, it's not Symantec's fault.  However, if you got duped by https://www.walmert.com into thinking you were at the very large retailer's web site, then they should never have signed the certificate, and it's their fault.


Can I get a public key from PGP signature?

Yes. The format of the signature is defined in RFC 4880. If you decode the base-64 and interpret the data, you will find that the bytes from position 19 to 26 (inclusive) are the issuer ID in this case:

ID hex: E48184B5B05676B1

which matches the "Long key ID" behind your link. If you convert the ID to base 64, you can find it in the original signature data, because 18 bytes happen to divide evenly into 24 base 64 characters:

ID b64: 5IGEtbBWdrE=
Signature: iEYEARECAAYFAlHZCvgACgkQ5IGEtbBWdrF5HgCfc4xhT29ouAWdo1PMlyDKIfaq...


Secure way to update Date & Time of a Linux Embedded Device

I can think of two reasonable ways to address this:

Run a VPN, set your NTP client to sync to a server on the other side of the VPN
Look at OpenBSD's implementation of ntpd, from the man page (https://man.openbsd.org/ntpd.conf) :

  CONSTRAINTS

  ntpd(8) can be configured to query the ‘Date’ from trusted HTTPS
  servers via TLS. This time information is not used for precision but
  acts as an authenticated constraint, thereby reducing the impact of
  unauthenticated NTP man-in-the-middle attacks. Received NTP packets
  with time information falling outside of a range near the constraint
  will be discarded and such NTP servers will be marked as invalid.

  constraint from url

  Specify the URL, IP address or the hostname of an HTTPS server to
  provide a constraint. If constraint from is used more than once,
  ntpd(8) will calculate a median constraint from all the servers
  specified.

The description in the man page seems to be exactly what you are asking.

There is a Linux version of OpenBSD ntpd in the form of portable OpenNTPD maintained by Brent Cook : http://www.openntpd.org/portable.html


At the moment, no.

Icons are data, not code. There is no mechanism to execute malicious code paths due to the contents of an icon, because icons don't get executed, they just get displayed.

That could change. But it would take a vulnerability to make it so. In that event, the "malicious icon" would be tuned to take advantage of the vulnerability in the software that displayed it.

At the moment, there aren't any of those vulnerabilities that we know of, so the term "malicious favicon" doesn't make sense, as there isn't a way to make one malicious.

That doesn't mean that there never will be, but right now there isn't.


How effective are anti-virus products against real-world threats?

Do we have any scientific measure of the real-world effectiveness of off-the-shelf anti-virus products in detecting and stopping today's active threats?

No. New viruses are created everyday, some may spread far enough to get caught by Anti-virus vendors, others might not, slight variations in viruses can cause them to be missed and many people in underground markets offer 'FUD' Crypters/Packers in order to evade AV solutions. With so many people writing malicious code and the code being re-used/modified to suit its more than possible what we see and defend against is only the tip of the iceberg.

  Put differently, what is the actual real value of running an anti-virus product when facing today's common security threats?

The vale? It provides another Layer of security. Like all security technologies, no one single defense creates a 'bulletproof' defense against all malicious attacks. I've heard wildly varying estimates as to the size of AV signature database but the point is, that it'll catch low hanging fruits (it'd be embarassing to be pwnt by ILOVEYOU now wouldn't it?)
In addition, the herustics engines might work for you from time to time and find new malware that doesn't have signatures.

Its all about defense in depth!


Is a honeypot an effective deterrent to hackers successfully compromising your network?

Deploying a honeypot is not unlike adding a painted door or a fake safe to a bank vault.

It does not deter anybody (its purpose is not to be detected as a honeypot). Possibly someone misspelled detect.

It can reduce (somewhat) the time spent by attackers against the real door. Not by much.

More than that, it can be optimized for data gathering (simplistically, you know nobody is going to ever use the services on the honeypot, so you can tune them all to "log everything high volume paranoid dump dump dump". Service efficiency goes to hell, but as soon as someone attempts anything you need guess nothing. The "safe" is all alarms, and no bullion.

Even more, you can correlate what is happening on the honeypot with what is going on in the rest of the network. The honeypot will tell you what's behind what the other machines report as unusual but random "noise".

Finally, the honeypot can apparently allow an attack to succeed, so that you can gather yet more data. Example: the attacker wins a root shell on the honeypot. He proceeds to download more sophisticated tools. Now you have, at the very least, a copy of those tools as well as an idea of where he downloaded them from.

(If you have time you can crash the connection in a not-too-suspicious way and let him reconnect later after having added suitable instrumentation to his tools, that are now his no longer).

You can determine whether he's just a script kid looking for some warez bouncing, or someone who actively targeted your network. Even by avoiding the honeypot he will tell you something that's worth knowing.

But pretty much nothing of the above comes for free; nor will it work by itself. You need someone continuously managing (normally at a very low level, but continuously and always ready to escalate) the honeypot. The honeypot has to be maintained and updated, just as much (possibly much more) than the other boxes.

You have to decide whether the gain is worth the pain, and whether you can invest in the necessary pain.

Just "adding a honeypot" will do nothing to increase the network security; to the contrary, it will engender a bit of false security, and possibly provide a security breach if the honeypot isn't as well insulated and armored-in as you believed; it might also attract more attention than if it weren't there, if it offers services or vulnerabilities the other machines don't share.


Using certificate on same server but different port for https

I figured out the issue.  The problem was not with the CA key, it was with the private key.  Once i remade the private key using this:

keytool -genkey -alias gis.akrf.com -keyalg RSA -keystore "C:\Program Files\Apache Software Foundation\Tomcat 9.0\conf\Keystore\keystore" -ext SAN=dns:(your dns here, like some.domain.com or localhost, which should also match your keyalias in tomcat's server.xml )

so it has an SAN and followed the directions here, it worked.


Log information for SIEM auditing in Linux

Auditing is broad term and could mean auditing that the SIEM is working as expected or generating reports providing detailed usage statistics. (It could mean many other things beyond these as well)

The SIEM will only be as good as the data source, so that is the first thing you should check. Ensure you have a number of defined use cases, for example low level use cases may be normal user accounts attempting to use SUDO or add jobs to cron.

One you have a collection of use cases you need to ensure they are being logged. Linux does not log all actions by default, even if it does log them by default you need to ensure that the connector to the SIEM is receiving the raw logs. Depending on the Linux system and the methodology used this will differ, but the most common setup I have seen recently usually involves using rsyslog and auditd.

Once you have the raw data being collected by the SIEM connectors you then need to ensure that the raw logs are being parsed and normalised correctly, this is something I have seen configured incorrectly before and it can cause problems down the line. Standard syslog connectors may form a basis for the normalisation process, but depending on which logs are being collected and what format they are in this probably will require a level of tweaking.

Once this is done you need ensure that the events are being generated on the SIEM by the logs, if all is OK then you should see a stream of filterable events on your SIEM solution. This doesn’t necessary mean that any of the events are going to match your use cases.
The next thing you need to do is create rules for each of the uses cases; for example you may want a rule to fire every time a normal user uses SUDO.

The next stage is testing. Testing can be tricky, because you need to be able to do something that is going to trigger the rule and in most production servers that will either involve a lot of paperwork or it will not be possible at all. This means you will need to use either a test system or replay file that will flood your system with events, you can configure either to purposely carry out activity to that will trigger a rule and an action. This action could be anything from correlation with other events, sending alerts or key to this question feed directly into a report or query for auditing.

Additionally you can write scripts that will attempt to carry out the use cases and generate log entries, this will test the entire process from the raw logs through to the SIEM rules. (Good luck getting scripts like this onto a production server though)

Once you have thoroughly tested that each of the use cases are triggering the rules/actions you require, you can start tuning out any events that are not a security issue, for example some normal users may have legitimate access to the SUDO command and you do not need the rule to fire every time  they use SUDO.

One of the good things about SIEM is that in general they are very easy to audit as reporting is built in. You can configure a series of reports for each of your use cases. These can count how many times a rule fired, what times they fired, what actions were taken etc. You can dig down deeper and audit all events regardless if they fired a rule or not. Really you are only limited by your imagination or computing resources, although you should only really use the SIEM to report on security events.

These reports can be configured to provide detailed statistical analysis or general aggregated data. Once again you need to decide what you want to see, for example do you need to prove you are compliant with certain regulations? If yes; Break the regulation down into discreet provable objectives and then generate a report based on each of them, this process will be different for each environment and each regulation you need to be compliant with.

The SIEM will take time to mature, it is just the nature of the beast and things should improve over time, with continued tweaking, testing and reporting.

One thing to be very careful of though is not to out scope yourself, you may create a set of rules so tight that you end up with blind spots and miss malicious and/or anomalous activity in the environment, this is something that reporting will not help you with.

TL:DR

Ensure your data source is configured correctly, i.e. the correct logs
are being forwarded to the correct place.
Ensure the SIEM is seeing the data correctly.
Test and tune all your rules.
Configure reporting within the SIEM based on your unique auditing
needs, i.e each set of regulations/audit demands/environment/SIEM
will require bespoke configuration for the reporting and auditing
phase.
In addition to this, time will be required for the baselines of the
expected events and maturity of this SIEM to be established.

Finding information sources on the detail of how to do this can be tricky. Most enterprise class SIEM solutions are propriety products and the literature is quite heavily protected, if you are a customer go to your vendor directly and ask for support. There are a few resources dotted about online, but in general I find the information to be of low quality and in many cases out of date.

SANS have a paper called Successful SIEM and Log Management Strategies for
Audit and Compliance that you can get in PDF format here.


The information you asked for is given here on their official site. I am copy/pasting a small relevant excerpt below.

  BitTorrent Sync was designed with privacy and security in mind. The
  system uses SRP for mutual authentication and for generating session
  keys that ensure Perfect Forward Secrecy. All traffic between devices
  is encrypted with AES-128 in counter mode, using a unique session key.
  Modification requests are all verified using Ed25519 signatures and
  only systems with full access keys can generate valid modification
  requests.


What security implications are there for allowing outbound SSH traffic?

I think they also want to keep the port closed because it could be used for proxy connections, TOR, and the like.

Yes, that's the most likely explanation.

It is possible that malware would go outbound using SSH to hide it's traffic.  It's also possible that malware, or users, could use SSH remote port forwarding to permit "inbound" connections that are blocked by the firewall.  These are valid but probably lesser concerns for your school.

Their primary issue with SSH is probably not that it allows these tunnels, which as you point out could go over other ports and other protocols, but that it hides them beneath encryption, and blocks the ability of the administrator to control what the network is used for.  While other tools can do this too, SSH is "out of the box" and represents low hanging fruit for them to block.

  Could someone please respond with either more, better reasons why outbound SSH should be blocked or (preferably) with reasons why this network policy is irrational?

Their technical reasons are valid but possibly a little specious for (a school's) level of security requirements.  The administrative reasons are valid to them, but irrational to you.  Unfortunately for you, it's their network.

Where I expect you'll be tunneling SSH-over-SSL sometime soon.


Ability to determine which PGP public keys a message has been encrypted for?

First of all, although you used pgp, I assume you will actually be using  GnuPG. Otherwise, fetch it - it's free software. Although PGP will probably also have similar functionality.

Hidden Recipients

It depends. If the sender included the recipient's key fingerprints, you can retrieve them; otherwise (if encrypted using the --hidden-recipient option) GnuPG has to test all your private decryption keys against the message.

Listing (non-Hidden) Recipients

If the recipients are included, GnuPG will list them when set to verbose mode (--verbose). To prevent GnuPG from actually decrypting the message, add --list-only. The relevant lines are the ones starting with gpg: public key is.

This will output public subkeys, which you have to resolve again using gpg --list-keys [key-id].

A complete command line to retrieve the recipients from a message:

cat message.pgp | LANG=C gpg --verbose --list-only 2>&1 | grep 'gpg: public key is'

If you even want to automatically resolve subkeys, additionally pipe through cut and xargs:

cat message.pgp | LANG=C gpg --verbose --list-only 2>&1 | grep 'gpg: public key is' | cut -d' ' -f 5 | xargs gpg --list-keys

LANG=C is used to enforce English localization, so grepping will not fail for other languages.


Is it possible to extract a certificate that an application uses to connect to an API server?

While you can extract the client and server certificates when sniffing a TLS connection (at least with TLS 1.2 and lower) you cannot extract the matching private keys. But you need these private keys to authenticate against the peer. These private keys are only at the endpoint, i.e. in the android phone in case of the client certificate you want to use.

  Also, is this called SSL pinning from server side?

No. Requesting and verifying a client certificate is called authentication with a client certificate, mutual authentication etc but not pinning.


How will social networks (like Facebook) prevent their facial recognition software being abused to render Witness Protection Programs useless?

They probably won't. After all, dispelling and selling everyone's not-so-well-kept secrets - where they live, who they know, where they shop and what for... - is the social networks' business.

Reaching this data is unlikely to require anything as dramatic as bribing high-ranking fb engineers. Face recognition data is largely used in the open, with the advertised goal of helping users find their own photos, and it will likely be sold to third parties. It doesn't even matter if the social network itself has face recognition, as the photos themselves are in the open; others can run their own software on them.

Even without face recognition, it's a challenge to maintain two isolated social network identities (including non-simultaneously). Are you going to stop liking and reposting the same pages? Similar pages, views? Do you remember every one of your online-only friends so as not to add them again? It will only take a careless move or two, maybe even by your new friends, to create a connection. Not enough to pinpoint you, just to create a search circle around your old identity, and from there it's one step to your new identity's picture being recognized.

The simple answer is, social networks are not compatible with privacy. Their explicit goal is to put your life online and that's what they do. Their privacy restrictions are paper-thin and suitable for protection against minor embarrassment, not life and death situations.

Fortunately, social network use is still not mandatory. As long as there's enough non-users that they don't stick out (we're still on that edge), the choice exists.


Can Heartbleed be used to obtain memory from other processes?

There is a well-written analysis at http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html complete with code samples.

The author, Sean Cassidy, notes that (emphasis mine):

  What if the requester didn't actually supply payload bytes, like she
  said she did? What if pl really is only one byte? Then the read from
  memcpy is going to read whatever memory was near the SSLv3 record.

  And apparently, there's a lot of stuff nearby.

  To be honest, I am a little surprised at the claims of the people who
  found the Heartbleed vulnerability. When I heard about it, I figured
  that 64KB wasn't enough to look for things like secret keys. The heap,
  on x86 at least, grows up, so I figured that pl would simply read into
  newly allocated memory, such as bp. Keys and the like would be
  allocated earlier, so you wouldn't be able to read them. Of course,
  with modern malloc implementations, this isn't always true.

  And further, you won't be able to read the memory of any other process, so those "business critical documents" would need to be in
  memory of the process, less than 64KB, and be nearby pl.

An alternative viewpoint from Erik Cabetas of Include Security, commenting on Reddit:

  Was having some discussions w/ my friend about this bug. He thinks
  it's exploitable by using a variety of specifically sized allocations
  across the heap to read the 64k chunks all around the heap fragments,
  not in a linear type of fashion that Sean in OP's link is implying.
  After thinking about the way ptmalloc/linux allocates, I think this is
  possible for sure. The .fi guys from codenomicron are sharp dudes, I
  bet they were able to get the allocations just right in a lab
  environment.

Edit: Sean has updated:

  And apparently, there's a lot of stuff nearby.

  There are two ways memory is dynamically allocated with malloc (at
  least on Linux): using sbrk and using mmap. If the memory is
  allocated with sbrk, then it uses the old heap-grows-up rules and
  limits what can be found with this, although multiple requests
  (especially simultaneously) could still find some fun stuff.

  However, if mmap is used, all bets are off. Any memory not in use
  could be allocated for mmap. This is what the most of the attacks
  against Heartbleed will target.

  And the best part: the bigger your requested block, the more likley it
  is to be served by mmap rather than sbrk.


Is the Kaminsky bug still a problem for sites without DNSSEC?

Kaminsky isn't the first person to find a DNS cache poising vulnerablity. In fact many of these vulnerability have been found and that is why DNSSEC is important. DNSSEC is a defense in-depth strategy against this attack pattern.  However responsible software vendors patch vulnerabilities,  and when you find a DNS cache poisoning attack in BIND,  it will be fixed immediately.


What's the danger of malicious JS and .DOC files in the AppData\Local\Temp folder?

Temporary directories store cached information for fast retrieval. The Temporary Internet Files directory stores cached versions of webpages, including any attached files, such as javascript. Temporary versions of document files may be downloaded if you select "open" rather than "save" upon downloading a file. In either case, depending on the nature of the malicious file, the file could execute from the temporary directory, but having doc/js files in this directory in and of itself is no cause for concern unless those files have been identified as malicious.


Computer began downloading hundreds of blobs then froze

That site is employing something called Download Bomb. It just starts thousands of downloads at once to freeze the browser, scaring people with a fake virus warning. It only freezes the browser, and don't have any lasting effects or harms the computer in any way.

It's ironic that it affects Firefox, Chrome, Opera, Brave and Vivaldi, but does not affect Edge or Internet Explorer.

What to do? Press CtrlShiftEsc (or right click on the task bar and open Task Manager) and kill the browser processes. Disconnect from the network so the site cannot load its scripts, and reopen the browser. Close the affected tab and reconnect to the network.

Google and Mozilla are aware of the problem, and a fix is on the way.


AWS Signature V4 vs OAuth + JWT bearer tokens

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

Yes, it is more secure against replay attacks. As you suggested Bearer tokens can be used with any request (not just theoretically). They are completely independent of the request they authorize. AWS signatures, on the other hand, are "bound" to the request they are attached to. The request signed also contains a timestamp that is checked by AWS to make sure it is within a certain window. The request can only be replayed in this window.

Just as you said, the signature ensures the integrity of the request. Integrity is also provided by HTTPS. The AWS scheme maintains integrity even if HTTPS is taken away.

  if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

It does give you more security properties. There are some other HTTP signature schemes that try to replicate what AWS does. Here is a draft. Joyent also created their own scheme. There is also a library called Escher, which completely replicates the AWS scheme. It is also compatible with it and includes the validation side as well.

DISCLAIMER: I work for the company who developed Escher. We use it in production to connect lots of services.


sslstrip vs. privoxy redirect rule on clients

This won't work very well.  If you try it, you'll probably find that you are unable to browse most sites, because most sites don't offer their site through SSL (https:).

The right way to defend yourself: install the HTTPS Everywhere extension for Firefox.  Any time you visit a web site that is known to support https, HTTPS Everywhere will automatically redirect your browser to use the https version.  It's great!  I use it and highly recommend it.

Important caveat: You will still be vulnerable to sslstrip / Firesheep style attacks when browsing sites that don't support https.  There's not much you can do about that, except ask those sites to support https, or avoid using unencrypted wireless networks.  (Or, buy a secure encrypted VPN service to route all your communications through: but that is inconvenient and expensive.)


For PHP, you can consider tools such as SecureAssist (by Synopsys). Its decently comprehensive and helps find security related vulnerabilities.

Other options include tools such as RIPS.

More  information can be found on the Owasp static analysis tools page:

https://www.owasp.org/index.php/Source_Code_Analysis_Tools


How to perform encryption/decryption in a RESTful system?

As others have mentioned, you already have TLS, so this won't add any security, it'll just slow things down.
You mention sharing a private key between servers. Don't do that. Ever. Generate individual key pairs for every server, and have your central server sign them (the usual certificate generation process, with your central server as the CA).
The method you've proposed is otherwise OK but slow. Why not try libsodium boxes? Then it's a matter of calling crypto_box_easy() on the sender side, and crypto_box_open_easy() on the receiver side (obviously after key/nonce generation and exchange of public key from receiver to sender). There are bindings for Java.


Would it be a security risk if I moved PsTools to the windows system32 folder?

I use them from \Windows\ for easy quick deployment.

No problem whatsoever from a security perspective.

I try not to use the system directories, as things are hard to trace in there already, but directly in \Windows\ things are very clear and easy to follow from a "what exe files should be there" perspective.


Do (uncompromised) passwords ever need changing, if I use a password manager?

Do you know that they are uncompromised?  If you are absolutely sure, then there is no real need to change.  Obviously if they are compromised, then go ahead and change.  If you do not know, then it becomes more interesting.

That is the main purpose of changing your passwords, just in case they are compromised and that you are not yet aware of it.  So the whole 90 day password change policy is usually a risk based compromise between how likely is your password compromised, and how annoying is it to change and re-remember (or in the case of a password manager, update and start using).


Is it possible to change the admin user/password remotely on a router without logging in?

Most routers use a HTTP Basic authentication scheme.
To access any page, including the change password, the credentials would need to be sent in header.
So, you dont need to "Log In", but you would need to send your credentials. Does that count?


There are many ways in which a session management mechanism can fail and this could lead to severe security risks.

As a good practice you should:

Use HTTPS, so that the information in the cookies could not be intercepted in transit.
Set the secure flag for the cookies, so that they are not sent over unencrypted connections.
Set the HTTPOnly flag for the cookies, so that they could not be read using JavaScript
Ensure that the session identifier (the value in the cookie that identifies a valid user session) is not easy to predict. Use large random strings for this purpose.
Ensure that the session identifier is changed when the user starts a new session (logs in), to prevent session fixation
A session expiration mechanism should be implemented on the server. Do not trust the user for this job.
When the user logs out, invalidate the session on the server, so that even if an attacker attempts to use the identifier, it would not be accepted by the server.

From your description, your aplication fails to meet the last point in the list above. You should check to see if the other points are satisfied. The sum of all the vulnerabilities in the application is the one that offers you a general view of how secure/vulnerable you are.

You should take into account that by exploiting the problem you have described, one may be able to access an user account without credentials. How bad is this in the context of your application? Could this malicious user access sensitive data, place orders, etc? For one application this may have a great impact, for another one it may be less important.

For further reading check out:
OWASP Session Management Cheat Sheet


Where can I download vulnerable Windows OS images to practice penetration testing?

Check out NIST's FDCC (Federal Desktop Core Configuration). They offer Windows XP and Vista downloads.
http://nvd.nist.gov/fdcc/download_fdcc.cfm [mod note: link is dead]


IP Spoofing: How secure is to control access by user’s public IP address?

Short Answer
Assuming a TCP connection, it is nearly impossible to spoof a source IP address without control of the network.
Longer Answer
Assuming you are not using any proxies (which can cause issues if you're getting their IP address from a X-FORWARDED-FOR header), and running a service on TCP, it's extremely difficult to spoof a source IP address
To initialize a TCP connection multiple packets have to be sent back and forth between the server and the attacker. If the source address for the initial request is spoofed, then the attacker would be unable to finish opening the connection because the spoofed address is not their address. So when the server sends a packet 'back' to them, it would instead be directed to the real owner of the address and not the attacker.
I would make a diagram on Visio for this, but I am in class, so hopefully a sketch is sufficient.


Storing multiple hashes to prevent collisions, security risk?

This is not a good idea.

The first reason is that collisions are not an issue. For password hashing, you don't rely on resistance to collisions, but on resistance to preimages. There is no need for a password hashing function to admit easy-to-build collisions, but if it does, this is not a problem either. For instance, collisions can be built with PBKDF2. And we don't mind.

The second reason is that the attacker intent on finding a password which matches a given hash has no need to compute several hashes. The attacker tries a long list of potential passwords, but that list is way smaller than the hash function output range. The consequence is that when the attacker finds a matching password, it is the password -- and this is so even when the attacker works over a single hash function. Therefore, though you spend the CPU to compute several hashes, the attacker is perfectly content to work with only one. In other words, the several hashes waste your CPU. This is important because you normally want to use a slow hash (with a configurable number of iterations) so that attacks are made slower. By doing the job several times, you force yourself to lower the iteration count, thereby automatically giving an advantage to the attacker.

The third reason is a generalization of the previous one: the attacker only needs to work on one hash value. If you provide several, then this can only help the attacker: he will choose the one which makes things easiest for him.

Summary: your "several hashes" idea does not solve an actual problem, but it may help the attacker. So don't do it. As @Iserni explains, use bcrypt. For a more detailed treatment on how password hashing should be done, read this.


Is a server absolutely safe if the attacker don't know unknown bug?

The question itself relies on some pretty critical, and invalid, assumptions:

We know who the attacker is.
We know what the attacker does and does not know.
We know that the attacker does not know about zero-day vulnerabilities in our system.
The attacker's level of knowledge and skill is static.
A system can be absolutely safe.

We cannot assume to know who the attacker is.
With very rare exception, if any, it is impossible to know who will be attacking your system in the future. Chances are, you don't even know everyone that's attacking your system now. Therefore, you must do what you can (within reason) to prepare for all possible attackers.

We cannot know what the attacker does or does not know.
The second assumption is very much reliant upon the first to begin with. Even if you do know who's attacking you though, it is the very nature of human beings that one person does not comprehensively or authoritatively know everything that another person knows.

We cannot know whether an attacker knows about zero-day vulnerabilities in our system.
The very nature of zero-day vulnerabilities is that we, as defenders do not know about them. That's why they're called "zero-days" - as long as the attacker is the only one with knowledge of a vulnerability, defenders have had "zero days" to develop or apply patches or configuration changes necessary to mitigate them.

Attackers are always learning and developing new skills, tools, and techniques.
Even if you do know who your attacker is and what he knows, and that his knowledge is limited to only the vulnerabilities that are patched on your system, that does not mean that he will not learn something new in the future. If an attacker has studied your system, and realizes that he does not know of an exploitable vulnerability for the software and updates you have installed, the next thing they'll probably do is start to Google for other vulnerabilities that do apply. If nothing turns up there, they may try analyzing the system and software themselves to develop whole new exploit vectors.

No system can be made absolutely safe.
This is just the raw nature of security. No matter what, there will always be something that can compromise your system. It's our job to just make sure that that "something" requires extraordinary effort or resources, so that potential attackers are dissuaded from even trying. We should also put monitoring and alerting systems in place so that we can see when an attacker is successful and respond quickly and appropriately.


With the recent denouncing of SHA-1 by Google, should SHA-1 based PBDKF2 now be avoided?

The use of SHA-1 inside PBKDF2 or other password hashing methods is not affected by the collision attack shown by Google. In functions like PBKDF2 it is important that the used hash can not simply be reversed, i.e. it is not possible to construct the input from a given output (preimage attack) and thus not reconstruct the password based on exfiltrated password "hashes" in case of a hacked system. Apart from that SHA-1 is used in several thousand iterations inside a single run of PBKDF2 which further makes it harder for the attacker even if he has some kind of (probably very slow) preimage attack against SHA-1.


Does Windows 10 leak information about your IP address?

Is Windows 10 Leaking my IP Address?
Almost everything is leaking your IP address.
I'm going to avoid telling you your IP address isn't secret. You seem to already know that. Instead, I'm going to tell you what you're looking for: Yes, Windows 10 leaks information about your IP address ten over a hundred times until Sunday, even if you're behind a proxy!

Can that information or other information that Windows 10 automatically sends out to the internet be used to link an individual PC to an IP address?

Yes, see below
----------

## Web Search Group Policy ##

Registry Keys:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\Windows Search\DisableWebSearch
2. HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\Windows Search\ConnectedSearchUseWeb\
3. HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\Windows Search\ConnectedSearchUseWebOverMeteredConnections

-----

## Cortana Group Policy ##

Registry keys:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Experience\AllowCortana\value
2. HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\Windows Search\Allow Cortana

-----------

## OneDrive Service ##

Windows Services:

1. Sync Host (OneSyncSvc)
2. Sync Host_Session1 (OneSyncScv_Session1)

------------

## OneDrive Group Policy ##

Registry key:

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\OneDrive\DisableFileSyncNGSC

----------

## Remote Registry Service ##

Service: (RemoteRegistry)

-------------------

## Built-In Bing Search ##

Contacts Bing for things such as web searching. If a patch is made that circumvents the above fixing, you'll need to block Bing.

----------------

## Office 15 (2015) Telemetry Group Policy ##

Registry keys:

1. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\15.0\osm\enablelogging
2. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\15.0\osm\enablefileobfuscation
3. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\15.0\osm\enableupload

-----------

## Office 15 (2013) Telemetry Scheduled Tasks ##

Tasks:

1. Microsoft\Office\OfficeTelemetryAgentFallBack
2. Microsoft\Office\OfficeTelemetryAgentLogOn

---------

## Office 16 (2016) Telemetry Group Policy ##

Registry keys:

1. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\osm\enablelogging
2. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\osm\enablefileobfuscation
3. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\osm\enableupload

--------

## Office 16 (2016) Telemetry Scheduled Tasks ##

Tasks:

1. Microsoft\Office\OfficeTelemetryAgentFallBack2016
2. Microsoft\Office\OfficeTelemetryAgentLogOn2016

---------

## Telemetry Services ##

Services:

1. Connected User Experience and Telemetry (DiagTrack)
2. dmwappushscv (dmwappushservice)

---------

## Telemetry Group Policy ##

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry

-------

## Consumer Experience Improvement Program Group Policy ##

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SQMClient\Windows\CEIPEnable

---------

## Customer Experience Improvement Program Scheduled Tasks ##

Tasks:

1. Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser
2. Microsoft\Windows\Application Experience\ProgramDataUpdater
3. Microsoft\Windows\Autochk\Proxy
4. Microsoft\Windows\DiskDiagnostic\Microsoft-Windows-DiskDiagnosticDataCollector
5. Microsoft\Windows\Customer Experience Improvement Program\Consolidator

----------

## Application Impact Telemetry Group Policy ##

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat\AITEnable

-----

## Steps Recorder Group Policy ##

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat\DisableUAR

------

## WiFi Sense (HotSpot Sharing) Group Policy ##

Registry keys:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\WiFi\AllowWiFiHotSpotReporting\value
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\WiFi\AllowAutoConnectToWiFiSenseHotSpots\value

-------

## P2P Windows Update outside local network ##

Registry keys:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Config\DODownloadMode
2. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\SystemSettingsDownloadMode

-----

TLDR: Registry Keys, Tasks, Hosts, and Services
I could go on and on. But download Spybot Anti-Beacon, and it will block most of these, and more. You don't want to block Windows Update because software updates help maintain the security and integrity of your machine.
Note that blocking all of these telemetry options isn't going to prevent information gathering, so don't trust in them. This program is simply there to help you opt out of Windows 10 telemetry stuff.
They can still find out what accounts were connected to what IP address at each time, even if the proxy is system-wide. If you wanted to hide your information from Microsoft, you would literally have to blacklist all connections, and whitelist only the ones you want.

Communicating Other IDs

Does it communicate IDs or other information with its requests that can be used to link IP addresses to specific PCs?
If I'm at an internet café with my notebook and go online, does Windows 10 send out information that can be used to link my notebook to the IP I'm using when I open the start menu?
If a systemwide proxy is set, does Windows 10 use that proxy to do its automatic requests?

Yes. Yes. Yes, and yes. Look at Application User ID Tracking:
Registry key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion
AdvertisingInfo\Enabled

Answers to your main questions
Now that we've demonstrated a small fraction of IP-leaking processes behind Windows 10, let's talk about what can be done with this data.

If I'm at an internet café with my notebook and go online, does Windows 10 send out information that can be used to link my notebook to the IP I'm using when I open the start menu?

Yes, application advertising IDs, connecting to Windows Update with your Windows 10 account, etc. In fact, connecting to any of these services, of which there are many, during your Internet Cafe visit, can easily tell Microsoft where you've been.
It doesn't matter if you were behind a proxy or 40: all connections to Microsoft services are recorded. Every single IP address for every single instance of your advertising ID / windows key / windows account, is recorded.


This is because RFC 4754 only defines three ECDSA signature schemes for use with IKE, each using exactly one predefined elliptic curve:

ECDSA-256: secp256r1
ECDSA-384: secp384r1
ECDSA-521: secp521r1

Therefore, it is currently not possible to use private keys/certificates with other curves for authentication with IKE.

A solution to this problem is currently being standardized.


How secure is it to use ODBC Driver with SSL

If you are connecting to a service on database-server, that service also needs to listen to a port.
Not using an ODBC driver depends on the application at client-side. ODBC is intended to allow several applications (like e.g Word) to make connection to a database.

Opening ports of course should be limited as much as possible, but sometimes ain't possible. The database in this case needs to be listening to a port, to allow incoming packets. As long as the software/service using that port are secure and stay often updated, you should be okay.

Besides that, SSL is more secure that a standard connection.
This because SSL encrypts the connection. ODBC can be used with loads of protocols, including secure ones.

Did this answer your question?


Open ports with no services bound to them

...would that be considered a security vulnerability?

No since there is no application behind that port to be exploited. (This port is actually called closed)

Do not mix up an unfiltered port with an open port. A unfiltered port is just a port which has no specific configuration (rule) in a firewall. It can still be either open or closed.


Are there any risks with prepopulating a username from a querystring on a login page?

The only security issue I can see with this is that you will have your usernames appear in all sorts of logs and in your users browser history. For most applications, that wouldn't really be a problem though.

Also, you might want to opt out from sending referer headers from the login page. Otherwise, if you link to external sites you could leak usernames to them. As a user, I do not want site A to know who I am on site B.

As Mathew points out, all the usual consideration when handling untrusted data applies - so you need to think about XSS etc.

(If this is a good way to do it with ASP.NET is a separate issue that I don't know the answer to.)


Unencrypted passwords in a system considered a vulnerability?

First of all, you should not encrypt passwords. Encryption is reversible.
Instead, you should hash the passwords. A hash is kinda like one-way encryption.

When the user signs in, instead of decrypting, you encrypt hash the password they provided, and see if it matches the hash that is already stored in the database. If it's the same password (and salt), then the resulting hash will be consistent and you can let them in.

When hashing passwords you have to consider a few things:

It's important to use salt to prevent side-channel attacks in relation to duplicate detection.
You should use a well-vetted routine.
You should use a high enough Work factor so it is expensive to brute force.

I've explained all the considerations here: Why is MD5 considered a vulnerable algorithm?.

In summary, you should use BCrypt. (which has had more time to be vetted than Argon2)
Run a quick SHA-256 on the password before feeding it to BCrypt. (to prevent truncation)
The BCrypt Work Factor should take 50-500ms on your target machine.
Limit login attempts to prevent Online Brute Force as well as DoS via hash computations.
BCrypt already has Salt, but it's best to also include some Pepper (~72 bits of entropy) which is a quick sort of extra password added to the user's password. The Pepper is the same for all users, but is unique to your application. It is stored either in your source code, or better yet, in a separate text file, but never stored in an SQL database.
Include reasonable Password Strength Requirements in your application, because no amount of hashing will protect a weak password.

  Would an unencrypted password database in a system be considered a vulnerability? (think yes)

If you don't hash or encrypt, it's a vulnerability for sure.

  Would an unsalted hashed password database in a system be considered a vulnerability? (unsure)

Yes, primarily because of rainbow tables. However the bigger concern would be how strong of a hash function you are using. Most of the good algorithms already have salt, so if you don't have salt, there's a good chance you're using a weak algorithm.

  Would a salted and hashed password database be considered a vulnerability? (tend to think no)

You're right, this is OK. It's common to store both Salt and Hash in an SQL Database, but it's best to also include Pepper which is kept outside of the SQL database.

  And would an encrypted password database but with a same "secret" key be considered a vulnerability?

Yes. Reversibly encrypting passwords is bad. If the key is stolen, the passwords are easily retrieved without brute force. Hashing solves this problem.


A CAPTCHA would not be defeatable as an XSRF mitigation except by brute force, or another type of attack (eg clickjacking to frame the target site's UI in a redressing context). Image analysis could not be applied because an attacker from another site doesn't have read access to the content in the CAPTCHA.

However!

  One defense that developers use to protect against a CSRF attack is to implement a CAPTCHA in critical steps.

I don't know the developers you're talking about, they don't sound very sane.

You get the same benefit without the cost in degraded user experience by simply sending a token to the client and having the same token checked when it comes back to the server. (You can also get much more entropy in such a token than a user could comfortably type in a CAPTCHA, making it brute-proof.)

Per-session synchronizer token pattern


What are the logical steps taken to perform ssh key authentication?

For example, were I looking for the TLS steps, I'd expect something along the lines of: Check cert of https page (server) - Grab public key and encrypt secret with it - Securely send secret to server which should be the only entity with the corresponding private key to decrypt - Server and client now switch over to encrypted communications using the, now, shared secret.

You're on the right track, but kind of in reverse.
For HTTPS the private key is on the server and you receive the public key on your client machine via the certificate.
When you use ssh keys, the private key is on the client (your computer) and the public key is on the server.
The protocol can proceed in different ways. The explanation in this paragraph is a high-level description that is appropriate for older versions of SSH. The server can use your public key to encrypt a challenge that is sent to you. Since you are the only one with the private key (hopefully), you are the only one who can decrypt the challenge. Thus, by successfully decrypting the challenge you have authenticated yourself without having to enter a password.
For more modern versions of SSH the protocol proceeds in somewhat the "opposite" direction. The protocol is described in RFC 4252. At a high level, the difference is that rather than accept a challenge from the server that is encrypted with the public key (on the server), the client uses the private key (which only the client has) to sign a message. The message the client signs contains: 1) session ID string; 2) message code byte; 3) user name; 4) service name; 5) authentication method; 6) boolean TRUE; 7) algorithm name string; 8) public key ID string. The server receives the signature and verifies it with the user's public key. This establishes the user's identity and so authenticates the user.
For more of the gory details, you can, for example, use Wireshark to observe your own traffic as you connect to a server using your ssh key. This will give you a better understanding of the detailed messages sent in practice.


Do concurrent connections to an HTTPS website perform separate SSL handshakes?

Each new connection does a separate TCP handshake and a separate TLS handshake. But if there is an existing SSL session they will try to reuse it, so all but the first connection to a server only do an abbreviated handshake if the server supports session reuse. In case of session reuse no key exchange is performed, that is the same symmetric key is re-used. See also How does SSL/TLS work?.


Is nonce useless when user input is reflected within an inline script?

reflecting user input within an inline script with nonce attribute beats the purpose of using it.

That depends on the type of injection you achieve.
If you manage to construct an XSS vector that stays within the nonce'd script tag, you're right, it's useless. You can just inject additional script code via e.g. "; alert(); //.
But if you're forced to close the script tag (say, because <, > are allowed but " is not) via e.g. </script><script src=evil.example>..., then the CSP works out, because you can't successfully inject new scripts without knowing the correct nonce.
Note that in the past, nonce exfiltration techniques and other nonce-related browser bugs have come up that may have rendered the second case exploitable, too. Have a look at this talk by Spagnuolo/Weichselbaum.


What is "Intentionally misleading Artificial Intelligence to create a misleading outcome" called?

This question may be better suited for English.SE.

Disinformation is defined as the the act of misinforming someone by giving them deliberately incorrect information, often with the purpose being to change the actions or behavior of the target. This is not specific to humans, and disinformation would be applicable to an artificial intelligence that implicitly trusts input and will act on it. This has a nefarious connotation.

An example could be telling a military tactical advisor computer that its country's adversaries have just amassed a large quantity of weapons of mass destruction. Despite being programmed well, the machine may conclude that the best course of action is a massive preemptive strike.

Garbage In, Garbage Out, or GIGO, is a term in analytics and logic, very often applied to computer programs, which essentially means that the conclusion made by an algorithm is unsound if the premises are flawed. This term came from concepts in scheduling: First In, First Out (FIFO) and Last In, First Out (LIFO). Phrased another way, no matter how sophisticated a computer is, the computer's output is only as accurate as the information given to it.

An example of this could be providing a utilitarian political advisor supercomputer with incorrect utility values, leading to felicific calculus giving an incorrect or even horrific answer, despite the machine attempting to improve the quality of human life. If you tell such a computer that people get a huge sense of thrill out of being robbed, it very well may suggest reducing the budget to fight crime.