What to do when I find a possible security vulnerability of public interest?

It would be a matter of opinion on how you should proceed. We already have a question explaining different ethical ways to report a vulnerability.

First off, for something this big I would personally recommend you remain anonymous at first, while leaving a way to later prove it was indeed you who discovered the vulnerability. Create a brand new PGP key (not tied to your identity), sign your messages with it and publish them anonymously (over Tor for example). If you later feel confident everything's fine and there are no hundreds of blood thirsty lawyers coming after you, you can use that key to sign a message saying that it was you (with your full name).

I recommend the responsible disclosure approach : you get in touch with the developers of said security system and leave them some time to deploy a patch.

Should you get no response, a stupid response or even hordes of angry lawyers barking at you, just use your anonymity to go public and let everyone know how that company deals with security flaws.

I disagree on the fact that disclosing a flaw while not providing an alternative is a bad idea. That flaw may already be known to the bad guys and it's better that everyone knows about it (and can at least know it's not secure) rather than letting the bad guys quitely enjoy using that information. Also, even if there is no alternative now, this discovery may motivate someone to actually make a secure alternative.

Finally, while I do not know what kind of "security system" we're talking about, security should be done in layers and any corporation which relies on that system as its only defense deserves to go down, just like those who don't bother to update once a fix becomes available.


What are the features of Dual EC DRBG that are lost when using a different cipher?

A PRNG which lacks reseeding, prediction resistance, or whatever these people mean by "continuous testing", is not a PRNG. Not in cryptographic terms.

Conversely, a good PRNG, like HMAC_DRBG, will be as good as Dual_EC_DRBG, actually better since Dual_EC_DRBG exhibits measurable biases, and is awfully slow. The only good point of Dual_EC_DRBG is the potential for a security proof which would demonstrate that the output is as random as a given number-theoretic problem is hard; but no such proof is known yet...

Here, by Dual_EC_DRBG, I mean a fixed Dual_EC_DRBG, with the two "random" points replaced by two points really generated randomly, not with the probable backdoor of the two standard points. But even "fixed", it would still be slow and biased.

The article you link to quotes the chief technical officer from RSA Security, who lists some advantages of Dual_EC_DRBG over "other algorithms". Without stating which algorithms Dual_EC_DRBG is compared with, these statements are vacuous. NIST themselves would feel quite offended at the suggestion that Hash_DRBG and HMAC_DRBG don't have the same features.


How can hackers guess passwords (using dictionary attack or brute force) without being locked out?

Account lockout is an effective rate limiting measure against brute forcing logins when the attacker is targeting one particular account. It is not effective against a bulk attack across many accounts. One could, for example, try all possible usernames whilst trying the same common password for all, and recover some proportion of the accounts.

Even CAPTCHA is only really a rate-limiting feature in the face of cracking and CAPTCHA-farmers.

  I know it happens because it happened to me.

It's not certain it happened due to brute force against the login interface. Apart from the mentioned phishing and trojan attacks, plus possible other web vulnerabilities like XSRF, Yahoo's database has definitely been compromised in the past (probably leaking hashes which are likely reversible for common and short password); plus if you used the password anywhere else then the other site could have been compromised. Yahoo have historically had a particularly poor reputation for account compromises which is likely a mixture of all these things.


You can look for strange USB device IDs with USBDview or USBView.

  USBDeview is a small utility that lists all USB devices that currently
  connected to your computer, as well as all USB devices that you
  previously used.  For each USB device, extended information is
  displayed: Device name/description, device type, serial number (for
  mass storage devices), the date/time that device was added, VendorID,
  ProductID, and more...  USBDeview also allows you to uninstall USB
  devices that you previously used, disconnect USB devices that are
  currently connected to your computer, as well as to disable and enable
  USB devices.

USB View is similar.

Other methods to defeat hardware key-loggers:

while typing sensitive information like passwords, after a few keys
of the password, use your mouse and point to a different location the
type some keys and then go back to the password field. This ways the
key logger doesn't know which keys are useful and which are not
use a password manager like LastPAss that fills in passwords
use a virtual on screen keyboard
use one time passwords or security tokens to make your passwords unique

usean on screen keyboard for sensitive data


This communication protocol is fairly weak as you do not provide authenticity or integrity. There are a number of attacks it is vulnerable to. The most severe ones I can think of based on what you said are:

Replay attack - A replay attack involves an attacker sending a copy of any part of encrypted data. The recipient will not be aware that the message is a replay of a previous message. The attacker does not need to know the contents of the message to pull off this attack.
Malleability attack - You didn't mention what mode of operation you were using. Assuming it is CTR or CBC, an attacker will be able to modify the ciphertext to change the plaintext in predictable ways. The only solution to this is to use an integrity construct such as an HMAC.
Man-in-the-middle attack - An MITM attack is possible as Diffie-Hellman is unauthenticated. To provide authentication, you would need to use an additional keypair such as RSA or DSA. The DH key exchange must be signed by these keys in order to ensure authenticity. The fingerprints of the private signing keys can be exchanged separately, or exchanged and stored so all subsequent connections are using it (a technique called TOFU, or Trust-On-First-Use).
Semantic insecurity - If you are using ECB mode (or incorrectly using CBC mode, or a mode not designed for this purpose such as XTS), encryptions of the same plaintext has the potential to result in leaking information through duplications visible in the ciphertext.
Metadata leakage - The length of messages of text gives away a surprising amount of valuable information. Unless you are padding your messages to a specific length, or at least padding them up to a multiple, you are allowing an attacker to learn information about the conversation based on the length of the ciphertext. Padding in this context is unrelated to padding in cryptography.

As you can see, there are a lot of variables that come into play when writing a cryptosystem. Real cryptographic protocols are quite complex. This complexity is absolutely necessary for mitigating a variety of common and not-so-common attacks. As you asked for a 0-10 rating scale, I would give this protocol around a 3. If you use ECB mode or you generate AES keys improperly (e.g. using a poor PRNG), it would be even lower. If you want to write an application that does encrypted chat, I would suggest using the OTR library, called libotr. The library provides secure end-to-end encrypted communication and repudiation (plausible deniability in regards to message contents), and more.


I don't really understand what you are saying, but I will try to understand/explain a few things.

First of all, the secure flag in cookie means that this cookie value will only be send when site is accessed via HTTPS connection.

Secondly, cookies are domain and path based so they won't be send to another domain, or path.

The attack that you're describing is known as CSRF Login attack, largely neglected/underestimated and marked as small risk little impact attack (imho falsely). You can read more in: "Robust Defenses for Cross-Site Request Forgery"

And finally If attacker is able to mount MITM with HTTP there is very little we can do and nothing will be as secure as HTTPS. So I will agree with you, to be secure sites should be full HTTPS only or not at all. Also as an additional measure web browsers could prevent overriding a secure cookie form HTTP response.


Is it safe to share a TLS Master Secret?

The (Pre-)Master-Secret is unique per TLS session. If you want a third party to be able to decrypt a specific pcap with this TLS session but not anything else it is safe to give the party this secret, as long as the session is not reused anywhere else.

Note that a TLS session can span multiple TCP connections. To make sure that the session will not be reused anymore by the client it is usually enough to close the client, i.e. the client usually does not preserve session information over restarts. But you should also make sure that the third party has no access to other data captures from the same TLS session apart from the ones they are explicitly allowed to analyze.

Since a TLS session is always between a specific client and target you don't have to worry about the TLS session reused between the same target and another client or between the same client and another target. But "target" does not necessarily mean a single server - it is not uncommon that a domain has multiple servers and that these share TLS session information.


Would cookie always change when browser changes?

Browser cookies contain only what the server sends to your browser.

If the server can tell that you're the same user using multiple browsers, then the server can send the same cookies to each of your browsers.

I suspect that you're asking about session cookies.  Most well configured servers will send a completely unique session ID each time a new session is started, and browsers will delete session cookies when they are closed.

There is no technical requirement that a server send a unique session ID in its cookies; nothing except decent security, reasonable session handling defaults on the web-platform's part, and common sense enforces this behavior on the server.


If a client is connecting to a different domain, then it's a different SSL session, regardless of whether or not it's the same key. Since the domain is different, there's no guarantee as to whether its the same server or not, so a different connection is required.

If you want to re-use the connection, then don't close the connection. If this is HTTP (you didn't specify) than you can do this using keep-alive, but typically only if you're using the same domain.


HTTP Request Smuggling is the attack used to steal cookies and other traffic-based credentials over a vulnerable configured server.
Attack vectors of HTTP Request Smuggling: (Use the Burp Suite for the following)

Parameters in the request. 2 parameters, Content-Length and Transfer-Encoding matter as the surface of this attack. If they both are present in the same request, it's likely that the request is dealing with the front-end and back-end server for parsing.

Also, the Transfer-Encoding parameter should be in a chunked state, this means that more than 1 servers are present on the other side. If another user is requesting the server at the same time, the request will randomly choose either front or back end server for processing on either of the parameters.

HTTP Request Smuggling is rated 7~8.9 in the criticality rate and can be considered a severe vulnerability. It should be included in a POC and is legal, unless the company does not provide the consent to you for testing their systems. POCs should either be provided on platforms like HackerOne or BugCrowd, or should be mailed to the security team with a private YouTube video describing it.
HTTP Request Smuggling can be chained with other tier-1 CDN-related attacks like cookie hijacking or sometimes a SSRF in case of a misconfigured server, token entropy or vulnerable headers.
For the CL;TE headers being, when you use an additional body in the request, the front-end and back-end server parse the body accordingly to the headers passed.
For example, if the following request is passed:
Content-Length: 13
Transfer-Encoding: chunked

0
EXPLOITS

The front-end server is accepting the Content-Length header, thus it will parse out the EXPLOITS string and send the request to the back-end server. The back-end server will parse out 0 first and since it indicates 0 bytes, it will not process the request body beneath it as the parsing will stop. So, the EXPLOITS string will be unprocessed till a new request arrives and will process it including the new request and will give out the response to the new request.
The headers can be obfuscated in a number of ways, like
Transfer-Encoding: xchunked

Transfer-Encoding
: chunked

Any obfuscation you can play with until you get the response in the repeater tab of Burp Suite resulting either a time delay or unexpected content. You can also send 2 quick succession queries to the server for confirming the vulnerability.
Hope this helps!


Is it possible to exploit IOT devices with Usb 'RubberDucky'?

In summary: most devices will probably be not exploitable this way but given the infinite wisdom of IoT developers I'm pretty sure they will come up with devices where this is possible.

There is a variety of IoT devices out there, especially since there is no stringent definition of what an IoT device is at all. Some of these devices will probably also accept both USB keyboard and USB storage. And in some of these devices the user might also do harm by entering specific stuff on the keyboard. This ability might be by design or it might be a debugging capability which was left in production code. With such devices BadUSB can work too since it relies on the idea that plugs in an USB stick which looks like a storage but behaves like a keyboard.


How does the PIN work in the RSA SecurID phone app?

The phone app has an algorithm to generate a new 6 digit random number every 60 seconds. Your PIN is simply added to that number without carry.  If you want to see the random number, just enter nothing for the PIN (or all zeros).
For example if the random number is 334455 and your PIN is 781923, then the resulting code will be 015378.
because
3 + 7 = 0  (throw away the carry)
3 + 8 = 1  (throw away the carry)
4 + 1 = 5
4 + 9 = 3  (throw away the carry)
5 + 2 = 7
5 + 3 = 8

I don't see how this information would be ever useful, but it seemed interesting.


How Have SQL Injections Evolved? (Specific Question + Open Discussion)

Your question is quite broad, but I think it can be boiled down to:

  Have SQL Injections changed with PHPs change from mysql to mysqli (because of missing stacked query support)

The answer: No, they haven't. mysql also does not support stacked queries.

Regarding the limitations of not having stacked queries: Apart from UNION-based injections, you still have error based and blind injections with subqueries, which don't necessarily require UNION (see eg here; there are other bypasses in case UNION is actually filtered out, but that's another question). You are stuck with the type of query you are in (SELECT, UPDATE, DELETE, etc), but apart from that, you have a lot of possibilities (but again, this seems like another question).


How secure are encrypted USB sticks really?

There is no reason it isn't possible to build a secure USB stick that actually requires password entry to decrypt which isn't present on the stick.  Short of putting a keypad on the actual device though, there is always the possibility of logging the password when connected to an insecure system (and even with a keypad, an insecure system could tamper with any partition that is opened up to it.)

Whether any particular USB stick fits this though depends on that particular USB stick manufacturer's design.  There are certainly plenty of ill conceived security products available.


How to handle credit card information on my server

I ran e-commerce sites for many years, and worked with many credit card processors.  I'll give you my go-to answer when someone wanted to use a processor that required the CC data to arrive at our server before going to the processor:

We refused and found another processor.

That's probably not the answer you are looking for.  However, credit card processors are a dime-a-dozen these days, and there are many who have APIs that actively encourage good security practices.  As a result, you're looking at this the wrong way.  Don't try to figure out how to secure this process. Just avoid it all together.  I rarely had customers that had high enough sales volumes online to get meaningful discounts from any processors, so even if you get a processor just for your website, do it.  You can always go sign up with Stripe.  They have amazing documentation, a great API designed around security-first, and their pricing is reasonable.

Just don't do it.  It doesn't even matter what the PCI compliance rules say.  There is no reason to go with a processor that force you to expose sensitive user data in this way.


I would suggest only installing these programs in a clean Virtual Machine(VM) you only use while on the school network.  Additionally only allow this VM to connect to the network not your host which presumably has personal data on it.

Refer to: https://superuser.com/questions/413050/can-i-pass-internet-connection-on-to-a-virtual-machine-but-forbid-it-on-host


Is there any advantage to combining a hash algorithm with a key-derivation function?

From looking at its specification, the first step of the argon2 algorithm is to hash the password with the BLAKE2b hash function. Therefore, it is useless to first hash the password with SHA2 before passing it to argon2id.


Security reasons for kicking user when logged in from two places

From the perspective of a developer who recently has to implement such a feature, another possibility is to prevent the users shooting themselves in the feet.

Many custom/internal applications have very specific workflows and store a lot of state in the session. If the user abandoned some work halfway on one computer, finishes it somewhere else and return to the original computer, he/she may get confused about the unifinished work. If the user incorrectly chose to continue, then the original results may be overwritten / duplicated.

It is of course possible to improve the code to make this less likely, but for an internal app, the most cost effective way is to prevent concurrent logins.


Why do we need DKIM to be used along with S/Mime?

S/MIME and DKIM are totally independent from each other. S/MIME signature and encryption is applied by the sender (end user) while DKIM signatures are applied by the mail server of the senders domain. Similar DKIM is usually verified by the mail server of the receiving domain while S/MIME signature and encryption are verified by the final recipient - the recipients mail server usually has not the necessary information anyway.

Additionally DKIM (in connection with DMARC) is used to detect spoofing of the senders domain only, while S/MIME signatures are used to verify the actual sender and not only the domain. And S/MIME offers encryption while DKIM does not.

It is true that a valid S/MIME signature provides a stronger proof of the sender than a DKIM signature. But there is no actual harm in using DKIM in addition to S/MIME.


Sessions implemented through cookies over HTTPS

TL;DR: HTTPS prevents both cookie tampering and also cookie stealing and replaying by a man in the middle.

First, HTTPS not only encrypts the cookie but the whole traffic. And, due to the way the encryption is done (random IV and also different encryption key for each TLS session) encrypting the same plain data always results in different encrypted data. This means that an attacker will always see different encrypted data where the cookie is transferred. Also, replaying any encrypted data later will only result in a decryption error.

Note that there are attacks which make use of side channels (size of compressed data) to extract cookies. See Current State of BREACH (GZIP SSL Attack)? and others for more information.


Taxonomy of Ciphers/MACs/Kex available in SSH?

An alternative response to the above is that if you're worried about security then focusing on algorithms is largely irrelevant, because where you'll get 0wned is through an implementation bug in your SSH server, not through anyone attacking the crypto.  In particular if you're doing something like VPN'ing home from DEFCON then you need to defend against metasploit, not a DES-cracker.  You could use the weakest algorithm that SSH normally supports, single DES, and be perfectly safe, because what's going to get you is an 0day in OpenSSH or, if you're not running the latest version, simply that.  So you're really asking the wrong question, pretty much any algorithm will keep you secure, it's the implementation bugs where they'll catch you.


Do Cipher Suites matter under attack using sslsqueeze tool?

If cipher suites really matter, does it mean that attacker can specify certain cipher suite for handshake to make the attack more likely to succeed?

Conceptually yes, though not with sslsqueeze. It is a simple tool that seems to be hardcoded to establish SSL and TLS connections with RSA key exchange (I've briefly read the code, a deeper analysis might reveal otherwise).

https://github.com/mmgaggle/sslsqueeze/blob/master/sslsqueeze.c

There will be variations across different servers since RSA since different key sizes will significantly affect computational requirements.


google states connection is encrypted. Should I change that?

What this means is that when you send a search query to Google, the query and the response will travel between your machine and Google's server under the protection of SSL/TLS, the well-known security protocol which is the basis for HTTPS (you know, the URL which result in that padlock icon to appear). In this particular case, the cipher suite will be TLS_ECDHE_RSA_WITH_RC4_128_SHA, as specified in this standard.

That's fine. Don't worry about it. If some evil people are interested in knowing what terms you search for, and try to spy on the network between your house and Google's machines, then they won't be able to get useful data. (Of course, Google itself will know everything, since SSL is only for transport, between two machines; but that's Google. Resistance to Google is futile.)


What are the columns in Firefox's SiteSecurityServiceState.txt?

1507520108719,1,1

The first number is the expiry timestamp in milliseconds. Divide by 1000 to get a normal unix timestamp.

The second one is the HSTS state, which can be "unset" (0), "set" (1) or "knockout" (2, overrides HSTS preload information as "no HSTS information available").

The third one indicates whether subdomains are included or not.

Source: https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#50


File encryption based on directory table

This is not encryption. The data on the disk would remain unchanged. An attacker can easily find data, e.g. by pieces of text for plain text files, by headers of binary files.

To you question Can this idea be implemented in practice? You can implement everything you want. You just should understand that it is not quite resistant against attacks.


How do I upgrade the encryption on my IIS-exported pfx file?

Openssl can also be used to upgrade the encryption, by creating a new pfx file with the same certificate and private key, but seems to require a multi-step process

First read the pfx file and export it as a pem file:

openssl pkcs12 -in badcert.pfx -passin pass:SECRETPASSWORD -nodes -out temp.pem

Second read the pem file and export it as a pfx file with upgraded encryption. I included the -macalg sha256 option here, though I can't prove that it is doing anything:

openssl pkcs12 -export -in temp.pem -out goodcert.pfx -descert -passout pass:SECRETPASSWORD -macalg sha256

Verify that the new pfx file has good (or at least better) encryption:

openssl pkcs12 -info -in goodcert.pfx -noout -passin pass:SECRETPASSWORD

Delete the old files:

rm temp.pem
rm badcert.pfx

Note that although openssl reports password-based encryption with SHA-1, it is actually the PBKDF2 variant of iterated SHA-1, per RFC7292, so this is not a weakness.


VPN Shared IP and wrongful attribution of traffic correlation of the encrypted packets by Feds/LEA

There's a mistake in your reasoning. While you share IPs, you have a unique IP:port combo, and Google certainly records this. This can and has been used to identify individuals behind shared IPs. It's a myth that a shared IP provides better anonymity.

The source port is necessarily sent with the IP address in order for the target website to know how to respond. This is how the concept of NAT, a way to put multiple IP addresses behind a single IP address, works. Otherwise, how could the VPN possibly know which IP address to forward a reply from a website to?

Please remember that VPNs are not meant for anonymity. The internal IP address is what "private" refers to in VPN, so it has nothing to do with "right to privacy", despite what the ads say.


How long would it take to brute force an 11 character single-case alphanumeric password?

The speed of WPA2, and the speed of modern GPUs, are essential to this answer.

A reasonable prosumer-sized (~US$5K) GPU cracking rig with 6 GTX 1080s can try around 2 million hashes per second - but there are 36^11 candidates to try!

For demo purposes, this is an actual attack, using the example WPA2 hash from the hashcat website:

$ hashcat -a 3 -m 2500 -2 ?u?d hashcat-wpa2.hccapx ?2?2?2?2?2?2?2?2?2?2?2
hashcat (v4.1.0) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #6: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU

[...]

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA/WPA2
Hash.Target......: 8381533406003807685881523 (AP:ae:f5:0f:22:80:1c STA:98:7b:dc:f9:f9:50)
Time.Started.....: Tue Apr 24 06:51:26 2018 (54 secs)
Time.Estimated...: Sun Oct 11 02:45:49 4105 (2087 years, 168 days)
Guess.Mask.......: ?2?2?2?2?2?2?2?2?2?2?2 [11]
Guess.Charset....: -1 Undefined, -2 ?u?d, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   336.2 kH/s (6.89ms)
Speed.Dev.#2.....:   330.8 kH/s (7.03ms)
Speed.Dev.#3.....:   332.0 kH/s (6.96ms)
Speed.Dev.#4.....:   331.1 kH/s (6.97ms)
Speed.Dev.#5.....:   334.2 kH/s (6.90ms)
Speed.Dev.#6.....:   333.8 kH/s (6.90ms)
Speed.Dev.#*.....:  1998.0 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 108544000/131621703842267136 (0.00%)
Rejected.........: 0/108544000 (0.00%)
Restore.Point....: 2539520/3656158440062976 (0.00%)
Candidates.#1....: 82TCFESS123 -> 8MXVZONANDA
Candidates.#2....: 9JGXQW12345 -> 9O3QWESS123
Candidates.#3....: 9BBZPANANDA -> 93M1YONANDA
Candidates.#4....: 96RCZONANDA -> 9WMXQW12345
Candidates.#5....: 5S3O3123456 -> 59QC6678999
Candidates.#6....: 40QC6678999 -> 4CUZPANANDA

But don't feel too reassured by the "2087 years" estimate. Fixed passwords often do not require brute force to be cracked. Many permanently fixed WPA2 passphrases are algorithmically generated, and many of those algorithms are either known, or discoverable by reverse-engineering the device's firmware.


What information to provide when submitting a vulnerability report to a bounty program?

ZDI, and other similar programs WILL NOT accept anything without reporting on the full vulnerability. There is no sanitizing data. You either trust them, or you don't. Sample applies for all programs listed on BugCrowd. With ZDI, this is what I found has worked best to minimize the amount of time you'd need to wait:

Full detailed report of the bug
Proof of concept
Troubleshooting (step by step guide to exploit including debugging)

What ZDI and others do, is take a look at what you're submitting, and go through the process of validating this. The Proof of Concept is not required, since their staff can make their own PoCs but it minimizes the amount of time spent waiting.

Troubleshooting output (e.g., WinDBG, OllyDBG, ImmunityDBG) helps them in seeing what is affected (EIP, EBX, ECX, etc) when something is overflowed for example. It isolates address space, or illustrates what you did for something like nopsledding, etc.

Now I infer that you're concerned that you will submit something, they will offer minimal, you'll say forget it, and they will go ahead and report it/fix it/etc it anyway. This is not the case hence you signing a non-disclosure agreement with them. So again:

Vulnerability - needed to determine the extent of potential damage if
X occurred
PoC - not necessary but helps proving exploitation against an
application
Debugging/troubleshooting data - aides in illustrating what, how, and
why something got exploited

There is no "partial" submission since they will be spending MONEY (time, resources) to figure out what the issue (if any is). Not chance any theories. The amount of money they offer, is based on how widespread the application is in use (e.g., Microsoft exploits command big bucks versus say MyRandomApplication.exe).


Brute force password cracking with a GPU

How are GPU's provisioned for password cracking? Do all, if not most cracking programs have special GPU aware software or do they just function at the basic driver or API level of the device?
Can it be as simple as plugging in a video card and installing a driver?

No, it is definitely not that simple. The password cracking application has to be written with GPU support in mind, either using CUDA (if you are using an Nvidia card), or OpenCL.
However, many of the popular password cracking applications has already done this. For example, John the Ripper has GPU support. Another popular password cracking application known for GPU support is oclHashcat.

Also, I have access to a lot of processing power from ASICs chips(+10 TeraHash/s) from bitcoin miners. I know they can only calculate based off of sha256, but can those chips ever be easily converted for cracking? If so, I would imagine the bitcoin gold rush of our era has made anything with sha256 obsolete.

For this particular question, I will refer you to an answer on our sister Bitcoin site.


privacy - Which parts of URL is protected by HTTPS?

Your ISP and your DNS provider are able to see that you are connecting to subdomain.domain.com, but neither are able to see the entire URL that you are requesting.

The first thing that happens is that your DNS provider will see that you are requesting the IP address that subdomain.domain.com points to.  So, if you are using your ISP's DNS service, your ISP will see that.

Next, your ISP will then see that you are connecting to the web server at the IP address that subdomain.domain.com points to.

Neither your ISP nor your DNS provider will see the entire URL that you are pointing your browser to.  The entire URL is sent to the web server only after the SSL/TLS connection to subdomain.domain.com is established.

Note:  Even if you use a DNS service other than your ISP's, your ISP is still likely to be able to determine the hostname (but not the entire URL) of the web server that you are connecting to.  Many IP addresses used by web servers reverse to the same hostname that forwards to this IP, so your ISP could conceivably do a reverse DNS lookup (for the PTR record) of the IP address that it sees that you are connecting to, and this would reveal the hostname associated with this IP address (subdomain.domain.com).  In cases where one web server is hosting many SSL web sites on the same IP, (which can be done if the web server is running SNI), your ISP could still be able to see the hostname that you are connecting to, because this is transmitted from your web browser to the server in clear text before the SSL/TLS handshake.


What is the difference between a payload and shellcode?

When exploiting an application, the payload is the code that the attacker actually wants to execute. It's the part that not just serves the purpose of leveraging the vulnerability itself, but does whatever the attacker considers useful.

When choosing a payload, an attacker typically wants code that starts them a shell. A shell is the program you interact with on the command line to control your OS (on Linux you might be familiar with the Bourne shell or Bash).

A payload that starts a shell is referred to as shellcode. But note that you will eventually find payloads that don't start a shell sloppily called shellcode, too.

A bind shell is a program that binds itself to a port and listens for incoming connections. Since opening a port attracts attention and because the attacker might often not be able to reach the port from outside the network, there is an opposite concept: A reverse shell doesn't wait for incoming connections but connects to a specified address and port itself. That is, the attacker waits for an incoming connection by the compromised server instead of initiating the connection themself.


How dangerous are worm:win32/Goldrv!rfn and worm:win32/vbjk?

Worm:Win32/Goldrv!rfn is a trojan that installs
Win32/Rootkit.Agent.HU malware.

Installation:
The trojan does not create any copies of itself.

The trojan creates the following files:
%windir%\system32\drivers\symavc32.sys
                      (167936 B, Win32/Rootkit.Agent.HU)
%temp%\_it.bat

Installs the following system drivers (path, name):
%windir%\system32\drivers\symavc32.sys, symavc32

The trojan executes the following files:
%temp%\_it.bat

The trojan deletes the original file.

The trojan may delete the following folders:
%currentfolder%


Does Tor help us to prevent ISP tracking?

You cannot hide how much data you are sending and when you are online. But, Tor encrypts data and sends it through proxies before it reaches the target server, so that hides the contents of the communication and to which website or server you are talking. You can also try to hide that you are using Tor, but this is difficult and a determined ISP will be able to determine that you are using Tor.

The first proxy will decrypt the outer layer of encryption and send it on to a middle proxy. The middle proxy does the same and sends it onto the final proxy. The final proxy finally decrypts your original request, so be aware that they can see the contents of what you are sending and to which website or server it is being sent. But they don't know that it came from you.

Note that, while the final proxy can see the contents, if you use "https" then the contents are still encrypted. I would not do internet banking over Tor unless you know very well what you should be checking (IDN homoglyph attacks, the certificate, perhaps other things), but generally speaking: https encrypts your communication. They can still see which website you are talking to, though, since contents encryption does not hide routing information (the page request, form data, etc. still needs to get to the right website).

See also the top hit on duckduckgo for "tor isp tracking": Does my ISP know what sites I have visited if I am using Tor?


Can an indie apps developer get fined if they unintentionally didn't protect users' data from hackers?

First of all, don't trust any legal advice from a Q&A site on the internet. I am not a lawyer, but I can give you some pointers at least:

It mostly depends on your place of jurisdiction. Laws are quite diverse in regards to liability when it comes to cyber security. You should consult with a legal expert familiar with software liability in your place of jurisdiction.
Data security is just part of the game. Getting hacked and having personal information leaked is a severe issue, but not the only one. Your systems can be compromised and used to attack others or spread malware / illegal material. Your users may incur damage if the system is not available during a DDoS attack. The list goes on. Do not consider your application secure, just because you followed all the data protection standards.
You have a degree of freedom when defining your contracts. Again, it depends on your local jurisdiction, but usually you can define for which use cases or industries in general your software should and shouldn't be used. You can basically say, that you are not liable for anything and that your software is not fit for any purpose. Your clients won't like that, but it is an option. The goal is to find a middle ground that works for all sides. Don't include any liabilities in your contracts that you are not comfortable with. Again, this is a difficult matter, get a legal consultant.
Get a software security expert on your team. You said it yourself, you're a beginner in the field of information security. Relying on standards and security frameworks only gets you so far. Without a competent partner to manage your application security, you run a high risk. If it is a small development project and you have limited funding, get a security consultant for a limited amount of time to cover the most important topics. If you can afford it, bring an expert into your team. A security savvy developer can help not only with security but other development tasks as well.
About security standards... Honestly, based on your description, no security standard alone will do the trick. Application security is a field that requires many years of experience to get things right, and even then it is difficult. I could list a wide range of different security standards from OWASP, NIST and many others, but the standards are not your issue. That's probably not the answer you were hoping for, but my honest opinion about your situation.


For the quick answer: use synproxy (as offered by BSD's pf for instance), or a reverse proxy like Nginx if you have an Apache directly facing Internet.

Real DDoS issues would merely come from actual IP address owned by botnets than faked IP address. However, some application remains indeed sensible to fake SYN packet, but this is merely an application issue exploitable by a single host (aka DoS with a single 'D') than a DDoS

Why? Thank to TCP 3 way handshake:

The client sends a SYN packet,
The servers answer with a SYN-ACK packet,
The client answers back with a ACK packet,
Then at last the TCP connection is established and the HTTP request (for instance) can be sent from the client to the server.

What invalidates forged IP address is that each host selects a random sequence in this handshake, and for the connection to be established client's final ACK must show the two sequence number validly incremented.

When you use a forged IP address for your SYN request, by definition you will never receive the server's SYN-ACK, therefore you will never now the random sequence number he selected, so you will never be able to complete the TCP handshake.

So, when you use a forged IP address, the only "harm" you may do is send fake SYN requests to the server, which should require very low resources on server side, and which will indeed require negligible resource if the server or its firewall is using above mentioned synproxy (with this option enable, the connection will be forwarded to the listening service only when the 3-way handshake has been successfully executed).

If you do not use synproxy, depending on the way your service is implemented a SYN packet may involve more or less resource. The issue with Apache server is that it already forks to a new process upon SYN packet reception, so you need either to protect it using specific measures (adding Nginx which uses another implementation not sensible to such issue), or configure your firewall to mitigate the risk (reduce the number of ongoing TCP handshakes, reduce the handshake delay, etc., but unlike previous solutions this one may have an impact on legitimate clients).


Potential False Positive while scanning a network with Nexpose - X509 Certificate mismatch

If you intend to access your site via (e.g.) IP 192.168.1.1 then you will need to have that same IP in the certificate.

Namely inside the "Common Name" and/or "Subject Alternate Name" sections.

Otherwise it will not be valid to access via that IP.

But if you don't plan on ever accessing via that IP, then you don't need the IP inside the certificate. And you don't have to care about the scanner's warning either. -- The warning is the expected result in this case. (See this SSL scan for the IP of "example.com". It also has as a warning that reads "The certificate doesn't match hostname". And rightfully so, since the IP is not listed inside the cert.)


No
I'm not sure what you mean? You can't "break out" of document.title=AttackerString where AttackerString is a javascript variable with data (the string value) controlled by you.
Again, you can't exploit escape(AttackerString) but you can exploit something like <? echo 'escape("' .$_GET['AttackerString']. '");' ?> by simply bypass the javascript function: &AttackerString="); alert("xss in the case the html output would be: escape(""); alert("xss");


Is it worth verifying the request hostname in API-to-API communications?

Verifying the hostname does not provide you with any extra guarantee of authenticity. Assuming that, in addition to using a shared secret, the APIs are able to verify each other's private keys, then you get a pretty strong guarantee that they are who they say they are. Anyone who is able to steal said private keys to fully impersonate one of the hosts will be able to trivially alter the hostname.


Getting self-signed SSL certificates for all https connections made from some premises

1. What's going on here ?

Google.com does not use a self-signed certificate. Most probably all traffic is going through a ssl-aware proxy (there are commercial appliances that do this sort of job), which intercepts and handles HTTPS connections (in other words it performs a man-in-the-middle attack). It masquerades as google.com for example: If it serves you google.com under the original certificate it will not be able to see the traffic details of the encrypted connection, so it uses a self-signed certificate for the part from you to the proxy, decrypts the traffic, and then reencrypts it using google's correct certificate and forwards it to google.

2. Is there any risk in manually
    accepting these certificates ?

Are you doing or sending something you don't want whoever is operating the proxy to find out? If yes, there is.
The proxy operators can see and change everything - passwords, logins, credit card numbers, anything. What is happening here is that all your supposedly encrypted connections are in reality plaintext connections and have the same degree of security as them.

3. Is this also likely to be the reason
    why I can't access my company's
    Cisco VPN any more (I can ping the
    public VPN server address but the
    Cisco VPN client times out).

Yes, if it also intercepts VPN connections and tries to mitm them, you wouldn't be able to connect because the mutual authentication will fail.

Finally, I would suggest that you use this firefox extension: (called Perspectives) http://www.networknotary.org/index.html

It is made specifically to combat issues like that and others: It allows you to monitor if a site you visit often has changed it's certificate, so that you know that something fishy is going on.


Does using the client keep the Keybase server honest even if you also use the web interface?

The keybase client DOES NOT verify the integrity of the keybase server. The client can to some extent verify behavior of the server to make sure, it is not providing wrong information to clients. That only includes withholding data, for example not saying Alice revoked her key and therefore allowing the compromised key to be exploited. It does not help against the server stealing keys, metadata or any other compromise.

Also, it is important to note, that the server can still pretend to Alice that it is unavailable to prevent her from ever submitting her revocation. While Alice would detect this, no-one else would. Alice would have to inform everyone and somehow prove this, which may be difficult.


It sounds like you might need to tap one of the other major feature sets of hashcat: rules. Rules are ways to express common transformations that people make against base words to "complexify" them (changing case, reversing them, leet-ifying them, etc.).

To try a rules-based attack, see the ./rules/ subdirectory, and apply one or more rulesets using attack mode 0 (-a 0) and the -r flag.

The hashcat wiki also has a primer on rule-based attacks.


How is it possible that we can't really trace C&C(or other hidden) server?

This is because an infected device "talks" to hidden service through 6 different Tor nodes. All those machines do not track any routed traffic - and they cannot be configured to "track Wannacry traffic" because none of them know what exact traffic they route (it is encrypted end to end, so only the sender machine and Wannacry server can see the content). Also only the first machine in this chain knows which is the real IP of the sender, but it does not know that the sender is a hidden service.

So to trace a connection, theoretically you'd need to:

Build a circuit (establish a connection through rendezvous server) to a hidden service. This is easy.
Find out who is the first Tor node in your circuit, and talk to them to trace the next node in the chain. This is way more difficult - not only the node operator may be unreachable or skeptical (how could they know you're really tracing WannaCry, and not some underground resource), but will also require modifying the Tor client and inspect traffic - latter might also be illegal in some countries.
Repeat the same with the next five circuits. Which will likely be in different countries - different timezones, different languages and different ideas of what is acceptable and what is not.

Add to that that you need to do this within the circuit lifetime - which, as far as I remember is rather short, less than 30 minutes - and you see the problem.


I would like to throw in that the link provided by user ximaera omits some information.

Using a scan like this

nmap -T5 -n --max-parallelism=255 --min-parallelism=100 -sn 10.0.0.0/8

could trip up some security mechanisms, because it can look a bit like a ping flood and it does not necessarily offer an increase in speed.

I would suggest omitting the parallelism options and scanning like this

nmap -T5 -n -sn 10.0.0.0/8


Is using Tor and VPN combination more secure?

In theory yes, In practice maybe not but also yes at the same time.

If you were to use VPN and a tor network you remove one of the security layers in the tor network. tor uses relays and your path changes every time you use tor by using a VPN you would be using the same end point (assuming you went TOR -> VPN)

If you went VPN -> TOR, You would encrypt all of your traffic to your start point (The VPN Out interface) and then the TOR network would take over, the issue here comes with the VPN service its self, they could very easily see you are using the TOR network, this would be your weak spot you want to be under the radar with everything.

To make it secure you would need to buy an anonymous VPN and pay for it in bitcoins after rolling your bitcoins via a tumbler (depending how you obtain the bit coins will determine your weak spot in the chain, but the tumbler should fix most of that issue). To also secure the purchase make bitcoin transactions and VPN transaction VIA TOR.

then once you have the anonymous VPN you would not want to connect to your VPN from your home address (though anonymous VPNS hold no data so technically you shouldn't be able to be traced from your home address). then once connected to the VPN you can use the TOR network that way.

To summarise:

Using a VPN creates an issue with its self as to obtain the VPN you would use personal information. though any extra security would be nice as you mentioned the chain is only as strong as its weakest link. The VPN would be the weakest link with personal information following you back (using a free VPN would end up in records being kept of your activities).

Keeping data private is never the issue, its keeping the data disassociated from the owner. 01/01/1970 is someones birthdate, asking someones birthday can be a security question...sadly I dont know who this birthday belongs to, following?

Hopefully I kept mainly to the point in my answer.


Do RFID key cards track the user through entry ways?

Having specified and reviewed smart card and RFID card entry systems as part of PCI DSS audit I can confirm that the system can, and often does, track people as they move through locked locations in a site. This is normally to allow the fine grained control of which person (usually based on role) can access which areas of a building e.g. only a few people can access the server room (often with 2fa anyway), and certain people can access security offices where CCTV is monitored etc. etc. Many security policies require that entry/exit data is retained for audit purposes and therefore tracking is inherent in the system.


What is a DoS Attack and how does it differ from a DDoS attack?

A denial-of-service attack is a type of attack that causes legitimate users to be unable to use the service. These come in a few different categories:

Resource exhaustion (e.g. consuming all network bandwidth, or server CPU time)
Limitation exploitation (e.g. locking a user out of their account by repeatedly attempting to log into it with invalid credentials)
Process disruption (e.g. crashing a process that serves user requests, via a bug in the software)
Data corruption (e.g. altering all user types to an invalid type, making it impossible for them to log in)
Physical disruption (e.g. pulling out the power cable on a server) - thanks to Henning for this one!

The most common type on webapps is a resource exhaustion, which is what most people tend to refer to as a DoS. These are caused by an attacker sending a large number of requests to the server, in order to exhaust one or more resources:

Network bandwidth may be entirely consumed by the attack, preventing legitimate user traffic from reaching the server.
Each request uses some CPU time, so a large number of requests may cause the CPU to spend all of its time dealing with attacker requests, instead of legitimate requests. Attackers can send expensive requests (e.g. full-text searches, SSL connections, etc.) to the server to increase the impact. There are also cases where vulnerabilities in the server software allow the attacker to craft special requests that eat a lot of CPU time.
A small amount of RAM is used for storing the connection state, which might allow for physical memory exhaustion if enough connections can be made. However, database queries can be very memory intensive, in terms of memory usage and memory bandwidth. If an attacker picks his queries well, he might be able to entirely exhaust the physical memory of the system.
Logs, database tables, etc. are stored on disk. Sending a huge number of queries over a period of time may exhaust the disk space on the server, causing it to crash.

Note that the requests don't need to be HTTP - they could be DNS, HTTPS, SSH, FTP, SMTP, POP, IMAP, SMB, etc. Any situation where a service is listening for incoming packets is a potential way to achieve a DoS.

There are two primary ways to achieve basic application-independant network DoS attacks: TCP SYN floods and UDP flood.

The TCP protocol involves a three-way handshake. First, a client sends a SYN (synchronise) request, to which the server responds with a SYN-ACK (synchronise acknowledged), which the client then finally responds to with an ACK (acknowledge). However, if a client sends a SYN and does not respond to the SYN-ACK, the server is left with a half-open connection. This consumes a small amount of memory within the operating system, and eats a few CPU cycles. Eventually the connection is dropped, but a flood of SYN packets can be enough to cause serious performance issues on the target. There are a number of ways to mitigate this threat, and the most notable is SYN cookies, which allow the server to send back a response without storing the SYN state.

The UDP protocol doesn't involve any form of handshake. Packets are simply sent between hosts, with no state or connection. This means that an attacker can send a large number of UDP packets to the server, consuming their bandwidth. This requires that the total bandwidth of the client exceeds that of the server. Since the client doesn't need any response, it can spoof the source IP address, making mitigation harder. These types of attack can be harder to block, and often require intervention by the service provider.

The problem for attackers is that servers are designed to cope with a large number of concurrent users, and small denial of service attacks. Sending a huge number of packets from their home network or a rented server is unlikely to cause a significant reduction in availability or response speed of their target. In order to make the attack more effective, they use a distributed denial of service (DDoS) attack. This involves using a number of computers on different networks to flood the site with requests. Often the attacker will infect other computers with malware, to form a botnet, which is then used to perform DoS attacks. The difference is that a DDoS allows traffic to flow from legitimate (but compromised) source IPs, increasing the effectiveness of the attack and making it harder to block.


Authenticate user based on mobile device identifier

If you can get the device ID, so can any malicious app
Think about it this way: would you want every other app on the player's phone to have the ability to send data to a centralized hub where they could then make fake web requests to your game on behalf of this user?
Now, sure, most of the apps on the user's phone aren't doing this, but do you really want to open that door?
If you want passwordless authentication and good security, you are probably better off going with a standard solution (Authy, maybe Authentiq, etc.).


How can a network be secured against attacks coming from the inside?

One of the easiest ways to protect against internal attacks is by isolation: in other words, having multiple sub-networks. For example, (this even works in a small home network), the wifi network might be 10.0.1.0/24, and there could be another internal network where the wired desktops and servers reside, perhaps call it 10.0.2.0/24. Now even if someone hacks into the wireless network they are constrained to computers in the 10.0.1.X space, and would be unable to access the desktops and servers. You could even have specific routes so that both networks can share a printer which is in one of the networks (or a third network), without exposing anything else.

As for sniffing wired traffic on the same network, this isn't an issue unless the network uses hubs rather than switches. With switches the traffic is only sent through the device ports of the recipient, so other devices cannot "sniff" that traffic. (That is an oversimplification but the general concept should be clear.) In order for someone to sniff traffic under normal circumstances, they would have to have admin access to a switch with promiscuous capabilities.

Note that with just these basic concepts, you don't really need to worry about encrypting wired traffic within an internal network, because it is already (generally) secure. This is why when you talk about encryption, it is usually within the context of traffic over the public internet.

Outside of those basics, it is difficult to go into more detail because this is a huge topic. But that should at least clarify your initial thoughts and get you on the right track.


Why are there questions about "media" in a PCI-DSS SAQ A?

Any entity should also protect paper documents that contain cardholder
  data in accordance with PCI DSS requirements 9.6 through 9.10. For
  example, requirement 9.6 states "Physically secure all paper and
  electronic media (including computers, electronic media, networking
  and communications hardware, telecommunication lines, paper receipts,
  paper reports, and faxes) that contain cardholder data."

What is cardholder data?

  Cardholder data (CD) is any personally identifiable information (PII)
  associated with a person who has a credit or debit card

So what is PII?

  Personally identifiable information (PII) is any data that could
  potentially identify a specific individual. Any information that can
  be used to distinguish one person from another and can be used for
  de-anonymizing anonymous data can be considered PII.

Consider receiving receipts with client information on it like addresses, names or other PII. That's the content they are targetting.


About the codification in your URL :"/~!@#$%^&()+~!@#$%^&()+~!@#$%^&*()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()_+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&*()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()+~!@#$%^&()_+~!@#$%^&()+~!@#$%^&()+~!@#$%^&*()_+/" I think that it is formed part of the path of the file suspected.

I think that this maybe is Phishing, I shearch the URL and finded this site:

https://urlquery.net/report/284aaf9f-1419-462f-86b3-392532e12237

It say that was report for a firewall because find a suspected trafic data.

You can test the host in virustotal for read the reports and have a major know of what happen and assurance if is malicious URL (the more probability is yes).


Portability of SED suppporting TCG Opal 2.0

Let me provide some extended details. I marked answer to your two questions with bold:

Most BIOS implementations support ATA Security feature set (also referred as ATA password or ATA Security Class 0) for SATA devices. If all that you need from SED is data encryption and locking with a single password then consider this option first.
MBR Shadowing feature allows host to unlock TCG Opal devices without any BIOS support. After power up device shows to host a special shadow PBA partition (Pre-Boot Authentication) instead of the original disk content. This partition contains code to unlock device and remove shadowing. BIOS loads this code and executes it (thinking that this is the actual OS). Only then the original disk content becomes visible and original boot loader is executed. Portability of such solution is lower because PBA code can't support all architectures (the sedutil you mentioned provides PBA image only for x86-compatible PCs and Macs) and can't unlock device after Sleep (S3 mode).
Shadow PBA works for Hibernation but it doesn't work for Sleep. Device is powered off in both cases, but BIOS loads system from scratch only for the first case. Device remains locked after waking up from Sleep and required TCG support from the OS or security application.
Code from shadow PBA partition does not manage the unlock password, it just provides a GUI to input it and to use it for authentication. The password (or usually its derivation) is managed by device firmware in a vendor-specific way.


How to implement secure device identification in a for-pay wifi router to prevent usage fraud?

The only way to accurately identify a specific client on a network would be with cryptography.   If each client had their own asymmetric key pair and you used a SSL VPN then it would be a lot easier to enforce resource usage rules.

Panopticlick would never work for this.  The browser signature will change because of updates or installing new plugins/languages/etc.  Not only that but this value is about as easy to spoof as a MAC Address,  just run Panopticlick on the victim's browser and then modify your system to match.  The bottom line is that software fingerprinting is too easy to fool and is error prone.

My gut feeling is that hardware fingerprinting is not the right path.  What if the attacker has identical hardware?  Macbooks are pretty popular these days.  Again this kind of fuzzy matching is error prone and could produce false positives/false negatives.


What are the security implications of a dead laptop?

If you have removed the hard drive and checked that no removable media was left in it, then none of your data can be found on it. (They will be able to see your BIOS settings, but that isn't considered sensitive data for a dead laptop.)

By the way, if you have an SD slot, make sure you check that too.


The traditional term for this sort of device is WORM drive, where WORM stands for "Write Once, Read Many."  A number of tape-like devices are still available and in use today.  More modern equivalents are DVD-R, CD-R, and specially protected Flash drives.  There are also vendors who have created magnetic (e.g., traditional disk drive) technologies which are write-only, such as GreenTec's WORMdisk.

EEPROM is unlikely to work for you because of the relatively small size and slow speeds.


What kind of attacks are mitigated by 2FA/MFA in Industry sector?

In our case, it was the human factor. You're lucky if the post-it with the password doesn't go right on the console. If it doesn't, everyone has the same password that everyone knows.

Staff gets annoyed by the need for a token, but they can't easily replicate it, so they're too worried about explaining how they lost theirs to just leave it around. Add a password that has to be changed and soon enough they run out of combinations so obvious that they could be guessed in three tries, and syncing their passwords is more trouble than doing things right.

On tokens vs tokenless, I'm strongly for tokens. Tokens come dirt cheap in a box from China, they work in buildings with phone jammers, don't get left elsewhere out of fear of damage, there's no battery concerns, and they end up stored alongside physical keys, which people always recognize as items to be protected. And there's something to be said for the personal interaction in handing one.

I don't see how you can separate real security control from the human factor. Security is all about minimizing the vulnerabilities from the human factor. Make it easier to comply with the rules than to work around them and you can get enough security that the system isn't wide open.

Source: Did SCADA.


What client-cert validation can be gleaned from DNS/reverse DNS lookup?

About meaningful information from reverse DNS: The short answer is no, not really.
About CLIENT certificates and SERVER certificates:
Normally when you use a X.509 certificate for client validation, the client (normally a web browser) will represent a CLIENT certificate to the HTTPS endpoint, much like the HTTPS endpoint will represent its own certificate to the client. The server can then choose to trust the client certificate based on if it is issued by a trusted authority for the server. This might be a certificate authority (CA) belonging to the organization that runs the server, or a CA that is commonly trusted by most devices.
What you seem to be doing is looking at the SERVER certificate at the HTTPS endpoint for the reverse DNS that the client IP address points to. This is normally not something that you would do. But for the sake of your question, I will continue down this path to provide you with what you can find:
Making sure a reverse DNS name can be trusted
First of all you must be aware of that a reverse DNS name can point to ANY DNS name that the owner of the IP would like to point it to.
In order to be able to trust the reverse DNS name of an IP address, you will also need to resolve the reverse DNS name to an IP address and compare it to the client IP to see if they match. If they do not, the name cannot be trusted.
Imposter example:
The owner of IP address 66.66.66.66 sets its reverse DNS name to yourbank.com. If you check the SSL sertificate at yourbank.com:443 it would probably be valid for yourbank.com. But yourbank.com and its valid certificate has nothing to do with the client. Resolving yourbank.com to an IP address will show that it points to another IP than the client IP, meaning that there is probably no relationship between the reverse DNS name and the client IP other than the reverse DNS name (PTR record) in the 66.66.66.66.in-addr.arpa DNS zone which is controlled by the owner of the IP address. The owner in control is usually the ISP or a company with static IP address(es) from their ISP).
Common valid examples:
If you have a client IP 11.22.33.44 that resolves to 44.33-pool.dyn.cable.someisp.net and the name 44.33-pool.dyn.cable.someisp.net resolves to 11.22.33.44 you know that the name is correct. This client might be a user connected by a cable modem with a router which probably do not have any open HTTPS endpoints.
If that client is running a website at their IP address, it would probably be for another name than 44.33-pool.dyn.cable.someisp.net. Maybe something like mypersonalwebsitethatirunfromhome.com.
For a client connecting from a business location the IP address might resolve to something like lan-gw.mainoffice.somecompany.com or static-77.88.other.isp.com. They might host a webserver at this IP, or they more likely have a subnet of more IP addresses and they have another IP address for their webserver.
Other client IPs might not have any reverse DNS names at all, or they can have a name that points to a different IP address than the client, but still be related, or they are a bot that crawls the internet for indexing or looking for exploitable vulnerabilities in the web servers. These bots might have IP addresses from a cloud based IaaS network like AWS. A good bot will present its name and maybe an URL for more information in the HTTP_USER_AGENT header.
Even if the client IP address is a dedicated webserver it would probably have a reverse DNS name in the format of web94.someisp.com. The server might host www.someisp.com and several other websites accessible at the HTTPS endpoint by providing other.websites.net in the SNI of the HTTPS request.
Final thoughts for looking into the reverse DNS name of a client:
If you are lucky, the reverse DNS of the client IP might actually point to a DNS name that is related to the client IP, which you confirm by resolving the DNS name back to its IP address and compare it to the client IP, and you can validate the certificate, but all it proves is that the client IP has a webserver running with a valid server certificate for the DNS name that the IP address points to in DNS. Note that the client that is connecting to your HTTPS endpoint might be a web browser in the network behind that public IP, or it might be some malicious activity from a compromised device in their network that is making the connection to your web server.
Back to actual validation of CLIENT certificates:
If you want to trust a client you must let the client prove its identity. This can be done by a client certificate installed in the actual client software (like in a certificate storage that the browser can access). The client will present this certificate when contacting the HTTPS endpoint on your server. This certificate must be created by a certificate authority that your web server trusts. The certificate can be installed in the client automatically from a central system for device management.
If you are not using a client certificate you will need to let the client identify itself by other means, like a username and password, or a valid authentication token that can be verified by the server.
Reply to Edit 1
What are your use case scenario here? Are you running a service that requires a certificate while you are willing to accept any publicly trusted certificate, but then restrict that access only if the client is related to a certain set of domain names?
Normally you would only trust client certificates from a certain certificate authority in order to have decent control of who can gain access to your service. If your goal is to provide access to anyone in the "somecompany.com" domain without ever having anything to do with the client certificate it might not be as easy as that.
If you want to provide the service to anyone with a public certificate you should only trust the data in the client certificate itself. As you already figured out, the CN field of the client certificate might be empty. Dealing with certificates with no verifiable domain name really has no other solution than making the client change their certificate, or whitelist that specific certificate.
The IP address of the client should not be used to approve access unless you know a specific set of IP addresses that you want to allow. An IP address only says something about what infrastructure the client is coming from. It doesn't prove that they are related. Accepting any connection based on the IP address alone poses a great security risk unless you know that you really can trust any connection from that IP, which also means that you need to trust all software and all hardware in the whole network of that IP.
The top level domain associated with the reverse DNS might not have anything to do with the IP address. Lets say I own an IP 1.2.3.4 and I point it to mydynamichost.dyndns.org, and using my account at DYN.com to point that hostname back to my IP address. That makes me connect from mydynamichost.dyndns.org, but I still don't own or operate on behalf of dyndns.org.
In your example where Bob connects with a certificate for bob.com, it would be just as likely that he is connecting from an IP that has a pointer for the hostname 101.102.103.104.bob.net, breaking the relationship between his domain identity and network identity.

What checks can I perform on the IP address that would increase security?

You can check if the IP address is listed in any blacklist databases. You should probably reject requests from an IP address that is exceeding a certain threshold in a certain time that would be outside of normal activity.

I can't tell whether checking the request IP against the IP resolved from DNS lookup would be useful 100% of the time OR
Whether I should check the request IP against the reverse DNS lookup results.

I am not sure if I understand the differences between your option a or b here. I am sure of that you should NEVER trust the reverse DNS name unless the reverse DNS name can also be resolved to the IP address of the client. I am sure that an IP address will not always have a reverse DNS name. Sometimes it might even have more than one name. The name may or may not be related to the client, but at least the client IP is listed in the DNS zone for the domain if you can resolve IP to hostname, and hostname back to the same IP.
I would still not say that it would be recommended to use the reverse DNS name or the IP address of the client for doing client authentication.
Ping me again if you need further clarification.


Would there be a secure way to store an encryption key on server side for front-end decryption?

First of all: stop developing until you can really understand encryption, privacy, and the laws regarding medical data. If because of financial reasons you cannot have an expert to inspect and certify your solution, for financial reasons you should not develop it. The money spent on having a specialist helping you design and test is a few orders of magnitude less than the fines and image damage from an data leak event.

Second: don't store the entire database on the client. It won't scale, and you must design with scale on mind since day-0. If you design things that by design don't scale, that will bite you later. Hard.

If you want to continue this (for Science, or to learn), you will use Envelope Encryption (this IBM link have a nice explanation). It basically means that your client generates some data, encrypts it with a symmetric key, encrypts this key with his own key, and sends along the encrypted data plus encrypted key. The server stores the blob and does not have any knowledge of its contents.

When the client needs the data, it will receive the blob, extract the encrypted symmetric key, decrypts the key and uses it to decrypt the data.

How you create the user's secret key? You need a Key Derivation Function (KDF). The KDF will take the user's password, some other parameters, and generate a key. Every time you run the KDF with the same parameters, it will output the same key. It can be seen as a very specialized hash function: you always enter the same value, it always returns the same hash.

But what if the user wants to change his password? All data is lost? No, it's not. You must create an intermediary key, encrypt all DEKs with it, and encrypt this intermediary key with the user key. Store the encrypted intermediate key on the server. If the user wants to change its password, he will retrieve the encrypted intermediate key, decrypt it with his current key, change its password (and by consequence his secret key), re-encrypt the intermediate key with his new secret key, and store it back.

And what if the user forgets the key? Using Envelope Encryption, he is doomed. There's no way to recover it, unless you somehow store an unencrypted intermediate key (or encrypted by your own key), and break the entire security chain.

Yes, I know it's complicated. And my explanation was not the best, and there's a lot of possible gotchas on the implementation, but is a secure way. Read the Envelope Encryption implementation from IBM, from Google Cloud, from AWS, and so on.

And let your boss know that developing a secure service managing medical data without proper experience is asking for big trouble down the road.


Why is it possible to bypass Android full disk encryption?

You seem to be confusing two different security features that are intended to protect against two different types of attacks.
The three attacks you mentioned are to bypass the lock screen of the phone, and have nothing at all to do with encryption. They also only work in a specific set of circumstances.
Among other limitations:

The phone must be already booted up. In order to do anything useful, the phone's OS needs access to the disk and therefore it must have the decryption key loaded in memory. Several of these types of attacks will not usually work against a phone that has only just been booted up but not yet unlocked for the first time after booting.
The phone may have a bug. In your third example, bypassing the lock screen could only happen because someone made a mistake. Programmers are human too and they make mistakes. It sometimes happens that mistakes allow a security bypass.
You have chosen to deliberately reduce security. In order to use your first example, the device owner must have enabled debug mode. This is not an easy thing to do - there are deliberately multiple complex steps that must be taken to enable it. You also need to allow each specific computer to use ADB, so this attack can only be done from a computer that the phone was previously connected to. Or, in your second example, you as the device owner have deliberately enabled a bypass of your security, trading it for convenience in case you get locked out of your device.

So what does device encryption do for you?
Device encryption protects your data from being accessed from outside the OS.

An attacker cannot reboot your device into "recovery mode" or de-solder the flash chip from the motherboard to read your data.
Every time your phone is rebooted (not just turning off the screen; only a full reboot), you must unlock it once before any data can be accessed. This is because Android encrypts the disk encryption key using your password/PIN/pattern, and the OS cannot access your data until that first unlock. (One way you can see this easily is if you reboot your device, then leave it locked and have a friend call you. Even though the friend is in your contacts, the caller ID will only show their number, not their name, because their name is stored on the not-yet-unlocked encrypted storage.)

If you want to add another layer of protection, some Android devices will allow you to add a password to the disk encryption. This adds an additional password prompt while the phone is booting up, and the phone will not boot until you have entered the password. However, unless you are afraid of nation-state level attacks against your phone and you plan to always keep your phone powered off and only turn it on when you need it, it is highly unlikely to be worth the trouble to set this password. (Again, remember the difference between disk encryption and the lock screen.)


Is a VirtualBox guest isolated from the host?

While there is isolation between the VM and the host this isolation is not perfect. Compared to using two different physical machines it is sufficient if the attacker can use a security issue in the hypervisor to escape out of the VM.
Such security issues are often in parts of the hypervisor where interaction between the VM host and the VM is done, i.e. emulated drivers etc. Guest additions also have such code, which means that they additionally increase the attack surface. Such vulnerabilities were found in the past, see for example 10 new VM escape vulnerabilities discovered in VirtualBox.


Is there a PAKE algorithm where the passwords can be tested in the first round?

No, since that would let passwords be tested without sending anything.

You could have the parties [do PAKE with the server] with

independent passwords and let the server be a key sever.

There probably exist protocols in which

Alice chooses a probability p in [0,1] and

even if the server knows the password, the server can't do non-negligibly better

at distinguishing different choices of p than just trying incorrect passwords

an incorrect password will have probability p of passing the honest-server's test

if [the server isn't separately given the password] then the server can't distinguish between

the real password and other passwords which pass the honest-server's test
.


Configuring SSL certificate on OS X 10.8.5 produces "Chain issues Contains anchor" error

"Anchor" here means trust anchor: nominally, the named-and-public-key which is known a priori by the SSL client, and used to validate the server's certificate. Traditionally, trust anchors are encoded as certificates, which is a kind of a stretch because a number of fields in a certificate do not make much sense for a trust anchor.

In particular, a certificate has a SubjectDN field and an IssuerDN field, the latter being equal to the SubjectDN of the certificate issuer. A trust anchor has no issuer, so when the trust anchor is encoded as a certificate, it is customary to set the IssuerDN to the same value as the SubjectDN (the certificate is then "self-issued"). This is what you observe; it is not a "duplicate". Similarly, a certificate is signed, so there is a signature field to be filled; trust anchors are then often self-signed. A trust anchor encoded as a self-issued, self-signed certificate is also known as a "trusted root", or "root certificate", or "root CA", or a few other terminology variants.

When the SSL server talks with the SSL client, the server sends its certificate as part of a chain, beginning with a trust anchor and ending on the server's certificate proper. Then the question is: should the trust anchor, assuming that it is encoded as a certificate, be sent as part of the chain ? Sending that certificate is useless, because if the client is to validate the chain, then it must already have it. Nevertheless, it is allowed to send the trust anchor. The standard says so:

  Because
        certificate validation requires that root keys be distributed
        independently, the self-signed certificate that specifies the root
        certificate authority MAY be omitted from the chain, under the
        assumption that the remote end must already possess it in order to
        validate it in any case.

Your server apparently sends the trust anchor. It would be exaggerated to call it an "issue": the standard allows it. At most, we could say that you may omit this trust anchor with no ill effect, and it would save a little bandwidth (about 1 kB per full handshake; the effect will usually not be significant).

(SSL Labs is known to award bad points and pronounce anathemas on details which are, actually, purely cosmetic.)


Are there any security issues with importing mail via POP/IMAP?

You are accepting the users password for an account for a service not of your control and storing it for some time (may only be in RAM) this may also be forbidden for the user of the other service to give out their password in TOS or similar.
The obvious issues with TLS MITM attacks, rogue CA... (see other questions on stack exchange, work by Moxie Marlinspike, probably not easily controllable unless you want to take your time to pin certs manually in your server implementation and only allow specific known services).
The other service may do things like automatically delete emails as they are downloaded or similar that one might warn users to check they are okay with before proceeding.
The usual security issues with your own services, buffer overflows, sql injection, cross site scripting, cross site request forgery...


Unknown ports shown on Nmap scan...and other strange behavior

0.0.0.0 is your machine that has a lot of services sometimes non-visible by other machines. Try to scan your machine from another machine and all can be more clear.

Run netstat -plnt on your machine and you can find which processed are running on these ports.


Browser copy function overridden silently, is this security risk?

Could it be misused? Yes. But I also know of many websites for which modifying this behavior is required. For example, websites that don't want you to copy paste anything from them. In those cases I've also seen them notify users with a popup like "This website does not allow copy pasting functionalities". And whether a website decides to do this or not is up to the developers. But yes, in general if someone is modifying the natural behavior of something, it's important to let the user know, imo.

Now if you ask can it be misused by hackers, yes it can, but how? If it's a compromised website, then maybe they modify this function to always have you copy a malicious URL, use it for spreading XSS, or launch CSRF attacks. From a hackers point of view, I would assume using it to launch URL based attacks is the best (mis)use case with highest chance of success. Alternatively, imagine if it had a permanent "rm -rf /n" , that'd be devastating because paste would trigger it automatically in a terminal and if you're running root, you'll understand the hard way why you should never run as root by default.

If it's the hacker's own website, then you have bigger things to worry about and shouldn't be on that website at all. End of the day, they are modifying a copy function, but they have no control over the paste part of it (in browsers atleast?)

Regarding browsers notifying users of modified copy functions -- it does sound like a good idea, but whether it should be implemented directly into the browser is a call the browser devs have to take. I would think this would be a good functionality for a browser extension to have although I've not seen any that do this.


Run fuzzer on any service or process in Linux

Generally the goal of a fuzzer is to present an application with a variety of inputs through it's expected input sources and then measure how it responds.  I'm not sure there's value in fuzzing with the memory of a running application and then seeing what happens.

Interesting, possibly, but not valuable from a security point of view.

If the threat scenario you're concerned about has an attacker in position to read or manipulate application memory then input validation or bounds checking for that application is the least of your worries.

I would focus fuzzing on the standard input channels for your application.  For example if you're examining a web browser I would focus on these input channels:

Local system files (html pages or media)
Html content returned from a server (html pages)
Media content returned from a server (video, flash, images)
Input to the navigation bar

My guess is that if you scramble the memory of a running process it's probably just going to crash and I'm not sure if that tells you anything useful.


What are steps to defend against XML External Entity (XXE) Processing vulnerability?

Have you done any research into this already? At the highest level, it is a matter of filtering and validating input and to not permit suspicious input (blacklist) or better yet set of processing rules that whitelists what you want. If the XML is not being built programmatically, you can just scan for any external references and create rules to handle/validate or just deny the file. Depending on your processing library, there may be some built in tools or options to address this.

Best place to start is probably at OWASP:

Testing for XML injection
XML External Entity (XXE) Processing

The following paper also goes into some more details in these types of attacks: XML Schema, DTD, and Entity Attacks


Why is it hard to prevent scalpers from using bots to buy up lots of concert tickets?

Phone numbers are easy to come by as are credit card numbers.  Most credit card companies offer 1 time use credit card numbers and phone numbers can be had for less than a couple of bucks per month.  It wouldn't be that hard to setup many SkypeIn or Google Voice numbers for example to get around the phone system issue.

It would make things a little bit more complicated since a person would likely still have to answer the phone, but it's also more expensive to implement and requires making calls out for every ticket purchase.  It also complicates the ticket purchasing experience for customers which would likely be greeted poorly.

There is also the obvious question of how does the activity hurt Ticketmaster?  They are still selling tickets and unless they see a drop off in venues using them, it doesn't really hurt them any, so why should they give up revenue or raise their costs to the venues (their real customers) when they can make a visible pass at trying by introducing Captchas.

Security is about analysing risk and cost and determining the point at which the mitigation of risk is worth the cost.  There doesn't seem to be a very compelling case for them at the moment to invest heavily in making it more difficult since it doesn't directly impact them and with their market position, is unlikely to have a significant impact on them.

From their point of view, the cost of preventing scalping may exceed the cost of letting it happen.


Why was the BEAST attack previously considered implausible?

The attack requires cooperation between an outer component (which can intercept traffic) and an inner component which runs on the attacked machine and is able to inject arbitrary data (chosen by the attacker) within the SSL tunnel, along with the piece of data which is to be decrypted. The general view among most people in the crypto and security communities is that when the attacker can do that, he has enough control on the attacked machine that he can be considered to have already won. A fix was nonetheless published in TLS 1.1 (published in 2006) and ulterior versions.

It so happens that with 2011's Internet, there can be a considerable amount of hostile code running on the user's system, through Java and/or Javascript, and such code has considerable power over what happens on said system. This is the kind of über-attacker that was envisioned and declared as "not plausible in practice" back in 2006. Note that BEAST is as yet unpublished except through some slides, so while it has run successfully in lab conditions, it is unclear whether it would be worth the effort to build it in the wild. After all, it seems that nobody ever bothered decrypting 40-bit SSL connections on a regular, industrial basis, despite the computational ease of doing so (that "nobody" is about attackers who are after credit card numbers and banking access passwords, not governmental security agencies -- if your country's secret service does not routinely decrypt 40-bit SSL, then you are entitled to question what the heck they do with your tax money).

One way to see it is that crypto and security researchers, and/or Web browser vendors, failed to envision the evolution of the Web architecture. Another way to see it is that browser vendors are hard at work building a Web structure which is, security-wise, doomed from start.


It increases dialog box fatigue. By overflowing the user with mundane dialog boxes, they are more likely to get into the habit of just clicking OK to remove the dialog box from their screen. This increases the risk of a user clicking OK on some important security decision presented in a dialog window.


With a serious hash, the only way to find a preimage is to make a guess and verify it. “Serious” means not somebody's homegrown method, but even MD5 which is broken for some uses still counts as serious here, as does Unix's traditional DES-based password hashing which still has the resistance that it was supposed to have (it's just that this amount is too little for today's computing power). In other words, if I have H and I want to find P such that Hash(P) = H, then the only way is to find P is to make a guess, compute the hash of this guess, and see if it's equal to H.

All password cracking methods can therefore be classified as brute force. Brute force can still use clever tricks. You can compute hashes of a lot of potential passwords and then look up many hashes in the resulting tables — that's a dictionary. You still had to compute all the hashes you're going to crack (and more). Rainbow tables consist of computing a humongous number of hashes and storing them in a clever way. A rainbow table is method for compressing a dictionary. These dictionary-based methods rely on precomputation that can be shared among many cracking attempts and are rendered useless by proper salting.

Password crackers always work by enumerating all possible passwords. The cleverness comes from enumerating the most likely passwords first — p@ssw0rd and 1loveYou before navpbtbf and homechasebogbigamy.


Possible setup for a direct democracy voting system to prevent fraud

In a perfect way you can't. There is always a group of people that could conspire to rig the system. It isn't feasible to allow every member of the public the opportunity to manually vet and observe each step.

So what you do is form a group made up of representatives from each party. In this way you know the group are extremely unlikely to rig anything because they would be unable to decide on a result to rig it to.

Another feature which can aid is to pubish a full vote log in a way where each voter can verify their own vote is shown correctly. This can be done either by assigning each voter a unique private ID or using cryptographic signatures and assigning each user a private key. The downside of this is voter manipulation (I can threaten you to vote a certain way. In a paper/booth voting system you can vote differently and lie to me) - but with an online system someone can just stand over your shoulder and watch you vote anyway.


Does Nextcloud installation gives passwordless access to all files by default?

The problem isn't with Nextcloud, but rather with the random guy's installation guide that you chose to follow. Had you followed Nextcloud's official one instead, then that attack wouldn't work. The problem is that Nextcloud uses a .htaccess file to protect that directory, and the random unofficial installation guide didn't bother to tell you that you needed to enable .htaccess files in Apache's config (AllowOverride). This mistake is common enough that under "Security & setup warnings" under Administration -> Overview, it will self-test and warn you about it if it detects it.

Further, following Nextcloud's hardening and security guidance would also stop this, as they recommend that you set the data directory to be somewhere that's not under the document root.


Clock consensus of parties in Kerberos v5

Kerberos does not synchronize time between the KDC, Admin-server and clients. The administrators need to establish time-sync mechanisms such as NTP to ensure that system time between various entities involved in the Kerberos domain is kept synchronized.

Microsoft Windows domains specify a default tolerated time-offset of 5 minutes, although this setting can be changed by a Group security policy (GPO) configuration. A lower value is more secure than a higher value, but the trade-off is the risk of rejecting genuine remote clients which may have high time offsets.

See these references for more details:

http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/time-sync.html
https://technet.microsoft.com/en-us/library/jj852172%28v=ws.11%29.aspx


Is it safe to binary-deserialize user-provided data?

I know this is really, really late in the game, but yes, there is a specific vulnerability that pertains directly to deserialisation of untrusted data. It works in the same way that so-called "PHP Object Injection" attacks do - by abusing classes that perform actions in their finalisation and disposal stages.

Consider the following class:

[Serializable]
class TempFile : IDisposable
{
    private readonly string _fileName;

    public TempFile()
    {
        _fileName = Path.GetTempFileName();
    }

    ~TempFile()
    {
        Dispose();
    }

    public FileStream GetStream()
    {
        return new FileStream(_fileName, FileMode.OpenOrCreate, FileAccess.ReadWrite);
    }

    public void Dispose()
    {
        try
        {
            if (File.Exists(_fileName))
                File.Delete(_fileName);
        } catch {}
    }
}

Now, imagine there's a really boring serialisable class called Message that just contains some strings. Nothing really interesting at all. You're using this class to pass messages around over the network, like so:

public void ProcessNetworkMessage(byte[] message)
{
    var bf = new BinaryFormatter();
    Message msg = null;
    try
    {
        using (var ms = new MemoryStream(message))
        {
            msg = (Message) bf.Deserialise(ms);
        }
    }
    catch (Exception ex)
    {
        AppLog.WriteLine("Exception: " + ex.Message);
    }
    if (msg != null)
    {
        ProcessMessage(msg);
    }
}

Seems innocuous, no? But what happens if an attacker passes a binary serialised version of a TempFile object over the network, rather than the expected Message object?

Four things happen:

The data is deserialised into an object instance by the BinaryFormatter.
The returned object is unsuccessfully cast to a Message object, throwing a cast exception.
The method exits without using the returned object, leaving the internal representation with zero references in the GC tree.
The garbage collector disposes of the object.

Why is this exploitable? Well, when the finalisation logic is called by the GC, the destructor calls TempFile.Dispose() and deletes the file specified by the _fileName field. Since that field's value is set within the binary serialised blob, the attacker can control it. Put it all together and you've got an arbitrary file deletion bug.

This seems a bit of a stretch, but often you'll find SQL queries and all sorts of other goodies in Dispose() or destructors of serialisable classes.

Edit: I did a quick search of the reference source, and it turns out that System.CodeDo
m.Compiler.TempFileCollection contains exactly the issue I showed above - you can fill it with a list of files and upon destruction it deletes them all.


Is it valid to authenticate a message by decrypting and validating the format of the plain text?

As the comments already suggest, this is a good scenario to be using AES-GCM, the Gallois/Counter mode of operation.

From the linked source:

  The operation is an authenticated encryption algorithm designed to
  provide both data authenticity (integrity) and confidentiality. GCM is
  defined for block ciphers with a block size of 128 bits

Other modes that authenticate the message with an additional MAC might work as well but as GCM is available, this might very well be the best suited option.

As to answer your actual question of just going with anything that decrypts to intelligible text:

This is not a good idea. There is a - small - probability that an attacker might alter the cipher text and it decrypts to valid plain text that wasn’t the original plain text.

While there is no known attack on AES to gain any significant advantage over randomly flipping bits to accomplish that, using GCM provides way better authentication, removes the possibility of human failure and offer this for little overhead, so GCM should be the choice here.


Since CVE is only the IDentifier to any vendor-recognized vulnerability for specific software/hardware, there is no way to categorize them using these identifiers as a basis, unless you take into account the year included in the CVE. Although, the year does not always match the date on which the Vulnerability has become public.

Knowing that each CVE ID is related to a Common Platform Enumeration (CPE), you can use it to categorize the CVE. For this, I recommend using the Data Feeds (https://nvd.nist.gov/vuln/data-feeds) provided by National Vulnerability Database (NVD).

I would like to emphasize 2 things:

A CVE can be refused even that the vulnerability comes to
public. In NVD Data Feeds files they appears as "** REJECT **". So, keep these files up-to-date;
You are still at risk for some false negative - i.e. Whose vulnerability affects certain platforms, you find the platform being enumerated in the vendor's security advisory, but it is not being enumerated in the NVD data files: CVE-2017-11779

NVD Data Feeds: https://nvd.nist.gov/vuln/detail/CVE-2017-11779

Portal MS Security Response Center: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11779

Note that the Windows Server 2012's CPE (cpe:/o:microsoft:windows_server_2012) is not present in either NVD Data Feeds nor CVEDetails.