I did something similar a while back to ensure we were keeping up with security updates. It's all manual, though: I can't help you automate it but I can tell you how long it took me and give an example of what I ended up using.

The initial setup took a couple days (we use > 75 libraries), and since then it's just been an hour or less per week to maintain it (not counting the time to actually update the libraries we use). I ended up with a matrix in a spreadsheet, with a row for each library we used. Then the columns were:

version we use
last version I checked
NEWS file (any issues I identified from scanning the NEWS or other readme files provided by the library)
CVEs (known to exist in our version)
latest version available from our vendor (we don't pull directly from upstream)
status, which says "OK" if NEWS and CVEs are empty and latest-version-checked matches latest-version-available, or I manually set it to some other status like "needs future fix" or whatever is appropriate
notes

I filled out the table with our libraries and their versions, then downloaded the full CVE database in text format and used a good text editor to search it for each of our applications. If there were any CVEs for our libraries I listed them in the CVE column and added notes about the version where they were fixed and/or why they applied to us (or in the case of some well-known CVEs, why they didn't).

I also skimmed the NEWS files for most of the libraries that had newer versions available than what we were using, though I gave up on that after a while when it didn't yield anything useful that wasn't already captured in a CVE.

Then I subscribed to an RSS feed of newly-categorized CVEs. It's fairly low-volume, though bursty, so when new CVEs come in I quickly scan them for issues and update my spreadsheet if there's anything that applies to us.

I also made a cron job to scan a different list of newly-filed CVEs, but that didn't seem to add any value beyond what the NVD RSS feed provided.


Corporate computers have own corporation's cert as trusted CA; should I consider all traffic compromised?

Yup.
Yes. (If you consider "My company's admins can change my HTTP(s) traffic" compromise.) Except for some programs that pin their certificate use and fail if another certificate is used.
That's pretty much the idea of SSL inspection: Open up SSL/TLS, do some anti-virus-scanning, close up SSL/TLS again.
And in place of that "do some anti-virus-scanning" you can substitute any manipulation of the traffic, you want.
But on the other hand: whoever can install a root CA on your system has superuser power already. So there's a million other ways that they can interfere/listen in.


Remote means that traffic will be intercepted in both directions; I.e. bidirectional arpspoofing so that traffic destined for the victim is intercepted as well. This is so any DNS replies can be spoofed by the attacker before reaching the victim.


How to become an internationally recognized certificate authority (CA)?

To be intentionally recognized, the trusted certificate authorities (CAs) will need to get their root certificates pre-bundled with specific web browsers and operating systems (OS), like Microsoft Internet Explorer, Apple Safari, Mozilla Firefox, Google Chrome and Opera (et al.). The trusted root certificate list is usually updated periodically to add or remove certificates.

In addition, specific programs like Java or Adobe have their own trusted root CAs which is used in their applications (thanks paj28 for the reminder!). Adobe has a setting which allows all Windows root certificates to be trusted automatically. However, I think the process is not so straightforward in Java.

To be included in Microsoft's Root Certificate Program,

  The CA must provide the information requested below, and receive preliminary approval for membership in the Program.

Similarly, Apple's Root Certificate Program requires root certificate authorities to meet certain criteria. This goes on for other browsers.

Other web browsers/OS may have their own specific requirements and legal agreements. Hence, to be as recognized as "internationally" as possible, a CA usually needs to contact all the major OS and web browser developers to obtain permission to be included in each pre-installed list of trusted root CA certificates.


Are SSH packets encrypted even before new keys are sent?

In SSH 2, key exchange is done using the Diffie-Hellman key exchange. It is best described on the Wikipedia page (the link). Also on the Wikipedia page are a lot of links to documentation (RFCs) containing nitty gritty details. Wikipedia or Google is probably best to find out more about Diffie-Hellman.

As a cool experiment you can download Wireshark and try recording an SSH session, to see how it works:

This is a Wireshark capture of (some of) an SSH-2 session. It is not a full picture, but shows the key exchange. Subsequent packets are encrypted directly after.

SSH can be done with Putty

And to be clear: the key exchange is not encrypted, but it is done in a very clever way, invented by two hippies in the 70's.


Inconsistencies found in OpenID Provider's HTTP Headers. Which one is the most secure that I should imitate in my STS, and Relying Party?

Use HTTPS, cachin/expires won't matter.
X-XSS-Protection as Google does.
Strict-Transport-Security (and the subdomain directive)
nosniff, blame IE.
X-Pad... if someone using using Netscape... there are bigger problems.


Why our key and our plaintext should have a same size in One Time Pad

I think Amussen mixed it while trying to make it clear.
Consider that you have 264 possible 128-bit keys instead of 2128 then the possible keyspace is reduced to half of its security.
This time you will ask how the attacker will know which ones are missing. Since we assume that everything is known but the key, we also know the key-space. So if we have time and money we can list them and see the possible messages and the reverse is the impossible messages.
Therefore read this

If the key is only 64 bits

as the effective key length of the key-space is 64-bit, i.e. the key generation can generate up to 264 different keys.


Fido U2F Public keys in registration response

They're the same. Note that signature doesn't contain the data shown in grey - rather, it's a signature of that data.


What security considerations should I make when choosing a TOTP app?

Most HOTP/TOTP apps are essentially the same; the algorithms are publicly documented, so most users merely see slight UI differences. However, there are a few security things you might consider when choosing one:

Is it open-source? Google Authenticator, for instance, used to be, but no longer is (which IIRC directly inspired RedHat's FreeOTP). However unlikely it is that Google has introduced code to steal users' tokens, it is possible; you also miss the other benefits of open-source, like being able to hunt for bugs in the source directly.
Are secrets backed up somewhere external? I recently had my phone unexpectedly die, and this meant I had to reset my 2fa codes on a bunch of services (while not having access to my phone number for sms or phone calls, the most common backup method). This was a huge pain. It's not surprising that many users would like to use a service that stores the underlying secrets somewhere external, so they can continue to use them in case of a device switch. However, this comes with an inherent risk: that factor is no longer "something you have", but access to your account, which is often another "something you know". You can make the argument that codes are no longer a second factor. Authy (optionally) falls into this category.

Beyond that, you've got considerations like "Does this integrate nicely into my existing tools?" that are very real UX considerations, but don't impact security other than in how they persuade users to use (or not use) MFA.


Client authentication flaw in old Netscape SSL protocol

Let C be the attacker. C runs another server, under its own name (C), with its own public key Kc. Occasionally, A connects to C (knowingly, but not knowing that C is Evil, or believing that the evilness of C won't extend beyond C itself). Attack goes thus:

Client A connects to C and sends {Kac}Kc to C.
Immediately, C connects to server B and claims to be A. C generates a random Kcb and sends {Kcb}Kb to B.
B responds to C with {Nb}Kcb to C. Since C knows Kcb, C can decrypt that and obtains Nb.
A is still waiting. C sends to A the value {Nb}Kac. That's the tricky point: C sends to A as challenge the same value as the one sent by B to C.
A responds with {CA, {Nb}Ka-1}Kac, as per the protocol. Since C knows Kac, C can decrypt that.
C sends {CA, {Nb}Ka-1}Kcb to B.

And, voila! C has successfully executed the protocol with B, sending a proper certificate and signature from A, computed over the challenge value that B sent to C. C is thus authenticated as A with regards to server B. The genuine A noticed nothing, and is not aware that anything was done related to server B at all.

The correction described in the article fixes the issue, which is that in the original protocol, the signature from A is retargetable: in the attack, A signs a challenge received from server C, but the signature also works as a response for the same challenge from server B. Including B's name in what is signed prevents the manipulation: now, a response to a challenge from a given server cannot be used as response to the same challenge from another, distinct server.

There are other similar attacks which also force the inclusion of A's name in what is signed. In SSL/TLS as it is currently defined, the signature from the client (in the ClientKeyExchange message) is computed over a hash of all previous handshake messages (sent and received), which includes both the client and server names (as part of their respective Certificate messages).


Unfortunately, the situation you describe appears unsolvable. You need to invalidate the token, but the only ones that can do so are the game developers.

Possibly you can persuade them of your identity, and after creating a new account have them transfer everything from the old to the new. The unknown crackers would then find themselves with an empty, lifeless husk of your old account.

Other approaches could involve trying to locate the unknown parties that have your token. If they're threatening I guess they're communicating somehow. (Just in case -- I'm not advocating recoursing to counter-threats. Things might end badly, or deteriorate anyhow. But knowing enough about the responsible parties might offer leverage [e.g. "they" is a skript kid with reasonable parents], or even be leverage by itself. It is difficult to erase the gaming account of someone who knows who you are and where you live, and might recourse to rubber-hose cryptanalysis).

You could also try and involve the police in this: at least in my country, any identifying access token, be it a stainless steel key, a code on a slip of paper, or a password, is considered my property and e.g. copying it with pencil and paper (with intention to use it to access my data) is a criminal offense. The nature of the data - online game, biscuit recipe or online banking account - is irrelevant.

So e.g. agreeing to release a sizeable amount of money or valuable hardware in exchange for a guarantee of the token being destroyed (a silly proposition - as they say, once you pay Danegeld, you never get rid of the Dane) would likely result in the culprit or culprits, usually not too experienced in the ways of crime, having you leave the booty somewhere and being intercepted by the police as they attempt recovery.


It depends... you can set things up so the commands are recorded on the client side.  By default the sent commands are not logged by the client though, if that is your question.  A much more common configuration (security-wise), if audit logging (via pam or some such method beyond just simple ~/.bash_history) was enabled they would see that ssh was run and then could review logging on "B" and find what was run on the "target".  This is all "if" things are configured for this, it may be possible to track down the info.


How do VPN providers exactly encrypt traffic from client to their server?

How exactly VPN providers encrypt data from client to their server?

There's numerous algorithms, or cipher suites.  Which ones that can be used are dependent on the exact protocol used.  You want to avoid using broken ones so using the latest versions and good configurations of your software is needed.  One you want to avoid for sure is anything DES.
OpenVPN: You can look at any installed instance of OpenVPN's supported cipher suites as well.  The server must support the same suites as your client.  It's worthwhile to ask these questions and research for any VPN provider.  Older VPN mechanisms like Microsoft's PPTP had vulnerabilities and have been deprecated.

how do VPN providers exactly restricts usage to a few devices.

You sign into them with a username and password, or certificate.  OpenVPN supports user authentication and certificates.

there's no way to know to know who is using how many devices

There is when you authenticate to the VPN server.  If you're already signed in then it knows you signed in twice and can deny the session.

If this is mapped to user account and they figure this out via his unique account then technically they are maintaining logs right?

Not necessarily.  The VPN server maintains a list in RAM of who is connected.  It doesn't have to be written to disk.  Also, if the username/password or certificate is not tied to your identity in any way (e.g. if you paid cash and received the credentials on a computer/IP/device not tied to your identity) then there is no opportunity to track.
Revocation lists can be used to deny access to revoked certificates, and servers can be set to deny access to expired certificates.  Through this a mechanism of certificate issuance and delivery that is separate from identity can be implemented, though whether or not it is, only the implementer would know.


Storing encrypted data readable only by user but created by server

One of the main cryptography principle is  Kerckhoffs's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge".

So the option with special key for every user sounds reasonable. Selected algorithm and key length should be strong enough to protect data in case when database is stolen. Recommendations for selecting algorithm and key length can be found in OWASP guide https://www.owasp.org/index.php/Guide_to_Cryptography

The main issue in that case would be how to protect user keys from stealing and implement appropriate key management.
The following items should be taken into account during implementation process:

Key storage: file or HSM (like SafeNet)
Frequency of key rotation (e.g. change keys once a year)
Master key (a key from storage with other keys) protection


The concept of a write blocker is to ensure the forensic integrity of a system while simultaneously forensically imaging that system. This is accomplished by permitting read-only operations to a file system, thus a write blocker will prevent all write operations by intercepting them and either translating them into a read operation (if possible) or simply disallowing the write operation.

For instance, a hardware blocker may simply just not include the physical connections for writing (as with USB) and a software write blocker may intercept otherwise write operations -such as disallowing metadata to be changed when viewing an image.

Taken from here:

  The United States National Institute of Justice operates a Computer Forensics Tool Testing (CFTT) program which formally identifies the following top-level tool requirements:

  A hardware write block (HWB) device shall not transmit a command to
  a protected storage device that modifies the data on the storage
  device.
  An HWB device shall return the data requested by a read operation.
  An HWB device shall return without modification any access-significant information requested from the drive.
  Any error condition reported by the storage device to the HWB device shall be reported to the host.


Diffie-Hellman key-exchange: securing prime and base

In Diffie-Hellman there is a large integer which is prime, but the other one needs not be large, and it needs not be prime either.

With DH, computations are done modulo a big prime p. A generator called g is also used: g "generates" the values gi mod p. If you (virtually) compute the gi modulo p, you will get back to 1 at some point; the smallest non-zero value i such that gi = 1 mod p is called the order of g (let's write it r). Necessarily, r divides p-1.

What DH needs is that:

p is large enough to make discrete logarithm hard; say, at least 1024 bits (current fashion is 2048 bits, because 1024 bits are now considered to be "a bit too weak" as in "unbreakable for now, but maybe in 20 years...").
r must have at least one prime factor q which is large enough to deter discrete logarithm; in this context, this means at least 170 bits (there again, fashions dictate 256 bits -- cryptographers just love powers of two).

q and r needs not be known by the people who do the DH. If you select a random p of appropriate size, and a random g (as a value between 2 and p-2, inclusive), then g will be fine with overwhelming probability (you will not know r, let alone q, but it would be extremely improbable that all prime factors of r are short).

Nevertheless, you could try a bit harder in the choice of p; for instance, you could select p such that p = 2t+1 where t is also prime. At this point, any g (between 2 and p-2) is guaranteed to have an order equal to either t or 2t, so you can choose g as you see fit. In particular, you can choose g = 2, which makes computations a bit faster.

None of the values above need to be secret. Indeed, both DH parties are assumed to know them beforehand, so they cannot be secret (if they were secret, it would be a shared secret and you would not need to do Diffie-Hellman at all, you could just use that shared secret as is). To save effort, you could reuse existing, published values for p and g, for instance these values.


The First Few Milliseconds of an HTTPS Connection [TLS 1.2 / TLS_ECHDE_RSA_WITH_AES_128_GCM_SHA256]

Disclamer: I am NOT a professional cryptographer nor an expert on the subject, only a security enthusiast. Therefor, I strongly encourage anybody more qualified to improve this post.

Before we start, I assume you mean "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" (0xC0,0x2F).

So based on the article you published, here what would change compared to TLS1.0.

TLS1.2

[Client] ClientHello

First things first: the protocol version should be 1.2 (0x0303) and the client specifies the following parameters:

Supported cipher suites
Supported extensions along with their associated values (server name, named curves, EC point format, ALPN support, signature algorithms, etc.)

See below a capture of a ClientHello packet (Firefox 51 Nightly).

⚠ Some extension parameters aren't unfolded because empty/irrelevant.

[Server] ServerHello

The server picks its preferred cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) and point format (uncompressed (0) since it's listed as first choice) and send it back to the client.

[Server] Certificate

The server returns its RSA certificate, nothing changes here.
The server authentication process is identical to the one detailed in your article.

[Server] ServerKeyExchange

The server send the curve type (named_curve), the selected named curve (secp384r1), its ephemeral public key (04:31:b9:9d:bc:66...) and the selected algorithms for hashing and signature.

The signature is defined as:

SHA-256(ClientHello.random + ServerHello.random + ServerKeyExchange.params);

and is signed by the server's private key.

The curve secp384r1 (also known as P-384 under NIST classification) is standard and defined by the following equation:

E: y2=x3+ax+b (mod p)

with the following domain parameters over the prime field Fp-384:

p = 2384 − 2128 − 296 +
232 − 1 = 39402006196394479212279040100143613805079739270465446667948293404245721771496870329047266088258938001861606973112319
a = -3
b = 27580193559959705877849011840389048093056905856361568521428707301988689241309860865136260764883745107765439761230575
g(X,Y) = 26247035095799689268623156744566981891852923491109213387815615900925518854738050089022388053975719786650872476732087,
8325710961489029985546751289520108179287853048861315594709205902480503199884419224438643760392947333078086511627871
n = 39402006196394479212279040100143613805079739270465446667946905279627659399113263569398956308152294913554433653942643
h = 1

All these parameters are public.

Side note: Both the client and server have agreed on using a named curve, resulting in a much smaller Server Key Exchange packet since the domain parameters are standardized and thus known by both parties.

The server public key is calculated as:

Kpub = Kpriv × G

The server private key is just a random number, defined as:

1 ≤ Kpriv ≤ n-1

[Server] ServerHelloDone

No difference with TLS1.0.

[Client] ClientKeyExchange / ChangeCipherSpec

This packet contains the client's ephemeral ECDH public key. It's calculated the same way as the server's public key (again, the generator G is common between the client and the server).

From that point, the client advise the server the next message(s) from it will be encrypted.

[Server] ChangeCipherSpec

The server acknowledges client's last message by returning the same ChangeCipherSpec message.

Beyond that point, all communications are encrypted using AES-GCM 128bit.

The symmetric key is calculated on both parties by multiplying its own private key by the other's public key i.e.:

Client : Symmetric Key = Client Kpriv * Server Kpub
Server : Symmetric key = Server Kpriv * Client Kpub

TLS 1.3 (bonus)

As of today (august 2016), TLS1.3 is still a draft so it would be premature to deep dive in it. Still, writing similar article based on packet sniffing would be tricky on TLS1.3 because the handshake is vastly different as illustrated below:

Source

As you can see, sniffing the handshake sequence (using cloudflare server) won't tell you much since the relevant data are encrypted in the ServerHello packet (see "EncryptedExtension" field).

I couldn't illustrate the sequence using Wireshark since TLS 1.3 is not supported yet.


Spoof IP address after a TCP handshake established

Certainly! If you're able to spoof valid sequence numbers this is in possible. This is essentially the TCP Sequence Number prediction attack:

The attacker hopes to correctly guess the sequence number to be used by the sending host. If they can do this, they will be able to send counterfeit packets to the receiving host which will seem to originate from the sending host, even though the counterfeit packets may in fact originate from some third host controlled by the attacker.

That's also why there's been a push to ensure that sequence numbers are hard to determine for an outsider.


Is it safe to use a passphrase to seed fernet key generation?

No, it's not safe at all. A passphrase would produce a deterministic key, but that would make this key vulnerable to brute-force and dictionary attacks. Besides, Fernet.generate_key() uses a CSPRNG (os.urandom()) which has an OS-specific randomness source and it does not accept a seed.

It is possible to create deterministic but strong keys, using a password-based KDF. Python's built-in hashlib library offers two such functions: pbkdf2_hmac() and scrypt(). Both KDFs introduce a work factor (a good amount of CPU resources must be spent in order to produce a key) which makes brute-force/dictionary attacks practically impossible. I recommend scrypt because it costs CPU, memory and parallelisation resources, while PBKDF2 only consumes CPU resources.

Creating a Fernet compatible key with scrypt:

from hashlib import scrypt
from os import urandom
from base64 import urlsafe_b64encode

salt = urandom(16)
key = scrypt(b'password', salt=salt, n=16384, r=8, p=1, dklen=32)
key_encoded = urlsafe_b64encode(key)

The salt should be long and random; although it's not a secret, it must be unique for each password.
The n, r, and p parameters determine the work factor (n=CPU/memory cost, r=block-size, p=parallelization). Those values can be increased depending on the OS - the key derivation process should take about 100 ms. Only the password is a secret value, the salt and n, r, p values can be stored or transmitted with the key.


Authenticate-then-Encrypt: does the authenticity provide a benefit?

It seems you are asking: If the receiver can correctly decrypt the message using the secret key, isn't that proof already that it was sent by the other party which also has the secret key?
AES and similar block ciphers don't really make distinction between succesful and failed decrypt operations. A message is transformed in a certain way, and that hopefully results in the plaintext. So we would need to check the embedded HMAC or CRC checksum to see whether the decryption succeeded.
An attacker would be able to manipulate the ciphertext so that the CRC is correct for the plaintext.
With certain ciphers, such as AES-CBC, an attacker can change the ciphertext in a manner that reliably changes the plaintext. If an attacker would modify the ciphertext, our HMAC or CRC checksum would no longer be correct. However, for a CRC checksum, the attacker can modify the ciphertext until the CRC is correct again. The attacker can flip bits in the embedded CRC, and can calculate what it should be.


What criteria should be used for manually reviewing / prioritizing failed logins?

At face value, this is easy, but as anyone can tell by reading your question (or for those of us who have implemented something along these lines) this quickly becomes a can of worms.

Lets look at a few potential metrics...

Failed attempts per username -- the standard metric by which an account gets locked out, keep it low and most attacks will be blocked.

invalid usernames per IP per x hours -- Seeing 100 login attemps for unique invalid usernames in an hour from the same IP is a good indicator of malicious activity.

locked out users per offending ip over last x hours -- If one IP has caused n number of users to get locked out in the last x hours, that's suspicious. You'd want to compare this to the number of successful unique users logged in from that IP. If there has been one good login and 40 locked out users, something fishy is going on and worth banning the IP until an investigation can confirm.

avg & max valid user logins per IP over x hours/days -- gives you a good baseline for what standard use might be from NAT'd networks.

The key is to build baselines and flag any anomalies either for manual review or automatic action. That automatic action could be locking out a user, banning or rate limiting an IP, flagging an IP or user as suspicious and requiring all logins from that source to go through additional bot prevention steps i.e. CAPTCHAs and or email verification.

Some sites require these additional verification steps from any user logging in from a new device, this too will greatly decrease the potential for a successful user based attack.

As for your optional scenario, lets say they are using sock puppet accounts to meet baselines to appear as a NAT environment. Lets say they have 100 accts logging in successfully. If they are trying to get into a specific account, that account will be locked out after 3-4 tries. Assuming you have a decent password policy, attack prevented. Lets say that they're trying to get into one of 10 accounts, would 10 accounts being locked out in an hour from a NAT environment be normal? Doubt it.... Flag the IP for suspicious activity requiring users to verify their humanity after one failed password attempt.

Ensuring that users get locked out in a reasonably quick time will prevent most brute force attacks. Adding IP based metrics for locked out users, invalid users, and other related metrics compared to baselines and tied in with standard bot prevention and user verification methods will further decrease your risk and ensure happy auditors, sysadmins and users.


How does consent.exe know what to display?

Based on the Russinovich TechNet article you linked: Remember that applications call out to the Application Information Service (AIS) to elevate. So consent.exe doesn't need to know how to launch programs. It exists solely to establish user consent, and return the result to AIS. AIS then does the actual launching (assuming consent.exe returns success).


Which approach to use to implement encryption in a Windows desktop app?

I strongly advise using platform-specific libraries wherever possible. The main reason is that they'll get updates automatically, whereas if you bundle a third-party library then it becomes your responsibility to monitor for updates to that library, produce updated versions of your software with the update to the third-party lib, and get your users to install the update. With frequently-updated libraries (such as OpenSSL), this is a considerable maintenance burden to take upon yourself. In my years as an infosec consultant, I saw many, many outdated OpenSSL libraries bundled with applications, most with a few dozen CVEs.

Of course, if you have to support an OS that no longer gets security updates from its developer (on account of being 16 years old), well, you're screwed either way. I'd still lean towards using the platform-provided libraries (Cryptography API or "CAPI", in this case), both for performance and because worrying about the security of anybody who uses an out-of-support OS is a fool's errand (but your users on current OSes will appreciate being able to stay secure).

One downside of using the platform APIs if you want to support XP is that XP only has the legacy CAPI, not the CNG (Crypto API Next Generation) that Vista+ offer. CNG both supports newer algorithms (I know it offers EC algorithms; less sure about CAPI) and has a nicer / more flexible API.

CNG is also a lot easier to "plug into" by third-party code, which is useful if you have a client that, for example, wants to use a specific implementation of certain algorithms (or key storage, or whatever) instead of the MS-provided implementation. This is another reason to use platform libraries, of course; if somebody has changed their default CNG provider, they probably want you to respect that!

I suggest you consider very carefully whether it's actually necessary to support such an obsolete OS when writing security-conscious code.


Your best bet for this issue would be to compile a list in Excel that shows all the blacklists that you are on, and begin with identifying if the blacklist requires you to call and confirm the information or if it requires you to register with an account and confirm that it is no longer spamming.

| Blacklist Name | Date Identified | How Long before it can show clean | Contact Information |

I used to work at an ISP and we had IP addresses for different regions. Thus a large amount of traffic would get blocked because of people getting infected.

I found that for the spamhaus ones it would usually take a few weeks of no one being infected for us to be removed. Symantec and a few others also go off these lists, but it can also help to call and explain your issue. Barracuda is really good about this as well, if you call and inform them of the situation they will generally put in a ticket and 24 hours later you should be off the black lists.

As far as google, you will need to have your site re-indexed if you are showing as a malware site on there.

EDIT:
Here is a list of blacklists, and there delisting policies that should help you well along your way.

SPAMHAUSE - Removal http://www.spamhaus.org/lookup/

Google Malware Removal - https://support.google.com/webmasters/answer/168328?hl=en

Barracuda Spam Removal - http://www.barracudacentral.org/rbl/removal-request


php's password_hash with system wide salt

There are two main problems with this approach:

Someone trying to bruteforce a single password will still have to go through the same amount of computations, but someone trying to get the password for multiple users will have to compute only one table for all the users on your system.
But the more important problem is that it's a deprecated function, which means that maybe you can't rely on it after a few more updates and thus your code might not run anymore as soon as the function is removed from a future PHP update.


Spying apps: Android mic and camera access

As all software based techniques have a potential to be flawed or hacked (and, as @Jason commented: an app that is seemingly not running might still run), there may be a 'hardware' based solution:
A good old sticker that covers the camera (only really practical for the front facing camera) is a solution that's not hackable. 'Camera cover slides', available for about 8$ at Amazon, are the more convenient alternative.
Unfortunately I'm not aware of a similar simple solution regarding the mic.


Can malware be installed on a mobile phone when the user opens an sms?

Yes, it is possible. There's in general two main ways to achieve this:

Social engineering. Fool the user into installing a piece of software. Installing software not in the app stores are doable on Android, and quite a lot more difficult on iOS.
Find a vulnerability, that either lets you install arbitrary apps without user interaction, or let's the browser leak the desired data to you. Sandboxing attempts to avoid browser data leaks.

It's not an easy task, but it's not entirely unlikely either.

The easiest way to mitigate the risk is not to access unknown or unexpected links, or in case of messages pertaining to be from a service, e.g. your bank, access them by manually entering the address in the browser. This will mitigate for instance Punycode attacks.

TL;DR: Software may have security holes.


How should I handle a spam account I don't control from sending spam emails with my username?

Anyone can create new email accounts with "John1234", and those usernames are considered "public" so you have no control over that.

What is more interesting is how the spammer got a hold of the distribution lists. I would highlight the "change password" advice and make sure that proper hygiene is being practiced.


Detecting incorrect CA to prevent MitM attack

If the server requires client certificate authentication then it will fail in case of intercepting proxy server. A tunneling proxy server will (most likely) work but it will be unable to decrypt the data.


Is it okay for API secret to be stored in plain text or decrypt-able?

No.  The API keys need to be stored in cleartext.

They are not passwords: they are cryptographic keys.  These keys are used for things like authenticating requests (using SHA1-HMAC).  The server needs to know the crypto key to apply the cryptographic algorithms.

Therefore, the API key needs to be stored in cleartext on the server.  If the server stored only a hash of the API key, it could not verify the authenticity of messages from the client or authenticate messages sent to the client.


Depends on the malware you have "developed", the real answer is simply NO.
I've seen malware starting with guest user rights and escalating to Admin.

If you need an alternative solution to a VM in order to run Malware on your pc with full PC controls and no consequences is DeepFreeze.

Once installed, you can run anything or delete anything on your PC. It will always boot back up normal, same as the moment you installed DeepFreeze. Disable it and all the changes are written permanently. If enabled it will always boot back in normal state no matter what you do, even if you delete /system32.. :)


For your own good.

If you disable CORS the following can happen:

I send you link to a page called hackfacebook.com for example. When you visit my page, I then request the facebook.com page using an AJAX request which if you are logged in returns the page content as well as your session cookie.

I now as the owner of hackfacebook.com have your login session.

As you can see disabling CORS is at your own risk as it can open up another attack.


SSL certificate mismatch does not show warning in browser

ifttt.com is in the Subject Alternative Names extension in the certificate.

Each certificate has a primary name, but it can also have multiple alternative names.  Hosting providers and content distribution networks that host multiple websites but wish to provide SSL Certificates (which is good) often use this method to create certificates that are valid for multiple sites that are hosted by the same service.

This is typically considered safe because the people who own the sites that share a certificate don't actually control the certificate - their hosting provider does.  The individual site owners don't have the private key.  This means they can't use the fact that they are Subject Alternative Names on a cert to man in the middle sites they share with.  The host could, of course, but the host already truly controls those sites - they don't need to man in the middle.  You ultimately need to trust them.


Are public website s3 buckets vulnerable to DDoS attacks?

If you're concerned with massive data transfer costs on CloudFront, you would still be vulnerable as CloudFlare can just be circumvented. You'd need to pay for AWS WAF for protecting your CloudFront distribution.
As an alternative, you can ditch CloudFront altogether and serve content from your S3 bucket allowlisting only Cloudflare IPs for s3:getObject, and still have Flexible SSL just for your assets subdomain/path using custom Page Rules:

https://support.cloudflare.com/hc/en-us/articles/360037983412-Configuring-an-Amazon-Web-Services-static-site-to-use-Cloudflare

Edit: Still need to set up public access on your bucket, but access can be restricted by IP

https://community.cloudflare.com/t/setting-ssl-tls-mode-using-page-rules/118211


Is it safe to use a proxy server within psiphon?

As I understand, Psiphon uses an encrypted tunnel (VPN like) for communication. That means if you first send data to proxy that then sends it to Psiphon, all the data going through the proxy is encrypted. The proxy owner can see when and how much you use it, but he does not see any more then your ISP already would. He can't see any content specifically.


How does a hacker reach a back-end file to exploit it?

"Hackers" don't really do (or need to do) what you are describing. In some cases, a misconfiguration may allow for a remote user to view the text content of a PHP script file (e.g. maybe a backup file with a file extension not normally executed by the PHP interpreter, or some arbitrary read vulnerability), but this is not required to construct a working exploit.
In general, I'd say there are at least two ways an attacker may find vulnerabilities without reading the source off the server:

The application is a well-known open source product (e.g. WordPress), and the attacker downloaded the source and found a vulnerability that way, or they found an existing vulnerability that applies to the version on the target server.
Certain design patterns immediately raise red flags to the trained eye. If I see in the URL something like /?file=store.html, this looks like it could be used for directory traversal/LFI/RFI (e.g. maybe replace the file parameter with ../../../../etc/passwd to test). Or, if the website lets me directly or indirectly run system commands (e.g. "Enter an IP address to ping"), it may be worth attempting shell escapes (8.8.8.8$(cat /etc/passwd)) to see if there is a command injection vulnerability. These type of blind attacks are often more of an art than science, as it can take quite a bit of intuition and assumption on the attacker's part to figure out how the system works and where a vulnerability may exist.


SSL mismatch error using ISP-provided IP address but not VPN IP address

Is the SSL "mismatch" on my ISP's side, and if so, should I have any security concerns? Tks.

It can be at your ISP but it can also be a compromised router which redirects traffic. A VPN installed on your local machine might protect you in both cases.

If it is your ISP then other users of the ISP will probably be affected too, unless the ISP (or some hacker/agency there) targets especially you for some reason. So I think that a compromised router is more probable. Since routers are often insecure lots of them can easily be hacked with CSRF or similar attacks just by visiting some external web sites. The hack can change the DNS settings so that most traffic from then on is under control of the attacker. See for example the compromise of millions of routers in brazil 2011/12.


I see no immediate problems with that approach. Especially if you use a per website salt in addition to a per user salt. So that your combined salt is complex enough. The main function of a salt in password hashing is preventing rainbow tables. And you don't need a highly random salt for that.

I still wouldn't do it that way, since using a random salt is standard practice. And inventing your own crypto is usually a bad idea, because it's easy to get wrong. So I'd simply follow the standard practice unless there is a really good reason not to.

IMO it's more important to use a KeyDerivationFunction with enough iterations to slow down brute-force attacks than to worry about the randomness of your salt. Having some salt is essential, but only one of the things you need.


Which topics should a security training for non-IT persons contain?

I actually did a presentation similar to this a little over a year ago, and spent quite a bit of time deciding how to structure it. My target audience did include developers and other people quite knowledgeable in IT, but also managers and other non-programmers, so I tried to keep it fairly general, and not to technically complicated. As someone else pointed out, I think one important thing is not to come across as boring; you want this to be an enlightening talk that helps people realize that this is something they ought to keep in mind, and not just another list of dreary tasks that will get in the way of actual work.

To this end, I tried to center the whole presentation around the concept of security culture instead of jumping straight into too many technical details. With that in mind, I still managed to touch upon many of the themes you mention in your question.

Some of the stuff I mentioned in my talk

(or would touch upon today if I was to hold another similar talk):

Confidentiality, Integrity and Availability (CIA): The central themes of information security, and a few should-be-obvious words about why these are important both to your company, and to individuals (if you can give people a little guidance that will help them stay safer beyond the workplace too, then that is only a plus, right? It might also make some pay more attention to you too - especially if you touch upon the safety of their kids/family too).
A few words about the concept of "security culture" ("culture" as in "a set of ideas, habits and social norms, common to a specific group of people", or something like that, and the idea that security awareness should be a conscious part of this).
Goals of thinking about security: Reducing the risk of unwanted incidents, preparing to handle them if / when they occur anyway.
Keeping cost in mind (or return on investment if you like); thinking about what measures will be easiest to get started with, and which make the most sense. I would include a few words about good habits here; such things as update your systems, use good passwords, and avoid clicking suspicious links, be conscious of physical security (tailgaters!) etc. Perhaps include a few examples from real-world events, including screen shots of news articles about breaches, etc?
Throw out a few questions related to what type of vulnerabilities or threats might be relevant to your particular company, and more. Examples: What are the "crown jewels" of our business? What is most important to us, and what may threaten them? How secure are we today, how secure would we like to be, and how can we get there in the future? In what areas would we want to improve our security stance? The point here is not to give people a checklist of things to do, but to get them thinking about the whole realm of security in general, and help take responsibility for parts of it, themselves.
Give a few examples of typical security guidelines, and ask your audience if any of them (or similar) should be considered for your workplace.

Oh, and one more thing: Including a few appropriate real world examples of security problems will help keep your audience entertained (but don't overdo it).

I don't know if this is exactly what you were after, but I hope it may be of some use. Good luck with your presentation.


I don't use TLS extensions, I'm safe of HeartBleed?

These "heartbleed" testing services work by attempting to perform the OpenSSL TLS heartbeat exploit and seeing if it is successful.  There are three possible outcomes:

1) The server accepts the malformed "heartbeat" packet and drops it.  In this case, you can be reasonably certain the server is unaffected (or that a firewall or other service is protecting it).

2) The server accepts the packet and returns random memory contents in its response.  In this case, you know for certain that the server is vulnerable.

However, you're encountering another option:

3) The server states that it does not support the TLS heartbeat option.  It's reasonable to assume the server is safe, but you can't be certain.  It's possible, for example, that the server is using the vulnerable version of the OpenSSL library and can be tricked into accepting a TLS heartbeat packet.


Security concerns surrounding HTTP GET in Web Development

Over TLS (https) connections, both POST and GET data is encrypted, so there's no difference in that regard.
To avoid SQL injection (or other) issues, you must validate and sanitize all incoming user input regardless of whether POST or GET was used.
Inherently, using POST requests is not more secure, but it's good practice to use POST requests when submitting data that will change (for example) something in the database.
If using GET, there's a bigger risk that your server logging tools will also log sensitive information by default (HTTP request log will contain all data). You can minimize this risk by submitting data with POST.
Also, in some scenarios (depending on your specific usage and needs), having sensitive information in the URL as query parameters (for example /data/something?secret_key=123321) will also be stored in the browser history, and this might be a risk if shared computers are common for your users.


How does Burp Suite evaluates this request as high severity with the issue "user input evaluated as code"?

The automated scan result is showing a potentially exploitable issue. Like every other automated scan result, you would have to perform a false positive analysis.

The easiest way to analyze this would be to perform a code review to see how the affected parameter is handled server side. If this is a blackbox/ graybox security test and looking at the code is not possible, then:

You need to use the Burp proxy to replay the request using the repeater tool and manipulating the sleep time value to see if the results are consistent (see bottom right corner in repeater tab for response time). If the behavior persists you might want to try injecting some other commands to confirm this. e.g. a command that makes the host connect back to a web server controlled by you (this depends on other variables such as network access for the host).

The vulnerability is server side code injection. The scanner injected the sleep command in the password field twice and noticed that the server took a longer than usual time to respond when it was asked to sleep for 10 seconds. This indicates that command injection may be possible.


I'll answer this based on my experience with the CBMC compiler.  I never used HitmanPro, malwarebytes anti-exploit or Microsoft's EMET but I do not see any reason why they would do things completely differently from CBMC.

Known exploit protection

If we look at the malwarebytes anti-exploit video (kindly researched by OP), we see that MBAE could find an exploit by identifying a downloaded malicious file.  That is exactly how a modern anti-virus program works: it checks the signature of a known malware (or "exploit payload" if you want to call it that way) and stops its execution if it matches.

In that specific case we can argue that Anti-Exploit is simply a re-branded name for an Anti-Virus program.  In theory you can argue that AV (Anti-Virus) only checks signature of files, whilst AE (Anti-Exploit) checks the payload (e.g. whiled downloading a file)  You can also argue that AEs searches for CVEs whilst AVs search for malware signatures.  But all modern AVs perform all that: they are updated when CVEs come out, they check signatures of network traffic (downloaded files) and they do that in real-time.  So I'll argue that, from that video, we can conclude that AEs are simply AVs rebranded.

Yet, there is more: AEs promise to be able to find zero-day exploits.  And that would be different from AVs.

Zero-day exploits

You can't find a zero-day exploit in a program without running the program.  But running a dodgy program is unwise.  This is because, if there is an exploitable point in the runtime environment, running a program may exploit exactly that breach.  Sandboxing is an option, but sandboxes often have breaches of their won.  So, how can we execute a program without executing it?  Symbolic execution to the rescue.

As I said at the beginning of the answer I'll use CBMC, a tool I needed at some point in the past.  It performs symbolic execution, but it is a research tool.  And no one really argues that symbolic execution can find all possible problems a program may have.

CBMC is a C compiler (and has a commercial version for VHDL too) that does not compile a program into machine code.  Instead it compiles the program into a language called GOTO, which is a simplified symbolic representation of the program.  Then a GOTO processor (part of CBMC) is used to run the symbolic representation of the program.

A symbolic representation is much easier to reason about, and the program can be run assuming a wide range of inputs.  For example, one of the things that CBMC/GOTO catches well in C programs are buffer overflows.

Now, CBMC works on C and VHDL programs, but the same can be done with assembly.  Although it would not be as accurate as constructing a symbolic representation from the source code (since disassembly is not perfect), it would allow to execute the symbolic representation of the program and check for coding mistakes.

Buffer overflows are the easiest things that one can think that can be found in the assembly as well, but other possibilities may include unchecked input (input is tracked in a symbolic representation, at least in CBMC) or opening network sockets (since it is a known syscall).

Disclaimer: I do not know how an AE is actually built, but if I had to build something that can find a zero-day exploit automatically symbolic execution would be the path I'd try.  Symbolic execution does not come without issues (known to the open research community, some non-disclosed sources may have found solutions to some of them):

SE does not find all problems, e.g. interaction between different configurations is often not found.
SE is rather slow.
Intel or ARM (or any other) disassebmly is never perfect, and disassembly problems reflect into SE results.


Can a HTTPS MITM decypher server response packets?

There are two separate problems mentioned in this question: authentication and session encryption.

As for eavesdropping on the initial response, it is a problem of encrypting the session. Each session between the client and the server is protected using a different key. The key exchange algorithm (whichever is used) ensures only one party receives the keys used to secure the transmission.

The technical details were already explained in answers to How does SSL/TLS work?, but in brief an ephemeral key-pairs are used. They are separate from the public key sent by the server in the certificate.

The server's public key (included in the certificate) is on the other hand used for authentication (in public-key cryptography when you encrypt the data with a private key you are effectively signing it not encrypting, anyone can decrypt it with the publicly-known public key).

For the client authentication you can also use a key-based authentication, but this scenario is much less common. Usually you authenticate using password or some other method over an already-established secure channel. In this scenario there is no need or way to "pretend you are the intended client" because at the moment of initiating the connection there is no notion of the intended client yet.


Does this concept attack work to harvest credentials and 2FA using offline fake site?

Seems like your intent is to defeat Two-Factor Authentication. There are a few ways to do this, some of which use your setup.

What is Two-Factor Authentication?

Two-Factor Authentication is essentially an added layer of security. If someone steals your password, and you have 2FA enabled, it is unlikely that they'd be allowed to log in without additional login details. For example, the World of Warcraft authenticator, a text message, or an email containing an access code.

Is Your Attack Possible?

  Is this thing working in a real scenario? 2FA can't block access of the attacker?

This is two questions:

This is likely working in a real scenario.
Correct, 2FA is relatively dumb when it comes to detecting something like this. 2FA only tries to verify, with an additional layer of security, that you are who you say you are when connecting from an unknown source.

However, https poses a challenge. How do you get the user to install a fake certificate in their browser? Most browsers are going to warn the individuals right off the bat if something is going on. Do you think most users will click, "I understand the risks, let me visit anwyay"?

You may not even need to use ssl in some cases. You could probably redirect them to http:// instead of https://, and they wouldn't notice it. A tech-savvy user may not even realize it.

Moreover, I would modify your attack:

Collect their browser fingerprint
After they attempt to login, redirect them to the true Facebook website with a login action.
Use their browser fingerprint to log in.

Why? Because Facebook will alert them of the login. If it matches the IP address they're connecting from, and it shows the same browser fingerprint, then Facebook would likely presume you're just using Incognito mode with another browser window since your cookie sessions are different.

  Can you host offline https site and fake certificates to make less suspicious the site?

What you are describing is essentially a man-in-the-middle attack alongside DNS hijacking for the purposes of phishing.

Yes, this is definitely possible. I've done something like this before as a test to try and defeat World of Warcraft's authenticator (I was bored, and wanted to see if it could be done; only did it to myself), and it worked pretty well - but I did not use DNS hijacking for that, only a MiTM.

How do you defeat Two-Factor Authentication?

I realize some of these methods will not be a direct response to your question. I'm simply providing an alternative viewpoint, as your goal is to break 2FA. You have to think outside the box.

In many cases, 2FA can be defeated by a keylogger / trojan.

"But Mr. Buffalo, why would I use a keylogger? How would I even infect them?" If you control the rogue access point, you can direct the user to a fake login page, or an EULA page with a "continue" button, and you can host a drive-by-download exploit on the page. Most users aren't going to look for this.
In cases where different IP addresses and browser fingerprints are detected by the login system and rejected, such as World of Warcraft's secret auto-ban program that bans individuals connecting to North American servers who are located in China, and other "high-risk" countries, even if they're legitimate users, then you can defeat these detection systems by using the victim's internet connection as a proxy.

2FA can be defeated with your method, but would be even better if modified with the above suggestions.

In cases of web browsing, you should also steal the victim's browser fingerprint and use it. This is a lot more work than you think, but if you pull it off, then it will appear to originate from the victim's machine, and not yours. Scary, isn't it? Someone could impersonate you with incredible precision, and even get you in trouble for breaking the law when it wasn't you who did it. This is a good reason why IP addresses can't be considered a person.

In either scenario, it requires a lot of work.


Why should I persist OAuth 2 access tokens along with refresh token

What would be the point of hashing the accessToken?

We hash passwords because people reuse them everywhere. If they would not reuse passwords, we would not need to hash passwords, the application has been hacked after all (as the attacker gained access to the db), so all is already lost.

accessTokens are not reused. and adding to security, are only used once (for 10 minutes for example, depending on your token lifetime). So why would we need to hash them? RefreshTokens can be used to obtain multiple accesstokens, which is why it seems reasonable to hash those, but even that is disputable as refreshTokens are not used across applications.

If you really want, you might think about encrypting the accessTokens, but we suppose your entire application has been hacked, including the encryption key. By the way, you don't really store an accessToken, rather you store the ticket to obtain an accessToken, but that doesn't change the relevance of your question.


How do connection relays strengthen anonymity?

There isn't any real magic here. The thought is that it is non-trivial to trace a message to it's physical location. It generally involves support by the ISP and is strongly regulated by the prevailing laws. So, while it is possible to trace messages, it requires some effort.

If I use an intermediate relay, the thought is that anyone tracing packets to my server will first find my intermediate relay. Upon analysis, they will see that it is acting as a relay and then they need to trace the relayed packets. So you've roughly doubled the amount of effort required.

If the relay and the server are in different countries with different laws, someone tracing the packets would now need to navigate two legal systems. And if the countries are known for not supporting this type of research, this could be very costly. Adding more relays increasingly raises the cost of tracing packets to the server.

Some negatives of this are increased communication costs, increased complexity, and having to deal keep up with changes in multiple legal systems.


Certificates and keys for mass production devices

If the requirement is that the server can authenticate a client device immediately after the device was first switched on then there is no other way but to ship devices where each has a unique certificate in the firmware or associated data. How this can be accomplished depends on the process how these devices are produced, i.e. how the firmware ends on the device, if associated data (like the certificate) can be added later etc. And this part is also not an information security problem, i.e. off-topic.

If there is instead some setup procedure involved when the device is first installed then it might be possible to create the certificate (or the CSR if a server side CA is involved, see below) during setup and inform the server about the new device and its previously unknown certificate. Of course there needs to be some authentication for this so that only valid devices announce themselves to the server. This can for example be accomplished if some unique key is shipped together with each device on paper or USB stick and is entered (or plugged in) as part of the setup procedure.

On the server side it might be possible to either store each client certificate for validation or have some private certificate authority (CA) which signs all the client certificates so that the server can simply accept all certificates issued by this authority and extract the device identity from the subject of the certificate. The approach of using a CA scales much better with many devices.


Open (residential) less safe than Public WiFi?

Open wifi is open wifi, whether is is residential or not.  A MITM can be performed on a coffee shop network just the same as it could be done on a residential network, albeit using different means.

There is no higher or lower level of security between a coffee shop's wifi and a residential wifi.


Is it safe to use a Windows executable with expired SHA256 certificate but valid SHA1 certificate?

What a signature means: The signature means that the program hasn't been tampered with after being signed. (Ex. inserting malware into it would break the signature) Signatures don't prove whether a program is safe, just that it hasn't been modified since it was signed.

Although the SHA256 signature has expired, this doesn't necessarily mean that the signature can no longer be trusted, so long as Microsoft has kept that private key safe. The file hasn't been modified to break the SHA256 signature, it's just time for them to switch keys, so Microsoft doesn't have to hang onto and protect old keys forever. It also means that if the key is compromised and it can't be revoked, it will eventually expire on its own.

Unless Microsoft's private key was compromised between February 17 and now, the expiration date doesn't matter. If the key was compromised and used to sign something evil before February 17, the expiration date wouldn't save you.

TL;DR: It's almost certainly from Microsoft, but they should sign it again.


good books for learning network and web security?

Cryptography basics
Coursera.org offers a great course on cryptography. You can check it here: https://www.coursera.org/course/cryptography
Not only you will be able to learn a lot, Coursera will also help you to test your learning by giving you some tests.

Web Security/Network Security Basics
Coming down some books, there is one good book called Gray Hat Hacking, The Ethical Hackers Handbook, 3rd Edition by Allen Harper. This book is recommended for newbies and is easily available in almost every bookstore.

Another book on web security is Web Application Security, A Beginner's - by Bryan Sullivan

However, I will not suggest you to buy and start reading these books without any prior knowledge. You must first work on improving your programming skills, learning C/C++. PHP, Python, Java and Ruby will help you a lot, and networking skills, basic knowledge of TCP/IP will help you a lot.

You might also want to learn ASM (Assembly language) for developing exploits and reverse engineering.

There is a website called http://opensecuritytraining.info/, which provides free tutorial on various aspects of the information security. You can try that also.


Blocking the whole network is easy: you flood the whole network with high volume packets so that nothing else can communicate.

If you got very clever, you could script something to log into your home router's web interface and shut down the network or reboot it.

For a targeted approach:

As a matter of networking, one node cannot block another node. You would need a central control node, like a switch, to block communication from a node to make sure that the node was blocked and you did not also affect all the other nodes.

At the switch level, you can block the port, not the IP or MAC, that is the source of the unwanted traffic. This is a very common approach. This function is not available on home equipment.

Using your home router's web interface, you might be able to figure out the port, and use whatever functions are available on the router to block the node. But that's quite the sophisticated level of browser automation.


When does one need to be concerned with leaking timing information in .NET?

Sleeping a random amount of time doesn't totally stop the information leak: if the attack can be repeated, the random part will average out to a constant. Instead, you should make sure that the operation always takes the same amount of time.


Standard to represent digital signature on paper

Your question is a good one. The basic issue is that a digital signature is associated with digital data. And (equally importantly), access to the original digital data is required in order to verify the signature or signatures.

Therefore, the transmission medium needs to be digital.

Three answers:

The paper copy is a pointer to the real (digital) original

In this scenario, the paper print out contains a QR code to the real original, which is stored on a server. There is no need to worry about proving the validity of the paper print out since it is merely a pointer to the real original, which is stored on your server.

The recipient (the relying party) would always need to look up the server copy to see what it contains and to verify its standard digital signature.

You would want to put a minimum of information on the paper printout since you do not want a recipient to think that they can rely on the contents of the paper printout--they can't and shouldn't rely on it, it is not reliable.

The paper copy would simply say "The agreement was digitally signed on date by signer. Download the original and verify its signatures by using the QR code."

I would suggest that you not require any user names or passwords in addition to what is contained in the QR code itself.

The paper copy's data can be verified

In this case, you want the recipient to be able to verify the paper copy's data without needing an online version of the data. Unfortunately, regular print on paper is not digital (OCR is not 100% accurate or repeatable.)

So I would re-cast your question to be "How can I reliably transmit digital data using paper?"

There are answers for that these days including 3d bar codes and special OCR fonts. Depending on how much content there is, you would include the original text as a digitally signed pdf file in the QR code. You could include a copy of the original text on the page.

You would have the same problem as above--if the document's text is readable on the page, then verification that it is the exact same as the text that was signed is very difficult or impractical. On the other hand, disputes are infrequent. The printed version could be verified when necessary.

The paper copy is a representation of the signed data

These types of documents are accepted by relying parties all the time (they're called faxes). There is plenty of case law about the legal validity of a faxed document. The laws differ by state and country, so consult a local lawyer.

If a facsimile of the original document is acceptable and legal, then you can simply print out a representation of the digitally signed document. Hopefully a graphic signature was supplied by the digital signer. If not, you can create one using the signer's common name from their certificate and a script font. The important issue would be to include a reference number to enable the original, digitally signed document to be retrieved if needed by a challenge. DocuSign and other vendors do this. Note the reference number for the online version.


Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?

This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder.

Here it is in a nutshell:  If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL parameters from the incoming URL to the outgoing redirect URL, then it is possible for third parties to exploit this artifact of your web site in a wide variety of nasty ways.

Worst case: evil.com is able to get the auth code originally intended for your web site (example.com) and may be able to use that auth code to extract user information from the auth provider (Google, Facebook, etc) or possibly even take control of the user's account on your web site.

Would evil.com be able to take control of the user's Google account using that access code? No, because the access code was minted for your site, example.com, and only works there.

Who's fault is it?  Yours, for implementing an open redirect on your site. Don't blame Google or Facebook or others for your poor implementation.

There are a few legitimate use cases for having a redirect on your site. The biggest one is to redirect the browser after login to the web page (on your site) that the user originally requested. This only needs to redirect from your web site to pages in your web site, on your domain.

How to fix it?  Have your redirect endpoint (example.com/redirect?&destination=ht.tp://foo.com...) validate the destination URL. Only allow redirects to pages on your site, in your domain.

More info on my blog: http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/

Update: There is an open redirect issue when using Facebook for OAuth user login. When you configure your app definition on Facebook, be sure to enter your domain-specific redirect URL in the redirect field provided. Facebook allows this field to be left blank. If left blank, Facebook itself acts as an open redirect while processing user logins for your web site.

Facebook should fix this by simply not allowing the redirect URL field to be left blank.


is this secure: email account that can only be accessed by sending and receiving emails within gmail

Gmail's spam filter is only concerned with spam.  Gmail will deliver email with SPF failures, and an invalid or missing DKIM signature.   If you don't believe me, send a spoofed email to your self.

If you are concerned with spoofed email,  then it would be better to use a service such like the Sendgrid inbound parse webhook,  which will include detailed SPF and DMARC information for all incoming email.


How can I determine if my employer is using their security certificate to MITM employees' HTTPS connections?

I would expect that I should be able to see which CA was used to
establish a connection in my browser, but I'm not sure how to do this.

It varies by browser, but in Chrome, for example, you would click on the padlock on the left hand side of the address bar:

Then click on the line where it says "Certificate":

After you click "Certificate", a new window will pop up.  Click on the tab named "Certification Path" and look at the root certificate (the top certificate in the list).  If that is the one your employer provided, then they are MITM this connection to this web site.

If I see my employer's certificate, can I assume that they are able to
see my unencrypted traffic, and if I see a different certificate, then
it's not?

Correct, that's how you can tell.

Is there any way to make a determination or is completely unknowable?

It's absolutely knowable.  It would be labor intensive to try and do for every web site, but frankly, once you find your employer MITM one web site, you can assume they're doing a lot of web sites.  Many employers exclude health and financial web sites from monitoring, for what that's worth.


How to distinguish malware from system crash?

Indicators of compromise may be in the memory, files, network traffic.
Try looking for the logs, maybe you can activate some of them (secure, auth). Try monitoring the traffic using a sniffer in the same machine or in the network gateway, looking for differences before/after reaching for this site.


No, you are not vulnerable to session fixation, because of this authToken that you give to your clients when they log in.

You would be if

...the attacker has fixed a session he knows on the victim's computer, then the victim logged in with this session and made it authentic, now the attacker can use only this session to get access. But you are giving your clients new secret when they log in - the authToken.

without something new you give to your clients when they sign in, you would be vulnerable.

  I am confused because of the extra token that is given when the user logs in.

In your model the authToken plays the role of the sessionID that you generate and give to your clients when they log in.


Are hashing functions designed to be injective where the domain is limited to the codomain?

As to your update, your standard cryptographic hash functions (MD5, SHA-1, SHA-2 family, SHA-3) try to approximate random oracles (and do not attempt to be injective).  That is they attempt to map any input to an output chosen uniformly at random in your output space (and do this mapping consistently).  With overwhelming probability, random oracles will not be injective when the number of possible inputs is significantly larger than the square root of the number of possible outputs, due to the birthday paradox.

For example, if you have a 128-bit hash output (a 16-byte hash with 2128 possible outputs) and use a random oracle to hash significantly more than sqrt(2128) = 264 inputs, it begins to become overwhelmingly probable that there will be collisions.  On the other hand, if you hash significantly fewer than 264 inputs, it will be very unlikely to have a collision if you started with an ideal random oracle.  (If you hash around 264 inputs than the chance of being injective is approximately 1/2; there may be a collision or not).

As a specific example, if you hash all 272 possible 9-byte inputs the probability of a random oracle being injective onto a 16-byte space is about exp(-n2/2m) ≈ 10-14231, where n = 272 ≈ 4.7 x 1021 and m = 2128 ≈ 3.4 x 1038.  This is incredibly unlikely; roughly equivalent to playing powerball (odds of winning 1 in 292 million) twice a week for 16 years and winning the jackpot each and every time with no losing tickets.  And again, this is only for a 9-byte input; with a 15-byte input the probability of being injective is about 10-1127492937032632506267955467381579!

Meanwhile, if you hash all possible 7-byte inputs, there's only 256 of them so with large probability there will be no collisions (that is it will be injective).  As this is significantly less than sqrt(2128), a random oracle would not be injective with probability with odds of 0.0000076 (about 1 in 130 000 times it would not be injective and the rest of the time it would be injective).

See the probability table on wikipedia for more information.

Granted this is not a proof for any specific hash function; to prove it we would have to generate a specific collision within the input space which would in general is difficult to show.

Now if you need an injective function that acts similar to a hash, this is quite simple to achieve by using a block cipher (formally known as a pseudorandom permutation) like AES and choose a random key to encrypt it with.  Block ciphers are necessarily both injective and surjective.  If a block cipher was not injective, then a person with the key and the decryption function and a block of ciphertext to decrypt with couldn't possibly recover the original block.

The downside of using a block cipher instead of a hash function is that the block cipher requires input of just one fixed length and transforms it into output of the same fixed length.  For example, AES can only take a input that is 128-bit and transform it into a 128-bit output.  (Yes you could use block cipher modes to transform larger inputs, but still for it to be one-to-one the output size would be the same length as the input).  The fact that a hash function can take variable sized inputs and output a fixed size hash makes it ideal for many purposes.  The fact that this requirement of hashes to map variable sized inputs taken from a very large input space into a smaller output space means that it will not be a injective by the pigeonhole principle is usually not a problem in practice.


Is it possible to obtain the WPA key of a wireless network while connected to it with an Ethernet cable?

If the key is not already saved on the computer you have access to (which you exclude) and you don't have a way to sniff WiFi traffic (which you don't explicitly exclude but probably meant to) then your only choice is to extract the key from any device which knows the key and which are reachable from your system. Such devices include the router but often include other PC's, printers, phones, devices to stream music and other IoT gadgets. Protection of these devices is often weaker then you might expect, i.e. no password or standard passwords. And there are lots of backdoors, backdoors and more backdoors.


you cannot check that because the processor registers are encrypted. The SP register is also encrypted from android 4.4.4 and on.


site is only available in HTTPS

HSTS in this case at least notifies that browser that the site will not be available in HTTP for the foreseeable future. Once the browser knows this (i.e. after the first visit) a downgrade attack like sslstrip will fail, because the browser will not connect with insecure HTTP to the site.

The secure flag for cookies will probably not provide any security benefit because it was already enforced that the site is available through HTTPS only. But it does not harm either and is a cheap feature so in the spirit of multilayered security (i.e. add another layer in case one gets broken) you better add it.


Do XSS attempts leave any trace on the server?

What can the website owner see?

Basically everything.

If the XSS vector (<script>alert(1)</script> in your case) is part of:

- HTTP headers (including cookies)
- URL (path, query string) except the anchor part
- POST data (including uploaded files)

Then the website owner is able to see it.

If your XSS vector is client-side only, then the website owner may still log it if Content-Security-Policy has been configured to log attacks.

How to test XSS without being spotted?

Don't, unless if you have been permitted to do so.

Run your own vulnerable webserver

Running your own webserver is not that hard:

echo "<?php echo $_GET['xss'];" > index.php
php -S 0.0.0.0:80

This will start a webserver available at http://localhost/.

Known vulnerable applications

Also, check out some projects like Damn Vulnerable Web Application, created to help people learn some vulnerabilites.

Moreover, for XSS, there exists a lot of resources to learn them:

XSS Game, by Google
XSS Challenges


Dealing with users who reuse bad passwords

It would do you well to read up on why Troy created the pwned password list in the first place.

NIST guidelines are pretty explicit what to do: "If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value." (emphasis mine)

Block the bad password. Tell them why you're blocking it. For bonus points, suggest a randomly generated password they can use instead, or link to a site describing how to generate one (or provide a list of password managers).

Or, as others have said, use some sort of 3rd-party authentication, e.g. "login with Google" or "log in with Facebook".


Could a badUSB device actually hack your computer while it is supervised?

Hello there genealogy!

A bad USB is able to download files hosted on a website. A very common thing for pen testers to do is to upload a file (most commonly a shell, exe or malware of some sort) to a said directory of a website that, with the help of a script that the USB will run, will make the computer download said file.

Yes, the owner of the device can actually see when the bad USB starts doing its thing and disconnect it, but that is when other skillsets enter into play, like social engineering.

Hope this helped!


Understanding the security of my home network

Edit: I totally missed the home network part. Purchasing a network tap in this situation would be overkill. In your case Snort or Suricata could work. You could specifically make rules to search the packets for strings that would indicate insecure communication. You could further tune it by removing all rules not pertinent to what you're looking for, cleartext credentials. More details on making custom Snort rules here:
http://www.sans.org/security-resources/idfaq/snort-detect-credit-card-numbers.php

Enterprisey solution: I've seen people run Suricata or Snort on their systems but that doesn't seem to scale so well if you have high bandwidth usage. You are right that a network tap might be useful in your situation. I'm not sure if you're dealing with fiber or copper, but you could get a suitable tap and feed the data from the monitoring ports into other tools. These tools, which could potentially be Snort or Suricata, could scan the packet data for specific strings such as you'd see in LDAP authentication. There may also be DLP tools that could work for this use case.


Someone is using my (or has the same) email

Is it a scam?
First of all, make sure that you actually got the letter from a court. This might very well be a scam - it sure sounds like one. Do this to verify that the letter is real:

Make sure that the name of the court correspond to a real court.
Find contact information to that court through some independent method (i.e. not using any information in the letter).
Contact them and ask them if they did in fact send the letter.

If it is not a scam
If it is not a scam, I see three possibilities:

The person accusing you of the threats never received the emails, and have forged the evidence. That would not be hard to do. (An investigation of the email headers will not help here, since they can also be forged.)
Someone has spoofed your email address, and has sent emails that appear to come from you. This is by no means impossible. (An investigation of the email headers could be useful here.)
Someone has hacked your email account (perhaps you used the same password on a site that was breached), sent the emails, and then deleted all traces (e.g. removed them from the sent items folder). (An investigation of the email headers would not help here, since the email is in fact sent from your address. Access logs from your email provider could prove useful, though.)

If it's not a scam, what you need to do in any case is to get some legal advice.


How hard is it to hack the JWT HS256 algo?

require('crypto').randomBytes(64).toString('hex') creates a key that is 64 bytes (512 bits) long.  In this case, the key is then encoded as hexadecimal (by way of .toString('hex')) - but irrespective of whether the key is encoded hexadecimal, base64, or some other encoding - the key is 512 bits in length.
512 bits is an enormous space.  There are over 1.34 * 10^154 possible combinations of 512 bit numbers.  For some perspective, there are thought to be about 10^82 atoms in the universe.   To brute force a 512 bit key would require cycling through all of these combinations, and computing the HMAC for each of these combinations, until the correct combination is found.
Even if an attacker had an unlimited amount of computational power, he would not have enough energy to mount a brute force attack - as just cycling through all of the combinations (let alone computing the HMAC for each) would require more energy than the amount of energy stored in the sun (see https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html, and scroll down to where it reads Or read what I wrote about symmetric key lengths in 1996, in Applied Cryptography (pp. 157–8).  Note, this applies to digital computers, as well as quantum computers.


This is probably about (extended) key usage:

sign / verify is known as Digital Signature:

  Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.

encrypt / decrypt is known as Data encipherment

  Use when the public key is used for encrypting user data, other than cryptographic keys.

SSL is known as TLS Web server authentication or TLS Web client authentication

Source: this page of IBM which does a wonderful job of explaining (extended) key usage.

As for the differences: signature generation is used to provide message integrity and authentication (although it could be used for entity authentication as well), encryption is to provide message confidentiality and TLS authentication is to perform entity authentication.

There is another key usage for non-repudiation, which is for instance used for official documents. Non-rep has a slightly different use than just signature generation.


Does knowing encrypted information make it easier to find an unknown key?

As always, it depends on the algorithm. The attack technique you are asking about is called a "known plaintext attack", but it only works for certain types of encryption.  Modern cryptanalysis is all about pattern detection. A brute force attack is the last thing done because it means that all other avenues of attacking the cipher have failed.

Imagine a simple shift cipher such as rot-13 (a weak form of encryption no better than obfuscation). You and I know that the shift factor is 13, but our fictitious cryptanalysis does not.  However, because they have various samples of both the plaintext and the cipher text available to them, they can sit down and determine quite quickly that each 'a' has consistently shifted to 'n'. Noticing this, they will quickly detect that the shift key is 13 and "break" this rudimentary encryption scheme. If they did not have this ability to easily check their work, the act of breaking the code would take much longer and possibly require them to start "brute-forcing" their way to solving it by trying each shift factor.

It is my understanding that although encryption algorithms are usually susceptible to known-plaintext attacks, modern algorithms are usually constructed such that they cannot be attacked in any meaningful way. That is, you might have a symmetric 256 bit key, and after much analysis, shave off 10 bits from a pure brute-force attack. The algorithm now has 246 bits of complexity.  It will still take a while to brute-force that key.  AES is not supposed to have any meaningful attacks on it.

Asymmetric encryption is an interesting case in that you can produce as many cipher texts as you want to compare to your plaintext (you have free access to public keys after all).  You can use this time to find and exploit weaknesses in the algorithm or specific implementation.


Is OpenVas an active or passive scanner?

With the default Configuration OpenVAS will scan actively. It happend to me sometimes in the past that software crashed while scanning it with a vulnerablity scanner. In my expience this applies mostly to badly written PHP apps, IoT devices and cheap routers but of cause it can happen with other targets too.


PRNG: Does combining insecure algos help?

A PRNG can be insecure for several reasons, but one of them is using as seed some data which can have only a limited number of distinct values. For instance, if you use the current time as seed, then that value is known to the attacker, or at least potentially known with a not-so-hard effort: even if you have an internal clock with microsecond precision, and the attacker knows that clock only down to an accuracy of one second or so, then this amounts to only a million or so of possible seed values.

By enumerating the possible seed values, the attacker can recompute the same possible streams than you. You can add together hundreds of PRNG with any algorithms you want; if they all use the current time as seed, this will not save you.

"Adding" together several PRNG might help if the PRNG are all properly seeded (with distinct seed sources) and some of the PRNG are cryptographically weak. But there are subtle details; it is not easy to do right, and usually not worth the effort.

If openssl_random_pseudo_bytes() returns "insecure" then there is very little you can do to salvage it. Also, this does not happen in practice, unless your system is somehow damaged. Any decent server, be it Linux, Windows, MacOS, FreeBSD... maintains a cryptographically strong PRNG seeded with hardware events (that's /dev/urandom, CryptGenRandom()...) and that's what OpenSSL uses. If this does not work, then things have gone sour quite deeply in your system, and it is time to panic (i.e. raise exceptions and alert the sysadmin).


When the client implements the SSH protocol correctly, this should not be possible.

However, you can never rule out a bug in the client which can be exploited by a malicious server to obtain information from the client.


What are the known ways to gain complete access to hardware audio?

No offense but I believe you are being a little paranoid. If someone had the knowledge to take control of your computer, what would he gain by changing the audio quality? It doesn't make sense, at least in my experience (20 years of vulnerability analysis).

A Windows malware spreading by USB flash drive, that is common, but hey, with my hand upon my chest, just format your disks, install Windows again, don't ever stick in another USB flash drive, and be happy.


Requirements for qualified certificates in DIRECTIVE 1999/93/EC

An answer is provided for instance in ETSI TS 101 862 "Qualified Certificate profile":

  5.3 Qualified Certificate Indication

  The following two techniques can be utilized to declare that a certificate is issued as a Qualified Certificate:

  1) by identifying a certificate policy in the Certificate Policies extensions, as defined in clause 4.2.1.5 from
  RFC 3280 [3], clearly expressing that the issuer intentionally has issued the certificate as a Qualified
  Certificate and that the issuer claims compliance with annex I and annex II of the Directive [1]; or

  2) by including a Qualified Certificate Statements extension with an esi4-qcStatement-1 statement as defined in
  clause 5.2.1 of this profile.

Note that each Member State can interpret 1999/93/EC as they want, so the "qualified" quality of a certificate does not really mean much (for instance Diginotar used to deliver qualified certificates in the Netherlands). For some examples of qualified certificates used by the European Commission, see here


Limit on modulus lines in OpenSSH /etc/ssh/moduli file?

Most likely 4294967295.

In the source file dh.c, the moduli file is opened with fopen, and a fgets loop is used to extract each line. The current line being processed is recorded in a variable declared as int linenum. This means it is a 32 bit signed integer, capable of representing 232 possible values. Since it is signed, this equates to -2147483648 to 2147483647 (one less because 0 is still a number and is considered positive). Since it starts at 0 and increments, the maximum value is thus 232 / 2 - 1. It will become negative if it exceeds this bound and wraps around.

There is some conversion between signed and unsigned in the source code. The int linenum holds the number of lines, while int bestcount has the number of suitable lines and is passed to arc4random_uniform, which outputs a random value between 0 and bestcount. The value it accepts and the value it returns is unsigned, but it is stored in another signed integer, which. That integer is used to specify which random line is to be used. If the number of lines exceeds what an 32 bit integer can hold, the random choice of line's upper bound will be smaller, perhaps much smaller, than the actual number of lines.

This limitation is not an issue in practice. The maximum length of a line is 4096 bytes, and 232 lines (not - 1 because the first line starts at 0) of 4096 bytes each gives a maximum file size of 16 terabytes! Good luck waiting for openssl dhparam to generate terabytes of moduli.

The whole function in the source code, as of OpenSSH 7.5p1:

DH *
choose_dh(int min, int wantbits, int max)
{
    FILE *f;
    char line[4096];
    int best, bestcount, which;
    int linenum;
    struct dhgroup dhg;

    if ((f = fopen(_PATH_DH_MODULI, "r")) == NULL) {
        logit("WARNING: could not open %s (%s), using fixed modulus",
            _PATH_DH_MODULI, strerror(errno));
        return (dh_new_group_fallback(max));
    }

    linenum = 0;
    best = bestcount = 0;
    while (fgets(line, sizeof(line), f)) {
        linenum++;
        if (!parse_prime(linenum, line, &dhg))
            continue;
        BN_clear_free(dhg.g);
        BN_clear_free(dhg.p);

        if (dhg.size > max || dhg.size < min)
            continue;

        if ((dhg.size > wantbits && dhg.size < best) ||
            (dhg.size > best && best < wantbits)) {
            best = dhg.size;
            bestcount = 0;
        }
        if (dhg.size == best)
            bestcount++;
    }
    rewind(f);

    if (bestcount == 0) {
        fclose(f);
        logit("WARNING: no suitable primes in %s", _PATH_DH_MODULI);
        return (dh_new_group_fallback(max));
    }

    linenum = 0;
    which = arc4random_uniform(bestcount);
    while (fgets(line, sizeof(line), f)) {
        if (!parse_prime(linenum, line, &dhg))
            continue;
        if ((dhg.size > max || dhg.size < min) ||
            dhg.size != best ||
            linenum++ != which) {
            BN_clear_free(dhg.g);
            BN_clear_free(dhg.p);
            continue;
        }
        break;
    }
    fclose(f);
    if (linenum != which+1) {
        logit("WARNING: line %d disappeared in %s, giving up",
            which, _PATH_DH_MODULI);
        return (dh_new_group_fallback(max));
    }

    return (dh_new_group(dhg.g, dhg.p));
}

Note that this is all from a cursory glance at the source code. If there are other issues that may occur down the line for reasons I can't predict caused by a large file, the upper limit may be smaller. I don't see any reason to think it would be, though.


If you add a HOSTS entry for localhost.example.com and the certificate covers only localhost.example.com then no MITM attack within the network against your system is possible since your system will use the entry from HOSTS and not use DNS to lookup the domain.

But, if the application which includes this certificate is not only used by you but by others then everybody must also add such HOSTS entry in order to be safe. You probably cannot expect this.

Additionally an attacker can extract certificate and private key from the application and in some cases use it against users which don't even run the application. For example if login.example.com sets a session cookie with scope of domain *.example.com then this session cookie can also be read when accessing localhost.example.com - and a successful MITM of this domain is possible using the extracted certificate and private key.


Responder captures NetNTLMv2 responses. You then need to use something like hashcat to crack them, and if your wordlist is good, you will then be able to get the password.

The hash of the response will not match the hash of the password itself, because it contains more information than just that password, such as the server nonce.

See this zone13.io post for some more information. The cracked response with the password visible looks like this:


Why does healthcare.gov exclude some special characters from passwords?

Assuming they're storing their passwords hashed, a reasonable justification for restricting the sort of content that the password field is allowed to contain is simple input sanitization.

There are likely a set of rules that get applied everywhere unless the developer makes a special exception; that way the programmer doesn't have to remember to "turn the safety checks on" for a given component; everything is sanitized except where you have a justification for doing otherwise.

The characters that are getting filtered out are frequently associated with injection attacks of various stripes, and there's no reason why you need to allow those characters in passwords, and with no justification for disabling the security checks, the default policy applies.

Why 20 characters? It was probably the default in some component library.


What is the risk of someone else having access to your SSL certificate?

It is not needed to get a forged certificate for g00gle.com. The person behind the phishing site just needs to obtain a regular certificate for that domain. Of course requesting such a certificate may fail as a computer or a human may be triggered by the likeliness to google.com. But otherwise any owner of a domain can create a key pair and send a certificate request to any commercial CA. Note that registering has the nasty side effect of making yourself known to the CA.

It's not possible to use the orginal google.com certificate. The certificate contains the information about the site / site owner, the issuing CA and the public key. You would need the private key as well to use the google.com certificate.

The problem with certificates issued to rogue parties occurs during man-in-the-middle attacks where the communication can be routed to another computer. In that case the attacker can choose to intercept, read and change traffic to e.g. google.com. The attacker may also impersonate the server or anything in between.

In the case of google.com the Iranian government was involved. As it controls (most of) the infrastructure of Iran's internet the routing to another computer is easy. More close to home (for most of us), attackers can also setup rogue WiFi access points and use that to route traffic.

Note that plain DNS doesn't contain security measures, so anybody controlling the network also controls the way that IP addresses are mapped to names and vice versa.