Encryption on Mobile Devices - Multiparty Encryption - Key Management I have the following setting:
Let A, A', A'' be different mobile devices. They want to sent a secret message M to all (or some of) the C,C', C''. The message is passed on to B that stores it for some time, and passes is on to the different C.

Now I am looking for an encryption scheme, such that A encrypts the message, and only the different C can decrypt it.

My first idea was to simply use the public keys of the different C. However, since B stores the encrypted messages for some time, and we have many copies of the message encrypted with the different private keys, this would not be efficient in terms of storage.

My next idea was to use a common key for the A and C, so that the message is encrypted with this secret key, and then passed on to B that does not posses this key. However, in this case I have the problem of how to generate a secret key between all these participants, that only communicate via B, and how to I handle the situation when a new A or C joins in.

Another idea is to use commutative encryption. However in this case the A and C will depend on the trustworthiness of B. Let A encrypt the message with the key of B, then B stores it encrypted. Then it encrypts it with the public keys of the C and decrypts with its own secret key. B never actually saw the message, would however been able to do so.

What will be the easiest scheme, so that we can easily update all key material, can easily have devices join in and store only one encrypted version of the secret messages without B being able to read it?
Is there any efficient multi-party-encryption scheme with an easy handling of the key-material?

I was already referred to the Signal scheme. I am however lost in the scheme amount of algorithms they  use. And I think the key-update process in my setting would be more complex, since all communication must pass by B.

If anyone understands my confusing explanation and has some idea of how I can solve this, any help or hint would be very much appreciated!

All the best,

Luca

You can use the same way as WhatsApp group messaging does.

Heavily oversimplifying it, this is what you can do:

Each member generates their own symmetric key called Sender key.
Every member shares their sender key with each other through one-to-one encryption scheme. In your case, you can share this key by encrypting it with their public keys. So if there are n members, each member sends their sender key n-1 times encrypted with individual's public key. Total number of key exchange will be n(n-1).

  Participants' public key can be obtained from B acting as key distribution server.

If A wants to send a message to other members, A encrypts his message with his own sender key and sends it to B.
B creates copies of A's message equal to the number of recepients and forwards this it to them. This is called server side-fanout.
As recepient's already knows A's sender key, they can decrypt A's message.
When someone joins, he generates his own sender key and shares it with others the same way. Other members also share their keys with him like before. Total number of key exchange will be 2(n-1) for n members including the new one.
If someone leaves, every member clears their old sender key, generates a new one and shares their key again. Total number of key exchange will be n(n-1) for n existing members in the group.
To prevent a malicious member impersonating as some other member, each member signs their message using their private key. The public component to verify the signature can be obtained from B.

How you implement one to one messaging, this can be used to share sender keys to initialise multiparty encryption. You can also use Diffie-Hellman to share sender keys but it also has to be done n-1 times if there are n members.

Here's a good article on reducing the distribution of keys for multiparty encryption: Better Encrypted Group Chat


How can I help an online identity theft potential victim? I just learned that my dad fell for a online green card lottery scam. It happened over 3 years ago, the attacker took 60$ and disappeared. I am not even considering getting this money back.

On the other hand, he had his victim fill out all sorts of forms giving out private personal data. That worries me a lot more. I do not know what is the exact data given, my dad himself does not remember, so let's assume the worse.

So far, my dad hasn't noticed any unusual activity on his bank account, and he just wants to put this incident behind him. I already gave him the usual talk of how to detect fraud and not fall for it (as far as my internet knowledge goes) but what can I tell him about the leaked info? How can he make sure that:

It's not going to be used by identity thiefs?
It's not already being used by identity thiefs?

you can't
you can't

There is one thing you should have done instantly:

File a complaint with the police, so they know there is a possibility that his personal details might be used in an identity scam.

Of course there are some standard things:

change pincodes
change passwords
report the incident to your bank
block any related credit cards

But to be honest, 3 years after the facts is a bit late.


Can malware on my computer infect my phone? Suppose my computer is compromised or has malware.  Can the malware spread to my phone?  If so, how?  Has any malware been observed in the wild to do this?

Relevance: Some banks use two-factor authentication of online banking transactions; when you want to make a transaction, they send a confirmation code to your phone, and then you need to enter it into the web site to confirm.  This is intended to protect against fraud by malware on the customer's computer, but if malware can spread from your computer to your phone, this protection looks less effective.  Also, a number of web sites have started to use two-factor authentication, and they would be affected similarly.

Related: Can a compromised mobile phone be used to penetrate a desktop or server? asks about the reverse scenario.

There is no reason why malware cannot spread from any kind of device to any kind of device, it all depends on how the malware has been developed. AFAIK there is no malware known that infects both PCs and mobiles at this point, but there's no reason it can't be done. Possible vectors are:

infected music files: a malware infected music file could be spread to a mobile during some sort of sync, like an itunes sync
Over the network: mobiles are often connected to wireless networks, malware could be designed to use vulnerabilities in mobile OSs to infect them
Over a USB connection: when you connect your mobile to your computer communication is possible between the 2 devices, and communications path is a possible malware infection vector
Bluetooth

Of course there are other ways a mobile could be infected (phishing, infected emails, etc), but they are not a direct spread from a computer to a mobile.


ICMP redirects and source routing in the wild? Theoretically, ICMP redirect messages (IPv4 and IPv6) and source routing (IPv4) / routing headers (IPv6) are very dangerous. However, I'm curious as to if attacks using these features really work in the wild. The issues have been known for a long time, routing headers have officially been deprecated (RFC 5095).

So my question is, are these attack vectors still something one should worry about? Should checks for these features still be a part of standard hardening routines on routers?

... are these attack vectors still something one should worry about?

No, not really.

I would venture to guess that few, if any, commercial firewalls accept LSRR/SSRR packets. It might even be the case that backbone routers drop these packets. Assuming your target is using some sort of home brew of iptables/pf it seems likely that rules to block these packets would be necessary.

  Should checks for these features still be a part of standard hardening
  routines on routers?

I don't see why not? It's a simple rule-set to add and I doubt that a few more rules would have any impact on performance.


Code Analysis: Binary vs Source While conducting a software security assessment, if you have access to the source code of a compiled application (say C++), would you ever do any analysis upon the compiled version, either with any automated techniques or manually? Is fuzzing the only technique applicable in this situation or are there any other potential advantages to looking at the binary?

It depends on the situation - type of application, deployment model, especially your threat model, etc.

For example, certain compilers can substantially change some delicate code, introducing subtle flaws - such as bypassing certain checks, that do appear in the code (satisfying your code review) but not in the binary (failing the reality test).
Also there are certain code-level rootkits - you mentioned C++, but there are also managed code rootkits for e.g. .NET and Java - that would completely evade your code review, but show up in the deployed binaries.
Additionally, the compiler itself may have certain rootkits, that would allow inserting backdoors into your app. (See some history of the original rootkit - the compiler inserted a backdoor password into the login script; it also inserted this backdoor into the compiler itself when recompiling from "clean" code). Again, missing from the source code but present in the binary.

That said, it is of course more difficult and time consuming to reverse engineer the binary, and would be pointless in most scenarios if you already have the source code.
I want to emphasize this point: if you have the source code, don't even bother with RE until you've cleaned up all the other vulnerabilities you've found via code review, pentesting, fuzzing, threat modeling, etc. And even then, only bother if it's a highly sensitive app or extremely visible.
The edge cases are hard enough to find, and rare enough, that your efforts can be better spent elsewhere.

On the other hand, note that there are some static analysis products that specifically scan binaries (e.g. Veracode), so if you're using one of those it doesnt really matter...


Getting detailed information about an infected website I have a set of bad URL's. I want to know the nature of infections affecting these URL's . Running an online scanner such as VirusTotal gives me some basic information from various engines about the URL in question like which engines tag a URL as bad, but the question of 'why' seems a bit unclear from these results.
Is the URL involved in spreading a known malware ? If yes, what malware is it? And how does it affect the end client who visits such a URL? These are some of the questions I'm trying to get answers to.
Are there resources / methods to get to know such additional information?
Any help is appreciated, thanks.

I have previously found wepawet and urlquery useful in the past. Both service analyze the website in question and give you some good detail about its features and behavior.


Can JavaScript encryption's problems be mitigated? Earlier this year, I was asked to evaluate using JavaScript to encrypt sensitive information in the user's browser before sending it to our server. While my first response was "ask an expert", my boss was adamant so I went ahead and researched expert opinions on the topic as well as I could. Based on that research I came back to him with a resounding "no expert thinks that's a good idea" and was able to convince him, but I wasn't able to actually specifically answer some of his rebuttals for REASONS it was a bad idea. Specifically the main reasons I found for JavaScript in-browser encryption being bad were:

Just use TLS in the first place, it's 100% certain to be better
JavaScript doesn't offer cryptographically secure PRNG
Any Man-In-The-Middle attacker would just modify the encryption code, rendering it useless

However, the specific use-case I was investigating mitigated those:

We were already planning to enforce TLS, with the JavaScript portion only intended to cover for future TLS vulnerabilities
We would generate an RSA key-pair elsewhere and send the public key with the encryption code, rather than needing the client to generate or send keys of its own
Although it wouldn't protect against an attacker which could modify our javascript, we could still protect against vulnerabilities that allow only READING messages

I wasn't able to come up with a real answer to the last argument in particular, and could only fall back to "overwhelming consensus". I can think of some POSSIBLE arguments, but wasn't able to definitively support them:

Encryption inside of TLS adds no value in the first place
Read-only vulnerabilities in TLS aren't realistic, any crack would inherently allow modification as well
Even without modifying the original encryption code, an attacker could inject JavaScript in a different manner and prevent encryption that way
It could add a modest amount of security, but the effort and knowledge required to create and maintain it would be prohibitive

TL;DR: The main arguments I've seen against JavaScript encryption are 1) use TLS instead and 2) JavaScript doesn't generate secure keys. If TLS is also used, and keys are generated elsewhere, does JavaScript encryption start adding value?'

Note: In response to a couple comments, the use-case here is NOT end-to-end encryption; the server needs to, at least in some situations, read the original data.

Obviously, the development of the Web Crypto API indicates that there is a future for encryption in Javascript on the internet.  (Or at least the W3C believes so!)

You can now generate secure random numbers and perform cryptographic operations efficiently, so you can use it for cases like you have described.  (Another example could be to protect you in case of a passive observer in a position like Cloudflare.)

As you've pointed out, you still need TLS to provide integrity, for a failure there would allow an attacker to modify/inject malicious javascript.  However, your proposal might mitigate concerns like BREACH, CRIME, and similar vulnerabilities.  (Depending on your implementation, it might also help in the case of issues like Heartbleed.)

One problem you haven't considered is ensuring that your cryptography is adequately well-implemented that it doesn't open you up to new attacks.  Cryptography is not a panacea, and if done poorly, it can make life worse.  (For example, it might lead to new timing or ciphertext size-related attacks.)


how to access to arachni scanner web interface? I have downloaded Arachni package. It is said in the README file to run bin/arachni_web to access to web interface of this scanner.

I run it but no web page appears. I just see these lines:

>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:9292, CTRL+C to stop

and then nothing happens.

What is the problem?

You've started a web server listening on port 9292, that's what the output says. Now you need to connect to it with a web client (browser) on that port. Try with http://localhost:9292, if you're accessing on the same computer you're running your server on, or replace localhost with the IP address on which the server is running (after making sure you're not firewalling selected port, in your case 9292).

Wiki of Arachni's Web User Interface


How secure is my system for a password reset? I am using my custom Parse Server with Heroku which I am pretty sure (99%) that it is decently secure using things like oAuth2 and 1 way hashed passwords.

The problem is I am trying to implement my own custom password reset.

This is what I am doing currently:

User requests password reset
A custom token is generated (has a timer to be deleted after 10 minutes)
An email is sent with a http(s) POST request to post the token id
My application checks if the token id exists
If true, the user is redirected a webpage where they can reset their password
User clicks submit and their new password is posted using http(s) POST
My server can then safely process and set the new password

First off, is it a problem using an initial http(s) post request with the token id to request a password reset? I know if anyone got hold of this physical link while it was active (within 10 minutes) they could change a users password then login.

Second, when I make another http(s) POST request with the new user password, is method this "decently" secure to and safe practice? Because again if someone could somehow intercept the request they could gain access to the users "new" password?

My password reset doesn't need to be perfect, however I want it to be good practice.

Is there anything serious I am doing wrong / making a mistake and if so what do I need to be to fix it?

*Note I use "http(s)" with (s) in brackets because I haven't brought an SSL yet.

Thanks.

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation.

These are the issues I see in your procedure.

User requests password reset

How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a restriction to prevent misuse?

A custom token is generated (has a timer to be deleted after 10 minutes)

How will you generate the token? There are many attacks on "random" numbers.

What will happen if the timer fails - will the reset password token be valid forever? How about storing the date it was generated, and then only allow tokens that are "fresh"?

An email is sent with a http(s) POST request to post the token id

I think an ordinary link is a better choice here. POST will require mail clients to either accept html forms, or javascript - which most dont.

My application checks if the token id exists. If true, the user is redirected a webpage where they can reset their password

Where will the redirected webpage be located? It should be unpredictable as well, or require the valid reset password token in order to avoid bypass vulnerabilities.

User clicks submit and their new password is posted using http(s) POST
My server can then safely process and set the new password

Sounds reasonable

--

Now, you should also invalidate the password reset token. No need to let it float around if it has been used.

And needless to say, HTTPS is a good idea.


Independent C library or function (on Linux) to programmatically generate a self-signed certificate Is there a simple C library or function to programmatically generate a self-signed certificate in C on Ubuntu?  Of course, one can execute a simple system("....") call to execute a CLI. I am looking for a native, small, stand-alone library just for this purpose with possibly added functionality but not with the full-weight of TLS implementations such as openssl, boringssl, mbedTls, etc.

Is there a simple C library or function to programmatically generate a self-signed Certificate in C on Ubuntu?

One that isn't OpenSSL on a base Ubuntu system? No.

I am looking for a native small stand-alone library just for this purpose with possibly added functionality but not with the full-weight of TLS implementations such as openssl, boringssl, mbedTls, etc.

It may be possible to isolate some of the code and make it into a standalone method somehow, but I'd discourage this route. It's unlikely that such a tool or library exists for this task on its own.
Use a known, maintained TLS library for this. Even if it will ever only be generating self-signed certs.


What are techniques for end users to select keys on a smartcard? When multiple keys exist on a given smartcard, how can a user choose between them for a given identifier ... ideally without a loss of privacy?

For example suppose I have a government issued ID that stores a set of keys for encryption and another set for non-repudiation.  I then store an additional 3rd party key on it.

When I authenticate (or encrypt) government data, (versus 3rd party data) how can I "choose" the certificate being used?
Is certificate selection a feature of the OS, smart card driver, or smart card itself?

When choosing certificates on the card itself, I envision a button I can press like this one here:

The reason I ask this question is so I can understand not only normal smart card usage, but also instances where several UProve tokens are issued to a similar card (the interactions are likely going to be the same)

Theoretically, on a Windows system, the Certificate Propagation Service automatically extracts all the certificates from any smart card which is inserted, and copies them into the "My" store of the current user. Each such certificate is registered with a link back to the corresponding private key, which is in the smart card. When the smart card is to be used, the application actually looks for a matching certificate, potentially prompting the user for the choice of certificate; once the certificate is selected, the application then tries to reach the private key, at which point (and only at that point) the smart card driver is invoked (internally, the application talks to the "Microsoft Base Smart Card CSP" which itself talks to the card-specific "minidriver").

The main idea is that applications don't see "smart cards"; they use private keys which they locate by their certificate. Whether a given private key is in a smart card or not, or whether two keys are from the same smart card, is kept in the OS internals. Application can fiddle directly with smart cards (using winscard.dll), but most do not (e.g. Internet Explorer, when dealing with a SSL server which requests client certificates, only looks at certificates and does not care about smartcardness).

Things vary on other operating systems, or with some applications. Firefox, for instance, uses only PKCS#11, a generic API for "cryptographic devices", and completely disregards the OS support when it is run on Windows. Then, what happens entirely depends on how Firefox decides to manage smart cards. The main principle is still active, though: user choices are centred on certificates.


Which kinds of cryptographic keys can be burned into volatile memory? I just read this article (link goes to the page of the article where to quote is from) and have a quesiton regarding the paragraph "Tipps vom Geheimdienst" ("Tips of the Secret Service"):

  Aus den Unterlagen entnahmen die Experten auch zahlreiche sinnvolle
  Hinweise, etwa dass auf flüchtigen Medien kryptographische Schlüssel
  eingebrannt sein können, da sie meist an der gleichen Stelle
  gespeichert werden. Selbst wenn ein solcher Speicher nicht mehr mit
  Strom versorgt ist, könnten Abbilder des Schlüssels extrahiert werden.

This is my translation of it to English:

  The experts took numerous usable hints from the documents. For
  instance, that cryptographic keys can be burned into volatile storage
  media because they mostly are saved in the same spot. Even if such a
  storage medium isn't connected to power any more, images of the key
  can be extracted.

Operating systems use address space layout randomization so I doubt any cryptographic keys stored in RAM while the operating system is fully running (keys for home folder encryption; PGP keys; keys of TrueCrypt (or TrueCrypt successor) volumes; etc.). Those keys should (afaik and please let me know if I'm wrong) only reside in RAM, in the CPU, and on the way in-between RAM and CPU. If they are written to swap, that's of course really bad but swap is permanent storage, not volatile storage which the article talks about.

The only useful kind of key I can think of whose secrecy might be endangered by it being burned into volatile memory is keys used for full disk encryption of the disk the operating system runs on because at the point where it's being decrypted, the operating system isn't fully running so I suspect ASLR might not either.

Is full disk encryption of the disk the operating system runs on vulnerable to this? Are there any other kinds of keys which are vulnerable to this?

I don't regard any keys involved in preventing the user from booting systems without valid signature or any keys involved in UEFI as useful. I regard such restrictions as malicious.

I'll argue that no key is secure against a reset attack (or a cold boot attack) in the context you cite.  Since you distinguish between volatile memory and RAM (DRAM) let's first enumerate (at a high level) places that may have caches:

Input devices will have some kind of cache (mice and keyboard definitely).
So will do output devices (e.g. a video card buffer, hell, those things have DRAM of their own).
Buses will not have a cache, but there is one place where buses direct onto a cache and nowhere else: the front end and back end buses are used between the CPU itself and the CPU cache.  Yes, the CPU has a cache of its own, and it uses SRAM.

Before we dive into the CPU let's look at two devices that do have a cache: since the keyboard (most of them today) has a cache, a key that you type may be compromised.  And since the screen is taken from a buffer in the video card any key that is shown may be compromised.  That's a lot of keys already, but let's look at the CPU cache next:

Since encryption and decryption is performed by the CPU, then the key is very likely to be kept in the CPU cache.  This is because the CPU uses a least accessed policy for cache overwrites (and a key will be used often if decryption/encryption is happening).  And unless you're using some kind of HSM* the encryption/decryption using any key will go through the CPU.  Therefore I'll argue that any key that is actually used to perform encryption/decryption can be compromised.

Reality note

Still, the idea of a successful reset/cold boot attack on a chip taken from a random machine is almost in the realm of science fiction.  Prof of concept of cold boot attacks have been performed, but they're costly and of quite limited use.

On the other hand, we may be getting close to cold boot attacks as the years progress with better (physical) tools but we are no there yet.  For example, I have serious doubts that the biggest issue I highlighted above, the CPU cache, is possible to attack.  Taking out the SRAM chip from the CPU without damaging it seems like a daunting task.

Some Reading

Low temperature data remanence in SRAM - cambridge university
Similar question on remanece in chips

* If you are using an external HSM then the network card cache may compromise a key.  That is, unless the key is stored in the HSM.  But that is another story.


Are there guidelines for application design of HIPAA compliant browser applications? This is a different twist - I'm pushing dispatch information to first responders, such as fire, police, and EMS. But they all could, potentially, include medical information and PII together.

My goal is to make it easier for the first responder to obtain critical information, so I want to make it available in the vehicle, or on the smartphone if necessary.  This is where I'm not certain what my responsibilities are.  I'd like to provide the information via the browser.  I'm curious if a) this scenario falls under HIPAA's domain, and b) are there guidelines I need to follow in the application design - the browser component.  The back end I am confident is secure.  But I don't know what I need to do on the front end side to protect from accidental or even malicious stealing/accessing this data (by taking the phone, or glancing over a shoulder...

Any advice?
Thanks!

...falls under HIPAA's domain?

If you're dealing with PHI then the answer is probably yes.  Check out this page from the US Government Department of Health & Human Services Security Rule Guidance Material for some more information.

  are there guidelines I need to follow in the application design - the browser component? The back end I am confident is secure.

You should be thinking about a risk assessment (see above mentioned page, especially the link to NIST Special Publication 800-66).  It's good to be confident but you need to have the documentation to show that you have been thorough. Regarding application design, two good sources are the book Writing Secure Code and OWASP (check out the OWASP Top Ten as a starting point).

During your risk assessment you will be looking at threats (such as "looking over someone's shoulder") and you'll have to evaluate the likelihood of this happening and the risk that it represents.


What can Google actually do on my phone using Google Play Services? When it comes to Android security and hardening, sources like the TOR project recommend to avoid the installation of Google Play Services (I'll call them only "the services" here). I'm aware that the following things could happen when the services are running:

Google could add any malicious code at any time when I have internet access.
Google could be forced to do so or somebody could exploit their infrastructure.
The services could already contain malicious code by someone for some reason.
There are vulnerabilities which could allow elevation of privileges and such.

But there are some problems with all these possibilities:

There's no proof that something like this ever happened before (except the vulnerabilities. nobody could seriously deny that such a large codebase has vulnerabilities).
They would require a targeted attack.
It all (still) sounds like conspiracy theory for many (even technical) people.

So my question is: What can Google actually do on my phone which will breach my privacy using the services without any patching and exploits? Can they access private app data? Record keystrokes? See network communication? Manipulate what I see?

But there are some problems with all these possibilities:

  There's no proof that something like this ever happened before (except the vulnerabilities. nobody could seriously deny that such a
  large codebase has vulnerabilities).

You're in the wrong forum if you think that "it's obviously easily possible, but has not been subject to large attention" is in any way a limit to the damage that can be done.

In fact, app updates as automatically done by the Play Services have been used extensively before to remove software and intellectual property from devices, add more intrusive ads in later versions, remove functionality, add spying… pretty much the definition of "malicious", if you ask me.

  They would require a targeted attack.

No. I don't see how that is true. If google wants, it can update the home screen of millions of users at once and then later pick out the data they're interested in.

  It all (still) sounds like conspiracy theory for many (even technical) people.

Nope. It seems you're young: Back in my day (and I'm not that old), there was consensus among people that updaters are questionable, at best, and only with the advent of ever more malware, the desire to have automatic security updates outweighed the concern about unsupervised updating.

In other words: it only sounds like a conspiracy theory if you're absolutely used to running such software. If you explain to someone from the 90s or 2000s that billions of devices will update central parts of their internet-connected firmware on a single whim of a single supplier, they'd probably be a little alarmed.

  So my question is: What can Google actually do on my phone which will breach my privacy using the services without any patching and exploits?

Anything. The same services, as far as I know, is used to provide system updates. These, by definition, have the highest degree of privilege on your system.

  Can they access private app data? Record keystrokes? See network communication? Manipulate what I see?

Yes. Imagine someone replacing the software that interacts with you, your display and netork. That is exactly the job of a system component update.


What role does cryptography play in anti-piracy? As a follow-up to Cipher for Product Registration, are there secure yet usable cryptographic standards/protocols for protecting software and data used by software? I'm interested in hardware and software techniques for:

Software registration
Anti-reverse engineering
Piracy prevention
Intellectual property protection (both of source code and data)

Though related areas would be of interest too.

Personally I have seen hardware methods which use a USB or Serial device for piracy prevention, encryption of machine code (everything from a simple XOR with a constant pad to more advanced methods) for anti-reverse engineering and IP protection. Are there any standardized methods? Are there any good comprehensive/authoritative sources on the topic?

One possible model for preventing software piracy is Trusted Computing. The hardware platform is "trusted" in that it should be tamper resistant and will refuse to run non-authorized code, or divulge the contents of the RAM. This is the model employed by game consoles, e.g. the PS3. This relies quite heavily on symmetric encryption (so that important code and data is protected against prying eyes) and digital signatures (the hardware will refuse to execute code which is not properly signed). Sony goofed it up by reimplementing ECDSA improperly (and doing a few other stupid things, e.g. their disk encryption system is pathetic) but the model still holds.

Of course, tamper resistance is expensive, and the contents of a PS3 can be extracted with relatively little cost -- but still not immediately. Sony, with its complex assembly of encryption and signatures, and by enforcing mandatory firmware upgrades (by rejecting access to the PlayStation Network for people who did not upgrade), succeeds in keeping piracy at low levels, and, more importantly, concentrating piracy into the hands of not-that-many actors, at which point regular police operations are effective. Cryptography is only part of the mechanism, and the real core of the anti-piracy system is the long arm of the Law.

HDCP is a standard for encrypting audio and video data while in transit over wires; this is meant to allow for, e.g., a movie to go from a Blu-ray player to a compliant TV without being copied by any device placed in-between. There again, this relies on symmetric encryption, asymmetric key exchange, and signatures.

A cryptographic mechanism related to Trusted Computing is Broadcast Encryption. This is specifically used in Blu-ray. This is a way to symmetrically encrypt data such that:

every Blu-ray player in the world has its own decryption key;
players refuse to play unencrypted data;
a given disk "includes" the encryption of the movie for every single player key.

A lot of science goes into the details, so that a single disk may indirectly contain the encrypted keys for billions of potential players. The scheme is based on nested binary trees and a "revocation" system: a disk cannot really contain one encrypted key per target player, but it can cryptographically revoke a few hundreds of "bad keys" known to have been hacked. There again, this is a cryptographic system which does not ensure that movie data will not be extracted, but at least enforces the need of an hardware-based hack on a given player, that attackers must do again on a regular basis because widespread leakage of data can be counteracted through revocation. It is unclear whether the Blu-ray protection scheme (called AACS) will stand the test of time, but it surely is much stronger than that of the plain DVD.

A companion technology for DRM is watermarking. Whether watermarking is part of cryptography or not is debatable (and debated). Some cryptographic algorithms, in particular symmetric encryption, are used within watermarking techniques for "randomization" (encryption turns structured data into what looks like random noise, and, as such, is more easily inserted into a given medium without altering much how humans perceive it).

Summary: there is no magic cryptographic algorithm which prevents piracy. If only because encrypted data can be copied as is. But DRM is a wide subject which encompasses many areas, and a few well-designed cryptographic algorithms can be an essential part of a DRM system -- usually to "raise the bar" so that successful attackers will be fewer, and more easily targeted by conventional law enforcement agencies.


HTML iframe security exploit Can somebody explain if there's something malicious in this HTML, The width and height of the iframe ares set to 1 and it's out of the view with top: -100px; statement. I believe it takes some some sort of permission from Google account authentication without the consent of the user?

<iframe name="oauth2relay255885454" idstrong text="oauth2relay255885454"
        src="https://accounts.google.com/o/oauth2/postmessageRelay?parent=http%3A%2F%2Fjankestauorg.blogspot.com#rpctoken=831371525&amp;forcesecure=1"
        tabindex="-1" style="width: 1px; height: 1px; position: absolute; top: -100px;">

       <!DOCTYPE html>
         <html>
            <head><title></title>
            <meta http-equiv="content-type" content="text/html; charset=utf-8">
            <meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0">
            <script type="text/javascript" src="https://apis.google.com/js/api.js" gapi_processed="true"></script>
            <script type="text/javascript" src="https://oauth.googleusercontent.com/gadgets/js/core:rpc:shindig.random:shindig.sha1.js?c=2"></script>
            <script src="https://ssl.gstatic.com/accounts/o/3584451713-postmessagerelay.js"></script>
           </head><body></body>
        </html>
</iframe>

It's from including a Google+ button. You're sort of right though - it's Google seeing if you have a Google+ account in order to let you share the page on Google+, or potentially show a different button if you've already shared it.

However, only Google gets to see the data.

The entire frame is generated by Google, including the positioning. It is placed off-screen in order to avoid messing up layout of the page.


How is SHA-1 insecure if it is not vulnerable to what MD5 is? I have been hearing a lot lately about how SHA-1 is no longer going to be used because of how weak and insecure it is, but if it is not vulnerable to collisions like MD5 is, then how is it weak and insecure? What is it vulnerable to that SHA-256 and SHA-512 are not or are less likely or easy to be?

SHA-1 is vulnerable to collisions, even if no one have been publicly disclosed yet.

Some cryptographers have been working on the subject the latest years, and they estimated that the cost of finding a collision is decreasing so much that some attacks will be very soon within realm of possibility.

In October 2015, an important milestone was marked with the first freestart collision example for SHA-1, which is a collision for its internal function. This is not a full collision, but this is still a major improvement on the way on finding one, so they recommended to move from SHA-1 because they expect the first collisions to be found very soon.

They estimated the new cost of a full collision from 75K$ and 120K$, which is a 3-4 years improvement over previous estimations.

SHA-256 and SHA-512 are different algorithms, and are not affected by these theoretical attacks.

Update (February 2017): The first public collision on SHA-1 has been announced!

Both this PDF and this one share the same SHA-1 hash. This collision was found using Shattered, a new attack on SHA-1.

You can also read Google Security Team's article on their blog.


What is the fastest way to brute force a hardware code Where I live, there is a keypad with numbers from 0 to 9 and two letters, A and B.

Using it I noticed that the code was checked on the last 5 things entered. If I were to try every code on the keypad, I simple answer would be to start from 00000,00001,00002... BBBBB.

However, that would mean that time was wasted in the process.
Consider someone typing 123456789 on the keypad.

In this case, if the door doesn't open, we know that the following codes are invalid:

12345
23456
34567
45678
56789

What I'm looking for is an algorithm, or at least the name of, to find the path with the fewer key presses.

I'm not looking for a "clever way" of guessing the code, as in look at what digits are dirty.

This is called a De Bruijn sequence. A pattern that contains all patterns within it.


Who in UK I can report to if I know company is storing my password in plain text? I live in UK, some time ago I wanted to login to my electric company account to check the bill and such, and I had forgotten my password - long story short I got my account locked and had to call them. To my surprise after completing my security checking over the phone (name, address, birthday) they simply told me my password over the phone, which would imply that they have it not hashed in their database.

EDIT:
The question that is referred to as duplicate does not ask nor provide for authority in UK that would be responsible to deal with such issues (I am assuming here that there is such authority, while in fact there might not be one).

Is there an authority to which I could report this in UK?

The Information Commissioner's Office is the relevant public body. You can report a concern online.

However, there is no explicit requirement to hash passwords. The Data Protection Act includes eight data protection principles; number is 7:

  Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Whether password hashing is an "appropriate technical measure" is open to debate - an organisation can argue they have other controls. I expect the ICO would only take action if there was an actual breach.


PCI scanning and penetration testing We are moving a web app from an internal merchant hosted setup to a general service we can offer to other organisations. The actual credit card data handling is done by a level 1 PCI compliant third party via an iFrame, so we never see any of the data. Even so the SAQ is jumping from A to D according to the discussions we've had with a QSA.

I'd like to get an understanding of scanning and penetration testing from those that have been through it before. That seems to be the largest external cost for us and may affect our architecture.

The vulnerability scanning seems to be an automated service which looks for major issues. The costs appear to start from a few hundred dollars a year.

Penetration scanning seems to be a manual process where someone actively looks for holes in the security. The costs appear to start from 3k-4k a year. The scanning is broken into external and internal scanning, I'm not clear on where the border is between internal and external. For example, does external include a logged in user? It also seems possible to do the internal scanning yourself if you have done the correct training.

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

From the examples in the SAQ around penetration testing it seems that a new one must be done for (what I would consider) fairly small changes e.g. updating the OS. How does this relate to the application level? Will we be able to do new releases without having to do a new penetration test?

Any advice on how a startup should approach this is appreciated. Of course I understand only a QSA can give the final word.

Update: Thanks for the responses, I should've read the PCI penetration testing guidance document before posting this question. From that document the scope of the system seems particularly important to get right.

It depends a lot on the specific companies you choose to use - there are some common terms, but it is not unheard of to come across "automated penetration testing", or "manual vulnerability scanning".

In general, a vulnerability scan is designed to look for common flaws: it will detect out-of-date server software, unpatched systems, open ports which should be filtered, and a few more specific flaws, such as default usernames and passwords being used on publicly available systems. It can also either take place externally, where it looks at what is visible from the outside of your network (usually a remote service, hosted by the security company), or internally, where it looks at what can be seen from the perspective of a user on your network (usually a pre-configured appliance which the security company provides, and which you host on your network somewhere).

On the other hand, a penetration test tends to be more targeted, looking specifically at your systems. A tester will look at open ports and software on the systems they can see, and work to abuse them. This might include testing for things like SQL injection or cross-site scripting issues, or running brute force attacks against passwords or usernames. These types of test can be more dangerous to the systems being tested, so automated testing tends to err on the side of caution, to prevent accidental outages. Pen testers are also more likely to pick up on logical errors, where the application does something that it shouldn't (can you buy goods without paying? Can you change your user privileges?), which automated vulnerability testing won't detect.

Internal and external scanning for pen testing is usually the same as mentioned above - internal tests look at the system from the point of view of a device connected to the internal network, and often find issues which could be exploited by malicious activity by company staff. External tests are more like standard attacks by malicious third parties.

Both are very useful tools, and can be used in conjunction very well - have an initial vulnerability scan to pick up on any low hanging fruit. Fix those, then have a penetration test, which is likely to pick up on any more difficult issues (by sorting the low hanging fruit, the penetration testers will have more time to look at the more specialist parts of your system - they have to report the simple stuff if it's there). Then have a regular scheduled vulnerability scan to ensure any new deployments don't have issues. You can get a penetration test for  new systems too, if you like, or if there are major changes to your code or systems, but assuming you make use of a secure development life cycle, you shouldn't need to test every little change, unless you're in a business area with high levels of compliance (e.g. banking applications are often tested after even minor changes).


Can you detect that new files were added to a hard drive that was removed and replaced? The internal HDD was removed from my laptop (with Windows 7) and connected to another machine to tamper with. Some new files were also created/copied by the mischief maker. After the tampering was done, the HDD was reconnected to my laptop.

I don't have access to the machine where the tampering was done. I only have access to the HDD. Is it possible to prove that the HDD tampered and files were created by an external machine, not the home machine?

Does NTFS file system logs or Windows log reveal something in such case?

P.S. I have to prove it using the contents of the HDD itself, hardware artifacts will not work.

As the attacker, it would be possible to modify the disk without leaving a trace. The attack does not need to use windows to mount NTFS, and could have specialised tools to not alter the metadata or provide fake metadata.
The easiest way for an attacker to fake the meta-data would be to change the date-stamp on their machine.

That being said an attacker could be less sophisticated, or make a mistake that leaves traces on the drive. The simplest check for this is to look for files created/modified at a time you know you were away from your computer. This check is easily defeated.

To prevent this in the future use whole disk encryption, e.g. bitlocker.


How do pentesters approach a large complex network? Lots of books talk about using tools such as whois and other information gathering tools to collect information on the network and of course, not forgetting nmap. However, in a real network with such a large number of hosts, wouldn't there be an information overload? How do pentesters know which host to start probing in the sea of machines? What would a good strategy be in terms of filtering the information and focusing only on whats important?

All security tests will have a scope and its this scope that would typically drive the process of the review.

So I'm assuming from the question that you're thinking about a network based review as opposed to a review of a specific application. With this kind of review the starting point is likely to be a set of IP address ranges that are in-scope of the test.  So from that starting point, one approach would be

a) Do a light port scan for common ports (something like the nmap top 1000) across your range

b) Once that's complete kick off more comprehensive scans and at the same time start reviewing the open ports from the initial scan.

c) Do some automated vulnerabilty scanning on the open ports to find low-hanging fruit.

d) Start working through the open ports doing manual review of each one.  How far you take this will very much depend on the time available for the engagement and the number of open ports found.  If you've only got a small number you can afford to go quite deep in trying to attack each port, however if you've got 1000's of open ports and a limited time window, you're probably going to want to automate as much as possible to get coverage.

e) once your comprehensive port scans have completed, review these for less common ports, which could be useful targets.

This is the kind of flow you might expect on a "standard" pen. test, obviously if you're doing something more like a red-team where you want to avoid detection, there would be a lot less automation going on as automated scanning tools tend to be very noisy.


Repost: Wappalyzer selling datasets - possible website security implications? This question has originally been posted to Stackoverflow but then I found that this was the right place to ask. If you are a moderator, please delete this question at SO.

Hello everyone,

I am using Wappalyzer everyday as it provides me with some interesting data about the websites I visit.

Today I noticed that they actually sell full datasets/lists of sites using certain technology. You can see an example here:

  The full list of 825,070 websites using WordPress costs US $1,575

Now, I know that most of those toolbar additions to your browsers actually collect information on the sites you visit and use them later on for statistics and other purposes (Alexa, visit count websites etc.). But the fact that these guys were actually selling it openly on their site, sounded almost as if someone would sell your email address publicly.

What am I aiming at?

Well, for $1,575 someone could get a really good base for doing some nasty things. They could hit all those websites and check the core versions and let's say plugins they use. After that they could filter the older ones and perform a series of attacks to infect visitors and spread out whatever they want.

The fact that an attacker would be able to get such huge already filtered list of websites, without any effort is what makes me question if this should be allowed to be done.

My questions are:

Is this legal?
What do you think about it?
Is selling website data widely done on the net?

I am asking more because of curiosity than getting really concerned. Having read that on their site made me feel it was not something completely normal.

If I'm wrong in something - please explain.

Thank you!

Is this legal?
The usual IANAL disclaimer applies here. First, it depends on which country you're in. However, selling a list of URLs that happen to run a particular bit of software is most likely legal in many countries. Remember that, in most legal systems, the action is illegal, not the tool. Possession of a tool that can be used to cause harm is not illegal, but using that tool to cause harm is illegal. If the data includes any personal details of users, though, the legality becomes a grey area.

What do you think about it?
I think that the list has some legitimate uses:

Tracking the number of sites that use WordPress, for business modelling purposes.
Tracking the number of sites that use old versions of WordPress, for security statistics.
Indexing purposes (e.g. an Internet-wide WordPress search engine)
General marketing purposes.

However, that doesn't mean that there aren't illegitimate purposes:

Spam.
Attacking vulnerable WordPress sites.
Collection of user credentials.

Ultimately, it's something that can be used to facilitate harm, but it's also not malicious in intent. It's a moral grey area, since what clients do with it isn't really up to the vendor. However, I do think the pricing is a little crazy. I could knock up the same set of data in a few weeks with a simple spidering tool.

Is website data widely sold on the net?
Yes, though usually it's in statistical form rather than raw data. It's important for businesses to know what their target market size is, when developing addons for webapps. The same thing applies to user data - social networking sites such as Facebook and Twitter are built around the concept of selling marketing data to companies, and targeting adverts at users. Similar stats for webapps makes total sense in such a business environment.


Apart from losing €40, is there any further risk if someone has my prepaid credit card number and home address? My girl was scammed and entered my home address and my credit card number on a fake website (through a Facebook ad). What risks am I additionally incurring, apart from having lost €40 (the money that was on the card, and luckily that is one of the cards that you have to charge in advance to make a purchase)? Is there something especially urgent I have to do?

My card description:

Can only pay what I first charge in
Do not allow to transfer money to my bank account
I choosen that card to lose at most the money is in it (Even if my bank insisted I choose instead another type of card).

Call the credit card company! They have procedures for this including blocking your credit card and replacing it. You might even be able to get the 40€ back.
There is a lot of articles about this online.

If you knowingly ignore the issue you might be liable for any future damages by fraudulent credit card charges.


How to use RSA private key for TripleDES encryption? Our goal is to send SOAP messages to a web service, signing these messages using TripleDesRSA15 algorithm.

Web service staff sent us a .pfx file, where certificate for encryption is stored. I'm able to extract private key from this certificate and its first line is BEGIN RSA PRIVATE KEY.

Then I store this private key in a server and use it for encryption using python:

pkey=open("pkey.key", "rb").read()

from pyDes import *
pyDes=triple_des(pkey)

But python module pyDes complaints:
*** ValueError: Invalid triple DES key size. Key must be either 16 or 24 bytes long

Did I use wrong key or use it in a wrong way?

How to use RSA private key for TripleDES encryption?

You don't!

RSA and 3DES are two completely different encryption algorithms with completely different properties. For a start, RSA uses a key pair (encryption and decryption key, respectively; this is known as asymmetric or public-key cryptography) while 3DES (because DES) uses only a single key for both encryption and decryption (called symmetric cryptography).

If you don't know exactly what you are doing (and not to be disparaging, but based on your question, I get the distinct feeling that you don't), you really shouldn't be doing encryption on your own. There are just far too many ways to mess up, in ways that puts data at risk, even when using well-known and time-proven algorithms like these (let alone if you are designing something entirely of your own).

Instead, you should delegate the task of data secrecy and authenticity to appropriate libraries, perhaps through Python's TLS support (same as your web browser uses when connecting to a HTTPS server), and just ask for a secure pipe to the remote system. The odds of getting that wrong are vastly smaller.


Is KeePass's method for key derivation secure? I'm familiar with how key derivation functions can be used to slow down brute force attacks against passwords by requiring significant computational and/or memory resources to compute the final key.

Common KDFs I'm aware of are bcrypt, PBKDF2, and scrypt, but KeePass seems to use an entirely different algorithm that I'm not familiar with. According to KeePass's help center:

  To generate the final 256-bit key that is used for the block cipher, KeePass first hashes the user's password using SHA-256, encrypts the result N times using the Advanced Encryption Standard (AES) algorithm (called key transformation rounds from on now), and then hashes it again using SHA-256. For AES, a random 256-bit key is used, which is stored in the database file.

  [...]

  By default, KeePass sets N to 6000 encryption rounds (full encryptions are meant; N has nothing to do with the internal encryption rounds of AES). This number has been chosen in order to provide compatibility with portable device versions (PocketPC processors are slower, therefore the key computation takes longer).

Is this use of AES as a KDF secure? Are there any serious flaws with this approach? Is 6000 iterations enough to significantly slow down a determined attacker?

That line about "PocketPC processors" is a bit concerning, as it implies to me that this decision on what KDF to use was made quite some time ago, before phones with more powerful processors existed (and, by extension, at a time when desktop processors weren't nearly as powerful).

Based on a 2014 tweet from Malik Mesellem, who created a KeePass master key cracking software named KeeCracker, he was getting a bit over 1,000 password guesses a second with his tool on an Intel i7 CPU.

In an answer to this similar question about KeePass key storage from back in 2011, Tom Leek discusses the possibility of 32,000 password guesses per second with a quad core CPU.  That may have been a best case estimate that is further degraded due to inefficiencies in the cracking software managing those AES operations, like we see with the KeeCracker figure.

Either estimate is pretty slow as far as password cracking goes, where you regularly see hundreds of millions or billions of hashes per second on a single GPU with a bad choice of algorithms like MD5.  The KeePass implementation is a bit faster than a 'typical' modern implementation of bcrypt or scrypt, but probably not by so much that you'd consider them to be in a whole different class.

I'm not aware of any criticisms of their choice of algorithms or implementation, and I'm not really qualified to evaluate them myself, but it appears that it is not considered a bad choice.  I think it's fair to question whether 6000 rounds is sufficient if you want a 'future proofed' password archive, but it doesn't seem that this is necessarily an irresponsible number to use today.

So the biggest concern of KeePass users should be choosing a master passphrase (e.g. not a password) that is going to withstand simpler cracking attempts.  Don't use known phrases, don't make it too short, don't make it predictable based off someone's personal knowledge of you, etc.  If you properly avoid these things it becomes unlikely that your passphrase will be discovered through dictionary, hybrid, or brute force cracking attacks.


How to go about an SSL certificate renewal I've got an SSL certificate from GoDaddy, and it's time to renew. I ended up with a single "keystore" file, which I give to my webserver (Jetty). This is the process I went through to generate the original keystore file, which gets to my final point of confusion:

First I generated my keystore file:

keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048

Then I generated the certificate signing request (CSR):

keytool -certreq -alias myalias -keystore keystore -file myrequest.csr

I sent the myrequest.csr file to GoDaddy. They replied with two files:

example.com.crt
gd_bundle.crt

I then ran this step, which seems to be importing a portion of the GoDaddy cert into my keystore file, but not exactly sure how that works:

keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt

Final step, similar to the above, pulling part of the domain cert into the keystore file:

keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts

Now I give the keystore file to my Jetty instance and all works fine.

With the renewal, I know I have to send GoDaddy another CSR. But do I start completely from scratch? Or was I supposed to keep around the original keystore file in step one, and proceed from there?

I didn't keep a copy of the original keystore file, I modified it via the steps listed above. So if I have to use it for a renewal, not sure if I got myself into trouble here.

Here's Jetty's doc for this which I used during the original keystore creation:
http://wiki.eclipse.org/Jetty/Howto/Configure_SSL#Obtaining_a_CSR_from_keytool

Digital certificates as used for SSL/TLS have multiple components. While there are lots of details that we could examine, all we really need here is a high-level overview, but each piece is important to understand what you should do and why.

When you began the process of obtaining your certificate, you first issued the command,

  keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048

You described this as "creating your keystore," which is accurate, but it did something much more important also: it generated your private / public key pair. In this case, the new keystore contained a key pair using the RSA algorithm and with 2048 bits of entropy (a fancy way of saying how strong the key is, or how long it might take to break relative to other keys). This is important because the key pair is how you will demonstrate to the Certificate Authority (CA) that your next request is a renewal, is really from you, and is for the same certificate.

When you generated your certificate request,

  keytool -certreq -alias myalias -keystore keystore -file myrequest.csr

you created a file that contained your web site's information (foo.com), along with a bunch of other stuff - including your public key. It all got encoded into a well-known format and sent off to the CA. The CA generated your certificate using your public key and their private key, which is how some random web browser can use this to know that they are on your web site and that it's safe to send data. Your certificate gets validated by your private key, which only you have, and by the CA's public key, which only works if it matches up with the private key that signed the certificate.

So, how does all this play into accomplishing your goal of renewing your certificate?

The short answer is, you don't renew, because a renewal isn't really a renewal.

A "renewal" is just a fancy way of saying that you're requesting a new certificate, with a new expiration date, using the same private key as for the old certificate. If you use the same command as before (with the -certreq option), it will create a new certificate request using your existing key pair. Send that off to GoDaddy (or any other CA) and they should be able to process your request with no problem.

When they send the certificate to you, issue the import command and you're good to go:

  keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts

You should be able to import the new certificate into the same keystore as the old certificate, since they have different serial numbers. If you run into problems with the import, try using a new alias. Since an alias is usually just for your own reference, you can change the alias or go in and remove the old certificate from the keystore. It won't be used anymore, so it's safe to remove, but it doesn't usually hurt anything to keep it around either.

Note: you won't have to run the CA root import again unless GoDaddy updated their root certificate (it does happen, but not very often). This was the command you used to bring in the root certificate:

  keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt

Since you mentioned that you're using GoDaddy, here's the link to their renewal page. The only instructions they have that are close to the Jetty server you're using are those for Tomcat. While those aren't exact, the Tomcat page does include some instructions on the use of keytool.
GoDaddy Certificate Renewal support page


Security headers in application vs. Tomcat default 40x error I would like to assess the actual risk for various CORS attacks when a web application properly sets CSP and other response headers, but the app server error page does not. When a 40x can be provoked by trying to access protected content, for example, can the error response be used to inject malicious scripts, even though the web application is protected? I just can't envision a scenario where this is done.

Or x-content-type-options: nosniff. It is missing from a 400 error page. Is this a real vulnerability? What can an attacker do with the error response?

What's on the error page? For Apache Tomcat, it typically contains the requested URL, type of the error message, a human readable description of the error and Tomcat version information.

The error page itself isn't really vulnerable to cross-origin resource sharing (CORS) attacks, and it's not running anything from the actual application.
The X-Content-Type-Options: nosniff prevents the browser from handling non-executable MIME types as executable MIME types. Doesn't really cause harm if a browser tries to execute the error page.


How would I secure my bios? How would I fully secure my bios password/other settings from being reset/breached by pulling the battery out or by other means?

Sorry - there is simply no (electronical) way to protect the bios against pulling out and put back in the battery. Thus there is no way to protect the password and the settings against erasing, if the attacker has physical access to the PC. But a broken bios password is not the end: you have to encrypt the whole disk to secure the data against being stolen or altered (but not against erasing, for this you have a - encrypted - backup to be safe). There ist just no other way against attackers with physical access.

A bios password is usefull to prevent the hidden stealing of passwords or data through secretly booting the pc from a live-dvd or bootable USB-Stick (e.g. http://www.komku.org/2013/02/how-to-reset-windows-7-password-step-by.html), if the PC is sealed or like this.


Is it possible to make my host completely safe from the virtual machine (where I will do malware analysis)? I am using Windows 10 Home edition (Fall creators update), 750 GB HDD. I use Oracle VirtualBox, and I have two virtual machines there: Windows 7 (32 bit) and Ubuntu 14.04.5. I will do malware-analysis inside the virtual machines. I will run malwares and analyze them. The malwares can be worm, trojan, virus etc.

Is it possible to keep my host (Windows 10) completely safe from the malware-infected virtual machines? If yes, how to do that?

If my infected virtual machines use the same wifi connection as my host, is there any chance for my host to get infected?

No, it is not possible to keep your host completely safe by using a VM. And on this years pwn2own competition a guest-drive-by to host system privileges exploit chain was shown.

Yet, for analysis of „regular“ malware, the risk is not as high.

Also, if an exploit in the Networking stack is found, this might also infect your host.

Best practice: have a dedicated VM host machine that doesn’t contain any information.


Should we configure all devices to never request SSL 2.0, and reject it if offered? In an effort to reduce man in the middle attacks, when will it be (or was it) an industry accepted practice to reject SSL 2.0 connections on the client and server side?

Is configuring this on a proxy sufficent to protect a set of hosts behind it? (Update: See the answer to this question here  or scroll down)

Regarding industry accepted practices:

(from http://www.rapid7.com/vulndb/lookup/sslv2-and-up-enabled)

  "SSLv2 has been deprecated and is no longer recommended. Note that neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs cryptographic modules for use in federal information systems. Only the newer TLS (Transport Layer Security) protocol meets FIPS 140-2 requirements. In addition, the presence of an SSLv2-only service on a host is deemed a failure by the PCI (Payment Card Industry) Data Security Standard.
  Note that this vulnerability will be reported when the remote server supports SSLv2 regardless of whether TLS or SSLv3 are also supported."


Why does LastPass store password hashes on the server at all? While reading about LastPass' breach, I was wondering why would LastPass store strengthened password hashes at all on the server side? Could they only store the AES encrypted data and when the user gets his encrypted data he could do the password strengthening + decrypt it and re-encrypt all on the client side so the only information LastPass is ever exposed to is the AES 256-bits encrypted data and that would be the only thing they would store in case of a breach.

As I write this post, I'm thinking that perhaps that stored hash is part of the authentication step to not give the AES encrypted data to anyone, but would that be the only reason to store the hash on the server?

Assuming that there's an alternate method to authenticate specific encrypted data to the user trying to access it, e.g. a shared random string between client and server not derived from the master password stored on the server side, could the hashing/password strengthening + encryption/decryption then be all done on the client side with no need to store anything else on the server side than the AES 256-bits?

Because wouldn't it be easier for someone to deduce the password from the hash alone than from the final AES encrypted product that was encrypted with that strengthened password hash? My guess is that the AES encrypted data would take longer to break than its hash alone just because of the extra step of computing the hash and then encrypting. So wouldn't that be another point for not storing the strengthened hashes on the server no matter how complicated the hashing algorithm is since it is a function of the master password.

Yes, you're right - the hashed value is for authentication so that the encrypted data is not given out without the correct credentials being supplied to the service.

Another similar service, Roboform, does have different authentication and decryption passwords for each account. However, there was a serious flaw that when the web interface was used - the master password was sent to Robofom, even though they were not meant to ever receive it.

See this answer for full details of the LastPass authentication and encryption process, albeit being derived from the Security Now podcast.

From these details, my best guess is that the LastPass decryption key is calculated by:

DK = PBKDF2(HMAC-SHA256, password, email, <user set>, 256)

and the authentication key provided by the client JavaScript or application before LastPass service gives you access to your encrypted blob:

AK = PBKDF2(HMAC-SHA256, DK, password, <user set>, 256)

However, this is stored hashed on their backend:

Stored_AK = PBKDF2(HMAC-SHA256, AK, salt, 100000, 256)

As you can see, there is an awful lot of work to be done in order to get from the cleartext password into the form that the hash is stored in on the backend. The number of client side rounds (as indicated by <user set>) can also be increased, depending on the capabilities of each user's least powerful device, this is then hashed again on the client, and finally hashed server side before comparison with the stored hash. This means there's still an awful lot of work to do should an attacker gain access to the server stored hashes (as they may have already done).


Why using the premaster secret directly would be vulnerable to replay attack? Reading from this question Why does the SSL/TLS handshake have a client and server random?, the OP asks why he can't use the premaster secret directly and the accepted answer says:

  ... preventing any replay attack.

I don't understand why it can't prevent replay attack if I use the premaster directly.

The premaster is encrypted by the server's public certificate. A man-in-the-middle can't decrypt the premaster secret without the server's private key. So I think that would be secure.

Do I misunderstand something?

I think you misunderstand what a replay attack is. You are correct that a MitM wouldn't be able to see the premaster secret, but an attacker can still cause trouble even if they can't decrypt anything.

Say you make a request to the server ordering a widget. There's a MitM between you and the server, but the request is perfectly secure, and they can't decrypt anything. Unfortunately, this is an alternate universe where the premaster secret is used directly.

The MitM sees you've made a request to store.example.com. They can't see what the request is, but they can see that it's to store.example.com (either due to the IP address or due to SNI). They can't see any of the decrypted communications, but they can see all of the encrypted traffic. Just for the fun of it, they take all the encrypted traffic you sent to the server, and they send it again, 10 times.

Now your card is charged 10 more times and a few days later you end up with 11 widgets instead of 1.

Now what would happen if an attacker tried that in our universe? (very simplified)

The attacker sends a copy of the victim's traffic that it had saved
In the Server Hello, the server replies with a different ServerHello.random
All values the attacker sends that are based on the original ServerHello.random won't match
When the server receives the Finished message and tries to verify it, it will fail, because the master secret calculated by the server is different (even though the premaster secret is the same)
The server will abort the connection

The key point here is that there is some state on the server, the ServerHello.random, that is different for each connection, and the master secret depends on this state.


What are the mostly used and known or less known web tracking techniques? I know about HTTP cookies, flash cookies, ETag when dealing with user tracking on the web.

Are there other technologies, known or less known?

Thanks.

Less known are:

Using Verizons supercookie: Verizon adds an HTTP-header in every HTTP-request with an unique ID for each customer even after they changed their IP-address, cleared their cookies,...
using "Cookie Matching": You are tracked by tracker A and B. You delete the cookies of A. B manages to identify you (via cookie, ETag, ...) and inserts a tracking pixel loaded from A containing your ID so that A identifies you sets the cookie etc. again. A redirects the pixel to B containing his ID so they can later do it again. A Cookie Matching exchang network often exists of more than 100 different trackers.
Using user login: Many users stay logged in in facebook while they surf and even logging out doesnt delete the cookie. Facebook like buttons are on nearly every page. Combine it with Cookie Matching and you get very far. Same for google account/"double click" (default login on Chrome browser and on Android)
HTML5 local storage: javascript can store and retrieve data on client in the HTML5 local storage. Similar to cookies, but not sent with every request by default. It is not deleted when a user only deletes cookies. http://www.w3schools.com/html/html5_webstorage.asp


Need help with searching a file in mutillidae webserver My school has setup a webserver with mutillidae installed for us to train our hacking skills. Our goal is to find a text file. After some hacking done, I'm currently able to use remote desktop connection and login to the webserver with administrator rights. However, after searching everywhere i still couldn't find the text file. I'm sure it's not inside the webserver.
Is it possible that the file is on other machine that only the webserver is able to connect to it? If so, how?
What are the possible clues i can gather from the webserver in order to find the text file?

I don't have permission to comment yet so I'll have to add this as an answer.

You can try using the command net use and net view to see what
the server is currently accessing over the network.
You could go to start->run->compmgmt.msc then look at Shared Folders and see if anything is currently open on a different server from the current server you're on. (thanks Iszi for the shorter path to shares)
Another kind of odd possibility is that the file confidential.txt is stored in an Alternate Data Stream in which case you can use Sysinternals Streams to search for existing streams.

It's hard to help in this situation because there could be any number of different things used to hide the file; there could even be a "rootkit" like system driver installed to hide files from user view but depending on the level of the challenge, that might not be the case.


Is the service join.me actually a huge security risk? In case you don't know, there is a website called join.me which lets you do screen sharing from a browser, using a flash program that is on the web page.

Until I encountered this service, I had no idea that flash was able to do screen reading, as opposed to simpler tasks like using the web cam. But if it can do that, could it not also be recording keystrokes, storing all data from a session for someone's perusal, or the like?

Once you trust a website to provide a viewport into your company's computers' screens, who is to say that they will not be sharing details of the session? And given the nature of flash, who's to say that the session is really closed just because you close the browser window?

While the "watching a screen" aspect of that site is pure flash, the screen sharing component is not.  When you attempt to share your screen, it downloads an executable to install; an .exe on Windows, and a .pkg on Mac.

So, yes - it's a foreign binary with the capability to steal all of the data you mentioned and more; but the sharing isn't using flash, so your fears on its access to data outside of the browser are (thankfully) not the case.


Writing to drive with full drive encryption without decrypting Consider the case where a computer has 2 drives: one for a Windows OS and one for a Linux OS. The user then uses full drive encryption, BitLocker, on the Windows drive.

It can be assumed that Linux cannot read data from the encrypted drive in normal operation (barring bootkits or other exploits). But my question is about writing to the drive. Can Linux mount a BitLockered drive for writing? Will writing to an encrypted drive corrupt the entire drive?

My assumption is that one cannot write to the drive because the file system table is encrypted, but I can find no documentation or discussion about this anywhere.

I know that there is the unencrypted partition that is part of the BitLocker process, but I am not referencing that partition.

Linux can read and write data on BitLocker encrypted volumes using Dislocker, but that obviously requires the key.

If you don't have the key, you can only read and write raw ciphertext (the encrypted partition), reading it won't give you anything useful (it just looks like random data), but writing on it will definitely corrupt the underlying NTFS partition and you won't be able to mount it anymore (and Windows won't boot).


Is Browser based flows required for most IdP based Authentication standards? I'm going to apologize in advance for the rambling nature of this question, I've read a lot about SAML and OIDC and other standards, just trying to understand why browsers seem to be so essential for them.

I've been doing some reading and research into different Authentication and Authorization flows (SAML and OpenID Connect to be specific).

Assuming I am building a web based application that uses some other provider to do the authentication (Okta, Ping Federate, etc), both SSO using SAML and OIDC seem to have flows that involve redirecting to the IdP to provide the actual Authentication for the user.

Afterwards, SAML seems to use further browser redirects to perform the Authorization for my own server, whereas OIDC can use REST API calls using the exchange token or access token or whatever without needing browser redirects anymore.

My question is: why must the browser be used with the IdP when doing the actual Authentication. I understand that the only way to ensure the user's credentials are not stolen along the way is that the IdP has absolute control over it and never exposes it to any other apps involved. But are there any generally acceptable and modern standards that involve, say, just REST API calls or some way that doesn't involve browser redirects? For example, I write my own page to capture the username/password, that I then POST to an IdP.

Or is the general consensus that the Browser must redirect at least once to the IdP in order to verify that you are even authenticated, and then if the requesting page is allowed to use the user currently authenticated in the IdP.

TL;DR: Is there any Auth standards that doesn't require a browser redirect to the IdP, or do all generally accepted Auth standards require it?

The SSO protocols redirect the browser to the IdP because the browser must receive the WebSSO session cookie from the IdP's web server (same origin). Otherwise it would not be single sign-on and the user would have to type in the password for each application login.

There are two variants regarding the actual session data provided when redirecting the browser back to the application (service provider, short SP):
  - mostly older protocols only provide a one-time session-ID and the SP checks that against the IdP, optionally retrieving some more user attributes
  - newer protocols also include user attributes in a integrity-protected message (e.g. digitally signed) during redirect to SP


Is there any way to secure old unpatched Linux server? I have to maintain very old CentOS server (not patched since 2013) for a year, until new software is developed to replace it.

It holds HTTP server, mail server and many custom build apps (author gone and forgotten long time ago) with terabytes of data and spaghetti of scripts referring scripts etc.
Is there anything I can do to make it less vulnerable besides patching it, because this is going to brake too many things that I can't repair in reasonable amount of time?

Put a firewall in logging mode in front of it.  Watch all the traffic coming in and out of it and run any reports or processes that this server should do so you make sure to capture all the types of communication the firewall rules have to allow.  Create rules to allow only this traffic to pass.  Once you are confident you have everything set correctly drop and log any traffic that is outside the normal traffic parameters.  Make sure to alert on anything logged so it can be investigated to be added as a rule or as an intrusion attempt.

Edit:  I've assumed based on the question wording that this is an internal server.  Also, use the opportunity when profiling the traffic to look for indicators of existing compromise.


Is this email from OneDrive a phishing attack? Today I received an email claiming that my OneDrive account is going to be deleted as it has been unused for the past two years. This is probably true.

The email urges me to visit OneDrive to reactivate my account before a date roughly 3 months from now so I may keep my account. Seems reasonable.

What gives me pause:

The email does not use my (fake) name associated with the account, or any name at all.
The links go to onedrive.com, whereas onedrive is typically accessed from onedrive.live.com
The only place I can find that says the above site is correct is wikipedia
The whois information isn't overly helpful (to my untrained eye), but is quite different from the live.com whois information
Email is from email@mail.onedrive.com, seems within reason, but a little odd
3 of the 4 links in the email go to the same page, just with a different UUID attached to the end

Reasons why I'm not so sure:

Microsoft has sent me legit emails from other domains before. Clearly not understanding the phishing risk this causes for their users.
Microsoft hasn't picked it up as a scam/junk (not many get through)
Thunderbird hasn't marked it either (normally gives me tons of false positives)
It is a domain one would expect Microsoft to have snapped up

Easy solution:

Go to the legit website and log in, if it's a scam then no harm, if it's not then problem solved.

Unfortunately, I'm the tech geek for quite a few family members that don't understand online scams so well. If it is indeed a scam, I need to let them know so they can recognize it.

Can someone who is a little more sleuthy figure this one out for me and my naive relatives?

Yes it appears the email IS legit. On logging into the account through onedrive.live.com, there was a notice waiting for me letting me know that my account had been frozen and that it was due for deletion on the same date as the fishy email. Thanks a lot Microsoft.


Clock consensus of parties in Kerberos v5 Lets say two parties (A and B) use kerberos v5 and they happened to have varied clocks which is more than 10 mins window time of Kerberos. How does Kerberos still enable them to arrive consensus at a time? What messages are exchanged for this re-synchronization?

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

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

See these references for more details:

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


How resistant is the iPhone encryption against brute-force attacks? I just read the following paragraph in an article from the New York Times about Apple encrypting iPhones by default):

  Breaking the code, according to an Apple technical guide, could take “more than 5 1/2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers.” (Computer security experts question that figure, because Apple does not fully realize how quickly the N.S.A. supercomputers can crack codes.)

From all the advice about encryption I've hear, how important pass phrases are, six digit passwords seem far too insecure to me in this scenario. From what I understand, an attacker that has posession of the phone could try out different passwords very quickly and in parallel.

Is there any reliable estimate on how much it would take (in time and hardware) for a brute-force attack against an iPhone with the given parameters for possible passwords?

Apple has quite a comprehensive whitepaper on iOS security.

According to the whitepaper:

  Every time a file on the data partition is created, Data Protection creates a new 256-bit
  key (the “per-file” key) and gives it to the hardware AES engine

Assuming an attacker had a file and nothing else then this would be quite secure.

According to wikipedia:

  50 supercomputers that could check a billion billion (1018) AES keys
  per second (if such a device could ever be made) would, in theory,
  require about 3×1051 years to exhaust the 256-bit key space.

However:

  The per-file key is wrapped with one of several class keys [...] The
  class key is protected with the hardware UID and, for some classes, the user’s passcode.

And

  To obtain the actual key, an attacker would have to mount a highly sophisticated
  and expensive physical attack against the processor’s silicon.

So if you could extract the hardware UID you may be able to then brute force it on the passcode alone. I suspect this would be a significant challenge even for the NSA though and they're probably resort to a wrench instead.

An attacker would also have to be careful if trying any form of online (as in entering the password while the device is powered on) attack because it's possible to set a policy whereby the phone is erased after 10 failed attempts.

  The "Erase all content and settings" option in Settings obliterates
  all the keys in Effaceable  Storage, rendering all user data on the
  device cryptographically inaccessible.

Basically it erases the encryption key for all the files, so then you'd be back to trying to brute force a 256 bit AES key.

Overall I'd say the iPhone is pretty secure considering how difficult it is to secure a device when an attacker can physically access it. Having said that, an iPhone is basically a black box so caveat emptor. There's still the possibility for bugs and vulnerabilities (such as say a weak RNG) or back doors.

When your adversary is someone such as the NSA you also can't discount the possibility of them compelling Apple to sign compromised firmware then physically intercepting the device before it's delivered.


Useless 2FA in case of inside attacker Suppose a server-side signing scenario, where user keys are generated in a HSM and exported to a database, encrypted with a symmetric key derived from a user password and HSM's master key.

To sign, users must provide the referred password and an additional factor, like an OTP, for example. The OTP can't be used to protect the key because it's a dynamic value, so it's just used as an authorization barrier. The transmission of the two factors is done through SSL.

Now imagine a malicious inside attacker changes the application code, so the passwords the users submit get logged in a file.

Although the signing operation via the application requires 2 factors, somewhat preventing attacks from outside attackers, what can be done to prevent that an inside attacker accesses the HSM directly and decrypts a signing key with the password, and using it to sign documents on user's behalf?

Typically, physical access to HSMs is protected by dual control, but users may have logical access to HSM if they have the password to login remotely.

What kind of security measures can I implement to prevent this kind of inside attack?

Auditing and alerting is the general approach to insider threats.

If you make sure that activity on sensitive systems is heavily logged and monitored, you dramatically increase the difficulty of subverting those systems.  Typically, you'd log and alert on any logons, and maintain an audit log of all actions taken on the system.  To protect those logs from tampering, you send them to write-once media or another system that users of the sensitive system don't have access to.

Another effective, relatively cheap approach to the problem is the four eyes principle (requiring two people to oversee a given action).

Lastly, if you're worried about the integrity of your code, (or other files) you could always utilize code-signing.  Attaching a cryptographic signature to whatever it is you're worried about being modified would give you a very high degree of certainty that the code isn't modified without authorization (assuming, of course, you get the PKI for that signing system setup properly).


BeEF Server over VPN Is it possible the run BeEF (Browser Exploitation Framework) on the WAN through a VPN?  IF so, how would I modify to config.yaml file?  I assume I would need to open some ports on my VPN service, however the service I use (nVPN.net) won't allow me to open port 80.

Yes, is possible.

BeEF usually works with these ports:

2000
6789
3000

Two of them are only used to connect locally. So you only must open port 3000 tcp which is used for "hooking" the victims and to access to the ui control panel. You can change this port in your config changing port: "3000" to other but usually is not necessary.

If you open port 3000 is enough to access to control panel and hooking. You can restrict the hooking networks and the access to the ui control panel modifying on config these lines:

permitted_hooking_subnet: "0.0.0.0/0"

and

permitted_ui_subnet: "0.0.0.0/0"

Another good practice is to change the default pass "beef" to other to avoid somebody can enter to your control panel. This can be done changing this in config file: passwd: "yourpass" under credentials section.

Remember to load your custom config using -c argument. Example: cd /path/where/beef/is && ./beef -c /path/to/your/configfile. Sometimes on distros like Kali Linux, if you check "/usr/bin/beef-xss", there is a script inside, so you can't launch custom configs using beef-xss -c /path/to/configfile that's because is better to locate where is beef installed, enter to the directory and launch it using ./beef for some reason it doesn't work using absolute paths in this way /path/to/beef -c /path/to/configfile that's because the first example I put is the good. Some usual paths where beef executable file is installed depending of the distro are:

/usr/share/beef/ -> on BlackArch
/usr/share/beef-xss/ -> on Kali
/opt/beef/ -> on Wifislax

Then you must be able to force the victims to load the "evil" js putting the "hook.js" in anyweb page loaded by clients or however... that's another story.

Good luck!


Computer identity still recognised after reinstall I bought a second hand laptop from a guy called Marcus. It had Win 10 on it but I immediately installed a new SSD drive and loaded Linux Mint. I was surprised when I visited a cafe to find that it connected to The Cloud WiFi with the message 'Welcome back Marcus'. How is it recognising this laptop?

Because of the MAC address.

The MAC address is stored on your internet card and is shared with the router to route the internet packets. Since, you connected with the cafe wifi, it gave your MAC address to the cafe router which they then used to identify your computer using the information they previously stored.


Display browser requested cipher suites from OpenSSL I installed OpenSSL locally and used s_server command to start a server by using self signed certificate created by OpenSSL as well.

The command I used to start a https server is OpenSSL> s_server -accept 443 -www -cert c:\temp\test_server.crt -key c:\temp\test_server.key. I pointed my own browser to it and I can see a list of supported ciphers from server, and selected ciphers (Ciphers common between both SSL end points).

I am just curious is there a way to display the preferred cipher list sent by browser?

Use "-brief"
You need to use the -brief command line option:
$ openssl s_server -accept 443 -cert cacert.pem -key cakey.pem -brief

Output:
Protocol version: TLSv1.2
Client cipher list: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:SCSV
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
No peer certificate
Supported Elliptic Curve Point Formats: uncompressed
Supported Elliptic Curves: P-256:P-384
Protocol version: TLSv1.2
Client cipher list: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:SCSV
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
No peer certificate
Supported Elliptic Curve Point Formats: uncompressed
Supported Elliptic Curves: P-256:P-384
GET / HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch

Note: "-brief" does not in fact mean "brief"
The Client cipher list: line is NOT displayed when leave out the -brief option.
Unfortunately the s_server documentation provides only wrong/misleading information about this parameter:
-brief
  only provide a brief summary of connection parameters instead of the normal verbose output.

Yes, that's right, in order to get more info, you need to use the "give me less info" parameter. (OpenSSL is quirky with its command line options that way.)
Further reading
There was thread about this on the OpenSSL mailing list and a developer provided the information about the -brief parameter:

Stephen Henson, 2015-03-06, [openssl-users] Getting info on the ciphers supported by a   client (Archived here.)


What Firefox settings should be changed from factory defaults to ensure privacy vis-à-vis Mozilla? Besides turning off everything in Edit/Preferences/Advanced/Data Choices and browser.newtabpage.directory.ping
browser.newtabpage.directory.source
browser.safebrowsing...
security.ssl.errorReporting.enabled

What should one change in Firefox settings to avoid sending extra info to Mozilla?

It is unwise to post link-only answers, yet I'll point interested readers at https://github.com/pyllyukko/user.js. A metric tonne of security- and privacy-related settings are there, waiting to be implemented in your Firefoxes.

I also link to permanent webarchived version of the main script in case the repo gets deleted or lost: https://web.archive.org/web/20150413081702/https://github.com/pyllyukko/user.js/blob/master/user.js

Shameless self-promotion here: https://github.com/Hunter-Github/awesome-firefox as a repository of privacy-related links for FF.