How to generate a superkey to decrypt strings I'm working on an application where users have a key or password generated by me that is used to encrypt a string. Each user has their personal key, and no user should be able to decrypt another user's string.

How to generate a "superkey", which could decrypt the strings encrypted by all the users key? I am new in cryptography, so if I could have a little help.

EDIT : To be more clear :

Alice encrypts a string with her Key : Ka
Bob encrypts a string with his Key : Kb
Alice should be able to decrypt her String
Bob should be able to decrypt his String
John, the supersuser, should be able to decrypt Alice and Bob's String

Since you generate the user-specific keys, you can also keep a copy of these keys somewhere (somewhere safe, preferably) and use them when needed.

Alternatively, you can generate the keys with a cryptographic derivation system which uses a "superkey" and the user's identity. For instance, consider the following:

The superkey is K.
A user is identified by his name/login/email u.
The key for user u is computed as: Ku = HMACK(u)

I.e. you use HMAC, using K as key, to compute the user-specific key. Since HMAC is deterministic, you can always do the same computation again, as long as you know the "superkey".

Of course, the "superkey" is sensitive; it must never be known to anybody else than the superadmin. In particular, you MUST NOT "hide" the superkey within some application code that goes to the user's machine. This can be a problem if the user key generation is supposed to happen on the user's machine (that is, it is done by "you" in the sense that it is "your application", but still on the user's computer or smartphone, thus within range of reverse engineering).

This HMAC-based mechanism is, really, a kind of efficient compression method for the same initial model, i.e. you keep a copy of the users' keys. (If that sentence seems obscure to you, then you don't know enough (yet) to securely deal with cryptography.)


How does end to end encryption work with whatsapp web? Since today I have noticed whatsapp is using end to end encryption. However web.whatsapp.com is also still working. Does whatsapp establish a connection with my phone to keep things secure?

Correct: The Web-Client is establishing a secure connection to the phone. The messages you send through WhatsApp Web are encrypted by the WebClient, decrypted by the phone, then re-encrypted to fit the end-to-end scheme and then sent to the recipient. Same thing the other way around.

I dont know details about the protocol, but this is what i suspect (or how i would implement it):

When first opening WhatsApp Web a key pair for asymmetric encryption/signing is generated (and stored in the local storage of the browser. Probably RSA or ECC.
Scanning the QR code exchanges the fingerprint of the said keypairs public key. This establishes trust between phone and browser installation: the fact that the user scanned the QR code implies that the user trusts the browser.
When WhatsApp Web is to be used, a TLS connection to the phone is established (probably proxied by WhatsApp to overcome Firewall and NAT issues). WhatsApp Web authenticates towards the phone using the initially generated keypair (thus relying on the trust established earlier).

The connection between the Browser and the phone is fully qualified TLS: Authentication and PFS included.


My web server is hit by strange traffic, what is that? I'm a noob and just set-up a linode account to play around with linux development.
I started nginx and made a simple homepage for my domain (giuliopizzini.com).
Today I checked the nginx logs and there is some really weird traffic going on, as if my web server was hit for random websites. I'm attaching Nov 23 logs  as an example, but it's the same averyday.

Anybody can explain what is going on? Thanks!

access.log Nov 23

217.136.10.64 - - [23/Nov/2011:03:32:44 -0500] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0    (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0    Safari/535.8"
217.136.10.64 - - [23/Nov/2011:03:32:45 -0500] "GET /favicon.ico HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8"
217.136.10.64 - - [23/Nov/2011:03:33:03 -0500] "-" 400 0 "-" "-"
58.218.199.227 - - [23/Nov/2011:06:51:23 -0500] "GET http://www.tosunmail.com/proxyheader.php HTTP/1.1" 404 570 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
58.218.199.227 - - [23/Nov/2011:11:38:16 -0500] "GET http://218.83.152.252/judge112233.php HTTP/1.1" 404 570 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
58.218.199.227 - - [23/Nov/2011:15:15:15 -0500] "GET    http://www.shopsline.com/proxyheader.php HTTP/1.1" 404 570 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
206.196.111.204 - - [23/Nov/2011:21:11:51 -0500] "GET / HTTP/1.0" 200 34 "http://findsa.co.za/directory/" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"

error.log Nov 23

2011/11/23 03:32:45 [error] 30442#0: *175 open() "/etc/nginx/html/favicon.ico" failed (2: No such file or directory), client: 217.136.10.64, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "giuliopizzini.com"
2011/11/23 06:51:23 [error] 30442#0: *177 open() "/etc/nginx/html/proxyheader.php" failed (2: No such file or directory), client: 58.218.199.227, server: localhost, request: "GET http://www.tosunmail.com/proxyheader.php HTTP/1.1", host: "www.tosunmail.com"
2011/11/23 11:38:16 [error] 30442#0: *178 open() "/etc/nginx/html/judge112233.php" failed (2: No such file or directory), client: 58.218.199.227, server: localhost, request: "GET http://218.83.152.252/judge112233.php HTTP/1.1", host: "218.83.152.252"
2011/11/23 15:15:15 [error] 30442#0: *179 open() "/etc/nginx/html/proxyheader.php" failed (2: No such file or directory), client: 58.218.199.227, server: localhost, request: "GET http://www.shopsline.com/proxyheader.php HTTP/1.1", host: "www.shopsline.com"

Access log

1.  304 not modified answer. Most likely a perfectly legal request, especially considering the user-agent.

2. 404 on favico.ico means that your webserver does not have the favicon.ico file available and replies with "404 not found". This is normal and can be fixed by adding a favico.ico file to your webserver document root.

3. "400 Bad Request". This looks like a probing request to see how your webserver replies to this. Usually the webserver only returns "Your browser sent a request that this server could not understand."

4. 5. 6. This is harmless 404 returning from your server. However this seems to be probing for proxy functionality on your webserver.

 7. Harmless request to your document root (probably returning index.html or similar). The findsa.co.za path is the referer header.

Error log

1.2.3.4. Harmless entries. These are just the webservers error when trying to load the files which it responded 404 on.


Best practice to manage user's java/browsers/flash player/adobe reader auto-update We are specially concerned about if our users keep updating their browsers, flash player, adobe reader, java( feel free to let me know some others that are also important). These applications usually the most common entry for attack/virus.

For windows and office update, we are doing well with WSUS. But we have noticed some users disabled flash player auto-update. Any idea? Is it possible to solve the problem through GPO?

There are a few different options I can think of off the top of my head.  The easiest way would probably be to push the updates yourselves, either through a deployment project that can be tied in to WSUS or more simply, through a log on script that would check the version and update.  Both require some custom setup to make work though.  GPSI can also be used though it is a bit older and doesn't scale as well for larger setups.

I know we generally frown on linking off-site but there is a really nicely done write-up on more detail about this here.


Contents for Security Operations Reporting Are there good guides or references on what a monthly report from a Managed service provider such as a SOC would be ?

This is pretty loaded and will likely be dependent on your organization and business vertical. For instance, your organization may be interested in receiving monthly reports on failed logins for executives, but some orgs may not care about that (for various reasons...).
In general though you will likely want to receive a number of reports, such as:

1) A report breaking down all critical or high risk incidents and their corresponding investigations for the month.

2) A report breaking down events be severity and category (as defined in conjunction with the SOC and the business). This can help with trend spotting.

3) A report discussing activity within the environment over the month such as it may affect the SOC and organization (such as EPS trends and so on).

Rackspace has something on this with sample reports here: https://www.rackspace.com/sites/default/files/white-papers/7_rackspace_managed_security_-_sample_reports_copy.pdf


Should I keep old or expired SSL crt, cabundle and key files Is there a standard or best practice as far as retaining old or expired SSL crt, cabundle and key files for your domains?

It's expired so it's no good for daily use. But it might be able to decrypt previous data. If you don't plan on recovering that, destroy the damn thing. In linux, this can be done with the shred command.


can ssh port forwarding be detected? say there are three players: A, B, C where A is local machine, B is ssh server, C is the final destination.

through ssh local port forwarding, A can connect to C via B.

So then data will be following the path A--B--C in order to communicate each other.

Let say C was originally designed to only allow connection from B but restrict connection from A. Of course this is the reason why A would use port forwarding to reach C.

In this case, is there a way for C to detect that even though its data is going to B, the end-user is actually A?

In other words, is there a way for C to detect port forwarding?

Based on my limited knowledge, since C is sending all the data to B afterall, shouldn't it NOT be able to detect A?

No, C will not be able to know that A is the original source of traffic.  All packets will have B as their source IP address, and even the TTL of B.  (Because only the contents of packets are copied, not their metadata.)

Of course, if you control B, you can detect the port forwarding, and block or tag it as you want, but you probably shouldn't allow untrusted users to do port forwarding on B, or shouldn't be treating B as a trusted host.


/dev/random in EC2 cloud is /dev/random any good in AWS EC2 for use in making a shared key that will be passed over a secure channel?  i am concerned that a launched instance would have not much entropy to begin with.  what if i delay using it for a couple minutes to get random EBS delays for more entropy?

edit:

i will not be logging in to these instances.  one instance will generate a key and place it (in hex) in a tag.  another instance will get the key from that tag and set up a VPN between them.  maybe there is a way to use PKC for this although the path to/from tags is https, which AWS depends on for login passwords.

edit2:

i guess timing to access the EC2 API can be another source of entropy.

The potential problem with cloud machines and randomness is VM cloning; see this. Any decent Linux system will be able to produce high-quality randomness from /dev/urandom at any point after boot, regardless of whether it sits in the cloud or not. However, if a VM is cloned, then the two machines will start at the same internal state, and there is no safety mechanism that can be included in the OS for that, because, by definition, the guest OS is not aware of the cloning.

It is technically feasible, for Amazon, to push fresh randomness in each newly cloned instance (it suffices to update the "seed file" in the clone). I don't know if they do it. If they do not (or if you cannot find some written documentation that says that they do), then you may have to do the reseeding yourself. Though simply waiting for a few minutes of network activity should inject enough entropy, it is both faster and arguably safer to force it yourself. Assuming that you are accessing the Amazon EC2 instance through SSH from your laptop/desktop, and that your laptop/desktop uses Linux too, then it becomes a simple matter of doing this once:

dd if=/dev/urandom bs=20 count=1 | ssh TheEC2MachineName 'cat > /dev/random'

and voilà! 20 fresh bytes of strong randomness added to the VM entropy pool. You can then proceed with all your crypto things on the VM right away.


How to safely store sensitive data like a social security number? I am looking for a way to safely store personal information with low entropy safely.

I have the following requirements for the data:

Must be able to search (i.e. to look up an existing piece of data) but not view
Other systems must be able to recover the real value
The system must be reasonably well performant (options in seconds not hours)

I think a system of encrypting the data using a public key is my best option. I can keep the private key offline so the individual value cannot be directly recovered. However I think that an attacker could use the encryption process as an oracle and recover the data due to its low entropy.

Any ideas on how to improve the security of this system? Not collecting this data is not an option. There will be additional layers around this data (access control, logging, physical security, etc) so I am just focused on this part of the system.

What you're looking for is deterministic encryption: that the same value encrypted twice gives the same output.  Given deterministic encryption with a key K, an attacker would need the key to determine which SSN maps to which encrypted value.  You can still perform searches on the deterministically encrypted data, but only equivalency comparisons (==, !=).

Examples of deterministic crypto that would work:

Block ciphers in ECB mode, if the data is <1 block long
Block ciphers in CBC mode, with a static IV.
Block ciphers in CBC mode with an IV derived from the plaintext.  (Note that you don't want to store the IV then, so decryption without the plaintext is thus impossible, so this is a search-only option.)

What won't work:

CTR Mode with a static IV (an attacker can then use multiple ciphertexts to recover the keystream & plaintexts)
CBC Mode with a random IV (can't search)
Any stream cipher (same as CTR mode)

Note that, in all cases, you are giving up ciphertext indistinguishability, but that's a core requirement of being able to search on the ciphertexts.

You do need a mechanism to share the key with other systems that need access to the plaintext, but an attacker who gains access to a database backup, SQL injection, or any other attack that gives access only to the database won't be able to discern the plaintexts.

PKI is not useful here, as you point out, as having the public key allows to enumerate the values and recover them, if you're using a deterministic PKI cryptosystem (plain, unpadded, RSA, for example).  Using a non-deterministic PKI (padded RSA) will not allow you to search on the ciphertexts.

I would review whether you really need to encrypt small, easily brute forced plaintexts.  What is your threat model?  Can you protect against these threats in other ways?


Using SessionStorage for Some User Info I have an application that currently keeps a few properties from a user's profile in session storage for the app to use when necessary. We don't keep sensitive data like username or password or ssn in session storage, but we do keep properties like the user's branch there. And the app uses the branch info to load certain data, while excluding other data. For instance, if a user's branch is "New York" then we load data relevant to that branch.

To clarify further, this is an in-house app -- behind a VPN -- so only employees will be using the app. And we let them temporarily change their branch in the app itself if, for instance, they're in the New York branch but want to see data from Los Angeles.

Is using session storage like this considered a reasonable practice, or should something like this always be stored in something like JavaScript storage? I have one colleague who seems to think this should definitely not be in session storage, but I'm not sure that's the case here. Is this considered a major no-no in this kind of use case? Or could this be considered a reasonable usage of session storage?

Probably the biggest concern I would have with this is scalability. It is unlikely that the web server language you are using is storing session variables in any kind of optimized database.  So if you are only planning on storing a few short variables for a few concurrent sessions, I would say this is a great way to do it (I've used it in some of my applications).  As far as security goes, storing variables on server side as opposed to client side is always preferred.


How do I get the list of cipher suites supported in a specific TLS version? Is there any cipher suites supported in one TLS version and not supported in the other? If yes, then is there any documentation that talks about the cipher suites supported in each TLS or SSL versions?

Yes, the documentation you are looking for are the RFC documents for the various versions.
Here are the links to the RFCs for TLS 1.0, 1.1, 1.2 and 1.3:

TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

Since this would be a link-only answer, here the core of each RFC.
TLS 1.0
The chapter 9. Mandatory Cipher Suits reads the following:

In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

This means that, unless and application profile says otherwise, a compliant application only has to implement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to be compliant to TLS 1.0. Of course, more ciphers were defined by TLS 1.0, and implementations were free to include even more, but to be TLS 1.0 compliant, this was the absolute minimum.
A complete list of all TLS 1.0 standardized ciphers is found in Appendix C. CipherSuite definitions:
CipherSuite                      Is       Key          Cipher      Hash
                             Exportable Exchange

TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA

TLS 1.1
Similarly to TLS 1.0, TLS 1.1 defines in chapter 9. Mandatory Cipher Suits the following:

In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Again, the complete list of all standardized ciphers is found again in Appendix C. CipherSuite Definitions:
CipherSuite                           Key Exchange   Cipher      Hash

TLS_NULL_WITH_NULL_NULL               NULL           NULL        NULL
TLS_RSA_WITH_NULL_MD5                 RSA            NULL         MD5
TLS_RSA_WITH_NULL_SHA                 RSA            NULL         SHA
TLS_RSA_WITH_RC4_128_MD5              RSA            RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA              RSA            RC4_128      SHA
TLS_RSA_WITH_IDEA_CBC_SHA             RSA            IDEA_CBC     SHA
TLS_RSA_WITH_DES_CBC_SHA              RSA            DES_CBC      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA         RSA            3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_DES_CBC_SHA           DH_DSS         DES_CBC      SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      DH_DSS         3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_DES_CBC_SHA           DH_RSA         DES_CBC      SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      DH_RSA         3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA          DHE_DSS        DES_CBC      SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE_DSS        3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA          DHE_RSA        DES_CBC      SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE_RSA        3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5          DH_anon        RC4_128      MD5
TLS_DH_anon_WITH_DES_CBC_SHA          DH_anon        DES_CBC      SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     DH_anon        3DES_EDE_CBC SHA

TLS 1.2
Chapter 9. Mandatory Cipher Suits again tells us the minimum required supported ciphersuites for TLS 1.2:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

The complete list can be found again in Appendix C. CipherSuite Definitions:
Cipher Suite                            Key        Cipher         Mac
                                        Exchange

TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
TLS_RSA_WITH_RC4_128_SHA                RSA          RC4_128      SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA          3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA
TLS_RSA_WITH_AES_256_CBC_SHA            RSA          AES_256_CBC  SHA
TLS_RSA_WITH_AES_128_CBC_SHA256         RSA          AES_128_CBC  SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256         RSA          AES_256_CBC  SHA256
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS       3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA       3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS      3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA      3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5            DH_anon      RC4_128      MD5
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon      3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS       AES_128_CBC  SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA       AES_128_CBC  SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS      AES_128_CBC  SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA      AES_128_CBC  SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon      AES_128_CBC  SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS       AES_256_CBC  SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA       AES_256_CBC  SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS      AES_256_CBC  SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA      AES_256_CBC  SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon      AES_256_CBC  SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS       AES_128_CBC  SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA       AES_128_CBC  SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS      AES_128_CBC  SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA      AES_128_CBC  SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon      AES_128_CBC  SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS       AES_256_CBC  SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA       AES_256_CBC  SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS      AES_256_CBC  SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA      AES_256_CBC  SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon      AES_256_CBC  SHA256

TLS 1.3
TLS 1.3 is a bit more demanding with minimum requirements. Chapter 9. Compliance Requirements again states what an application needs to implement at minimum to be compliant to TLS 1.3, but it's more than a single cipher suite.

In the absence of an application profile standard specifying otherwise:

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement theTLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites (see Appendix B.4).

A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519.

Furthermore, chapter 9.2. Mandatory-to-Implement Extensions lists many mandatory extensions that a TLS 1.3 compliant application must implement. These are too many to list here, but the RFC is linked at the top of the question if you want to see those yourself.
Finally, the Appendix B.4 Cipher Suites defines the following Cipher Suites:
+------------------------------+-------------+
| Description                  | Value       |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
|                              |             |
| TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
|                              |             |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
|                              |             |
| TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
|                              |             |
| TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
+------------------------------+-------------+

As you can see, this list has been reduced quite a lot. Turns out supporting a ton of cipher suites with questionable security is not a great idea.


Is there any point in setting the secure cookie flag for HSTS websites? If my website has HSTS and forced HTTPS (i.e. user won't be able to access the plain HTTP version of the website), is there any point in setting secure: true for the cookies?

Yes, you should still mark your cookies as secure, for three reasons:

You dont want them to be exposed just because of a server configuration mishap. What if you move your application to a server with a different configuration?
HSTS is trust on first use. If your HSTS has expired but your cookies has not, the browser may send them unencrypted. Whether or not there is something responding to plain HTTP is irrelevant here.
As Tgr writes, not all browsers support HSTS.

I admit that the benefits aren't huge here, but the cost is basically zero. So set the secure flag!


How a DOS TCP packet different from normal Packet? a normal tcp packet shown in figure

How a TCP packet that causes dos attack different from normal Tcp Packet?

It doesn't differ, really. A denial of service usually involves a flood of packets, rather than a single malformed packet. There were a few attacks "back in the day", like the Ping of Death, which exploited vulnerabilities in the packet handling code on the target system, but these are (largely) a thing of the past.

In general, with a DoS attack, you'll find that thousands of SYN packets are sent in order to starve the system of resources. This can prevent legitimate users from connecting, since the system is trying to serve the fake clients.


Multiple devices authorization with refresh tokens I don't really understand at all the protection scenario when a refresh token is stolen. Please explain.

Let's say there is this situation: the user is authorized in a mobile app and this app contains two tokens - a short-living access token and a long-living refresh token. Now, the attacker somehow steals both tokens from the user's device and immediately uses the refresh token to get a new pair of tokens, making the old tokens invalid. After that, when the user tries to use his old refresh token it will be invalid, and he will have to login again using his password.

At this point, the server should invalidate all other refresh tokens to prevent further usage by an attacker. But how then to implement multiple device authorization for one user, if there is only one refresh token available at a single time?

In the scenario presented, you can grant the user distinct tokens for each authenticated device, and each such device would have its own unique identity. In this way, you would be applying that "one-per" limit to users and devices rather than to users alone so they can authorize multiple devices.


Who: phone manufacturers, GSM operators or OS-creators (or whoever) should care that our mobiles do not to connect to rogue GSM towers? Which one in this chain should be blamed for not taking care of security:
Phone manufacturers, GSM operators, SIM card manufacturers or OS systems (Android, iOS, etc..) to protect our phones from connecting to rogue GSM antennas? It seems so easy to get hacked, just attacker sets up a rogue tower and that's all.

International interoperability

Users - and thus also phone manufacturers and network operators - want the ability for phones to connect to all kinds of operators throughout the world. It's a clear benefit that if you take your phone, fly across the ocean, and turn it on - and it becomes able to receive and make calls. This means creating and using standards that enable the phone to negotiate a communications channel with any tower following the standard - including operators that were established after the phone was manufactured, including cell towers with technology generations later than when the phone was manufactured.

If I today launch a new cell operator in Wakanda, and put up generic tower hardware, then phones of visiting tourists should transparently connect to them, otherwise they'll be very unhappy that phones don't work in Wakanda. And the phone can't distinguish this scenario from me putting generic tower hardware next to your office. A global "whitelist" of operators would have technical challenges (how would an old non-smart phone w/o internet access know about my Wakanada operator that I launched yesterday?), and also require strong international cooperation, which is unlikely - for example, there are mobile operators running in disputed territories or conflict zones, where the local governments could prefer to "veto" them.

Internal roaming

An operator may be "renting" some towers from another operator - e.g. they want the phone to transparently connect to the other operator's tower. There also are virtual operators, who don't have any towers of their own, but they're paying tower operators for the provided service - and they want their phones to connect to all those towers where they have agreements. So phones connecting to towers not controlled by "your" operator is an important feature of the network that makes it work.

While you generally get notifications for international roaming, for this operators don't want you to get notified. One reason is that for branding reasons, the operator very much does not want users to know that they don't have direct coverage of that spot and you're actually using a competitors tower; the other is that in such cases simply driving down a highway would get you a dozen notifications as your phone repeatedly switches network cells.

Risk doesn't affect operators and manufacturers

Another aspect is that from the perspective of the operators and manufacturers, it's not a particularly relevant risk. It doesn't enable stealing of service or cause loss of revenue for the operators; doing so is illegal (regulated frequencies) so it's not going to be used by other companies to offer competing service; it doesn't easily enable fraud for commercial gain, so it's unlikely to be that frequently used by criminals to cause consumer backlash.

The most common abuse of fake towers is surveillance by law enforcement agencies, and the operators and manufacturers don't have a major reason to prevent that. Yes, there is also some risk to the users, but it's marginal enough to consider it as something that would be nice to fix, but not important enough to harm the (very important) interoperability while doing so.


How to detect when your RAM is being copied or scanned by a hypervisor I am working in a Virtual Machine that is on a ESXi server on a remote machine. I am not the only one who has access to the ESXi and others could take memory snapshots of my running VM. Is there a way to detect someone trying to take a snapshot, or reading the entire memory?

No, it is not possible.

The hypervisor controls everything your VM does. The isolation between your VM and other people's VMs relies on the hypervisor. If the hypervisor maps the memory of your VM for its own use, or if it allows other VMs to map it, your VM won't know about it, because of the same isolation mechanisms that don't allow other VMs to access your VM's resources if the hypervisor is operating as desired.

The RAM being copied may actually be part of the normal operation of the hypervisor, to migrate the VM to different physical hardware (e.g. for load balancing or to substitute out failing or obsolescent hardware).

Note that the situation isn't any better if your service is hosted on a physical machine. What you believe to be a physical machine could be a virtual machine, or a physical machine running malicious firmware. If you run code to manipulate confidential data on somebody else's machine, you have to trust them no matter what type of machine it is.


How to theft-protect my Android device? Usually if your device is stolen the first things a common thief is going to do is : Disconnect the devices from networks and wipe it out so he can resell it.

Here is the current setup i imagined to theft-protect my Android device against common thiefs.

Bang up the volume buttons so booting into factory reset mode isn't possible anymore. - don't worry you can replace them with a volume control app -
Disable USB debug mode.
Install an app locker which password protects the 'Settings' menu which can be used to enable USB debug mode and sometimes factory reset the device.
Install a stealth phone tracking app or your own malware which leaks GPS location and other usefull information by SMS if the attacker put on a SIM card or throught the internet if he connects to Wi-Fi.

What usefull informations could be retrieved ? LAC/CID, MSISDN, GPS coordinates, IP Address. On top of that, a RAT would allow mic and camera spying. We could leave some apps accessible for the thief to leak informations about himself.

Optionnal : Encrypt all the data to keep a more advanced thief with different goals to access your data.

These mesures leave the attacker with a locked-up device which he can't connect to any network, nor wipe out. Eventually he will become desesperate and connect to a network which will give away informations.

What do you think of this setup ? How would you manage to wipe out my phone anyways ?

Edit : In case the thief incredibly manages to wipe out the device, their's two tracking / anti-theft apps who persist even after factory reset, Avast Anti-Theft and Cerberus. You can also move your own tracking app / malware to system partition through root. Alnernativly, you can turn on Android own anti-theft protection which demand you login to your google account after factory reset

Optional : Encrypt all the data to keep a more advanced thief with different goals to access your data.

This is not optional, encryption is the #1 must have. I assume that you care about keeping your device secure because you want to keep your data secure, over making it harder for the thief to take use of the phone. If it's stolen, it's stolen, most likely you will not get it back, even if you could somehow track the thief with these applications, law enforcement will not be fast enough to catch whoever stole it and you wont go down the rabbit hole by yourself.

Also there's no bulletproof solution for preventing the manual reset of everything on the phone.

A professional thievery scenario looks like this:

the phone is stolen, the battery and sim card get instantly removed
if it's not possible to remove the battery in place, the phone is wrapped into some kind of insulation or put in a metal container
the device is taken to a well insulated place (possibly some cellar, again tested for no rays coming in and out)
it is disassembled in place, or the kernel gets reinstalled in place

Be vigilant and don't get your phone stolen. That's the best advice I can give you, and of course if storing sensitive data on the device, encrypt it (not with some fancy google play application), you should enter the decryption key on boot time.


Central auth service redirecting to subdomain, using digital signature as auth token I'm working on a "proof of concept" of a central auth service (not CAS). There are holes in my understanding of what I need to do, and I have concerns that the "protocol" is not secure.

Why/What

Users to land on a central auth server which performs credential verification, creation, and change. Once verified, the user will be auth'd for their correct subdomain and none others. E.g. Client Foo has several employees. The employees all login through the central server and are then sent to Foo's subdomain. The subdomains are for isolating large clients and for crude load balancing.

How

It is to operate like so:

User lands on https://www.example.com/login
User provides username, password, and subdomain (say, foo)
central auth service verifies credentials
Response contains sig (and a timestamp??)
User constructs a POST request to https://foo.example.com/login with relevant data, described later.

Signature

where sig is constructed thusly:

  The document to be signed is user's ID and a timestamp in yyyyMMddHHmmss format joined with a comma. For example, for ID 55555 and timestamp 20140620132430, the document string is 55555,20140620132430.

The central server signs the documents with its private key. Each subdomain has the corresponding public key so they can verify that the signer was the central server.

POST Data

Relevant data passed to the subdomain's login (or auth??) service would be:

User's ID
timestamp for request generation time. Verified by receiver to be current.
Site (subdomain)
sig (base64 encoded -- not sure why that matters...).

It's not clear to me that the client/User is the one constructing the POST to the subdomain. The central auth server would of course have all relevant data to send to the subdomain and could construct the POST itself. Then I've got to deal with how to get the user over to the correct subdomain with the correct token or cookie or something.

Questions

Does this amount to "rolling my own" auth protocol?
Would an existing standard protocol cover my use-case?
What's wrong with the above? I keep thinking it's all wrong---that it's a potentially bad answer to the wrong question; that we should rethink what we're trying to use subdomains for.
If the basic idea is sound, am I missing anything? Or does anything else need clarification?

One thing I can think of that may be problematic (if the user is POSTing to the subdomain) is that you don't sign the subdomain the user is trying to connect to. Let me try to give an example of the issue:

Let's say I have (valid) credentials for foo.example.com. I send (foo, username, password) to example.com/login and get back (sig=signed(id, timestamp)). Now I POST to bar.example.com/login with (id, timestamp, sig). bar.example.com/login will look at sig, verify that timestamp matches the signed data, and then log in the id that was signed. I'm now logged into bar.example.com. Oops.

So I'd say the not only need the user never see the sig, but giving the user the sig is actually a security issue. If you do send back sig to the user you need to do sig=signed(id, timestamp, subdomain) and the subdomain login needs to verify that it is the signed subdomain.


Is the OpenSSH server using a fallback, hard-coded DH parameter for 2048bits? I'm toying around with OpenSSH configs and poking at the Diffie-Hellman parameters.  I'm using GDSSecurity's tool to check DH settings and this page to view other SSH settings.

For funsies, I removed all moduli smaller than 4096 bits from /etc/ssh/moduli:

$ awk '{print $5}' /etc/ssh/moduli | sort | uniq
4095
6143
8191

I'd expect that the key-exchange should fail if the client accepts only 2048 bit or 3072 bit groups.  Interestingly, it does fail in the latter case, but does not in the former, 2048 bit case.

KEX proposal client: diffie-hellman-group-exchange-sha256
KEX proposal server: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
KEX algorithm chosen: diffie-hellman-group-exchange-sha256
KEX client group sizes: min = 2048, nbits = 2048, max = 2048
KEX server-chosen group size in bits: 2048
Warning: Permanently added 'test,x.x.x.x' (ED25519) to the list of known hosts.
KEX proposal client: diffie-hellman-group-exchange-sha256
KEX proposal server: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
KEX algorithm chosen: diffie-hellman-group-exchange-sha256
KEX client group sizes: min = 3072, nbits = 3072, max = 3072
ssh_dispatch_run_fatal: Connection to x.x.x.x: DH GEX group out of range

The aforementioned site also claims a successful key exchange using a 2048 bit group.

I know too little about the details of neither the SSH protocol or OpenSSH to understand what's going on here.  Does OpenSSH use a fallback parameter if no appropriate group is available from the moduli file?

Fallback DH groups are defined in source code here. The current group can be 2k or 4k. But it really depends on which version are you using (there were some changes recently).

Note the RFC 4419, which specifies:

  Servers and clients SHOULD support groups with a modulus length of k
     bits, where 1024 <= k <= 8192.  The recommended values for min and
     max are 1024 and 8192, respectively.

And the recent release notes for future openssh-7.2:

  ssh(1), sshd(8): increase the minimum modulus size supported for
  diffie-hellman-group-exchange to 2048 bits.


certificate chain ".DER" is same as intermediate certificate. Is it correct? I have question regarding DER chain (root and intermediate) certificate.
I've generated root and intermediate certificates with openSSL according to https://jamielinux.com/docs/openssl-certificate-authority/create-the-intermediate-pair.html. As a result i've got:

root certificate (ca4096.cert.pem)
and intermediate certificate (intermediate4096.cert.pem) that is signed through root authority.

I used cat command to combine them into certificate chain ca-chain4k4k.cert.pem.

Then with openssl command:

openssl x509 -outform der -in certificate.pem -out certificate.der

i converted intermediate4096.cert.pem and ca-chain4k4k.cert.pem into corresponding .der certificates. Both resulting files are binary equal.

Is it right so?
If yes could you explain me, why root certificate information is not needed?
If no, what mistake do i make? How can i attach root certificate information in the .der chain certificate.

I use OpenSSL 1.0.1t

I used cat command to combine them into certificate chain ca-chain4k4k.cert.pem ...

openssl x509 -outform der -in certificate.pem -out certificate.der

  i converted intermediate4096.cert.pem and ca-chain4k4k.cert.pem into corresponding .der certificates. Both resulting files are binary equal.

The command you used essentially converted the first certificate in  intermediate4096.cert.pem and the first certificate in chain4k4k.cert.pem into the DER format. Since the first certificate in chain4k4k.cert.pem is the same as the first (and only) certificate in intermediate4096.cert.pem the result is the same.

  How can i attach root certificate information in the .der chain certificate.

You cannot simply concatenate multiple certificates in DER format. While with PEM simply concatenating all the certificates is possible with DER you would need a container like PKCS12. See Generating a PKCS#12 file with openSSL for examples on how to create PKCS#12 files with OpenSSL.


Firewall is blocking invalid URLs, what is the danger? My Fortinet firewall seems to be blocking invalid URLs (for example, URLs that it considers invalid, which means that underscores are not accepted, even though some sites use them). This causes some problems.

I want to remove that option so that it does not block invalid URLs anymore. What is the danger of disabling the check from the firewall for invalid URLs?

I want to remove that option so that it does not block invalid URLs
  anymore.

Fortinet actually has a clear article on exactly this issue.

  it's a checkbox that I can check or uncheck

The checkbox simply controls:

Enable to block web sites whose SSL certificate's CN
field does not contain a valid domain name.

and as they point out:

When a visited URL that contains a "_", the site will be blocked
with "block-invalid-url".
As per RFC 952, " A "name" (Net, Host, Gateway, or Domain name)
is a text string up to 24 characters drawn from the alphabet (A-Z),
digits (0-9), minus sign (-), and period (.).

The prohibition upon having underscores in domain names, which dates back to RFC 952, is a controversial issue which is somewhat pedantically clung to by security software.  There's some discussion of it in this answer.  In practice, having underscores in the host portion of a domain name is technically not legal, but widely practiced and does not indicate anything at all as to the security of the site.

  What is the danger of disabling the check from the firewall for
  invalid URLs?

Very low.  This is a pedantic check on RFC compliance rather than a reflection upon any actual security value.  In practice, malicious sites are not particularly likely to have "invalid" domain names.  There is no indication from the Fortinet KB article that they are drawing on any other source of data (e.g., blacklists, keywords) when determining if a URL is "bad".


How can the Magic SysRq key be dangerous for linux users? The  magic SysRq key is known for linux users to perform some actions when the system freeze , but it considered as dangerous command for users who have a physical access to the system:

  Some people view this key as giving access to dangerous system-level commands to anyone who has physical access to the keyboard or serial console.[12] It has been argued that this perceived security risk is illusory, as anyone with physical access to the computer would already have the capability to compromise its security.[13] The advent of the procfs interface has rekindled debate over this subject.

How can the Magic SysRq key be dangerous for linux users ?

It can be used to display CPU registers (which could contain bits of confidential information), forcibly unmount filesystems or reboot the computer, among other things (denial of service vulnerability).

I wouldn't say it is dangerous though. If you have physical access to the server there so much you can do without even using the "magic" key. A lot of distributions for example allow rebooting the server with Ctrl+Alt+Del without being logged in, but even if that's disabled, just unplug the power cable.

Once an attacker has physical access, all bets are off.


Authentication & Authorization via md5(userid + secret + endpoint + payload)? I am currently developing against a RESTful API that seemingly has a rather weird auth flow.
I got an API key consisting of an ID (public) and a "secret" (which seems to be a UUID).
Now, whenever I want to call the API, I have to do the following:

Create JSON request body
md5-Hash of (API-URL, Request, ID, Secret)
Set ID as header field "UserId" of request.
Set generated hash as "Authorization" header in the API call.

I assume that the receiver pretty much does the same hashing (and knows the secret of my ID) and compares the results.
However I think this is really wonky as

The JSON request body becomes case sensitive due to the hashing. If I add one space, the hash is different and auth fails.
They "roll their own" security related things it seems.

These issues are rather broad though. I would like to know what flaws are in this implementation that I am currently not seing?

The concept of calculating some form of hash over (url + request payload + ...) is not something uncommon. I wouldn't say it is flat out wrong.
There are a few problems with this specific implementation, though:

MD5 is not considered secure. SHA-2 would be a much better choice.
There doesn't seem to be any protection against replay attack. Adding e.g. unix timestamp in the header and including it in the input to hash calculation could help. Server-side timestamp validation necessary.
Including nonce in the payload could help. No two otherwise same requests would result in the same hash.
I find calculating a hash over an input including secret a bit unusual. Why would you like to do that? More common solution would be to calculate HMAC, e.g. HMAC-SHA256 instead, and exclude the secret from HMAC calculations. HMACs provide you with authenticity, as only the party with access to the key can generate correct authentication tag. I believe authentication was the reason why the secret was originally included. With key-based HMACs, the use of uuid-like secret could be abandoned.

I wouldn't be worried about the payload being case-sensitive, extra whitespaces etc. If you implement it right, it will work. And then obviously the server has to calculate the hash (or better HMAC) and compare it with the one it received, in case of differences I expect it would respond with 401.


Are two anti-virus better than one in protecting your computer? A century old adage: The more the merrier.

In general, does this adage hold true in regards to the number of anti-virus software you should have on your PC?

Are there any limits before it actually has the opposite effect?

Most anti-virus vendors advise not to use their products together with those from others. That's not (just) because they fear competition. Live virus-scanners scan files on access. When they notice that a process accesses a file, they try to access it before the process to scan it. They even try to do that when that process is another virus-scanner.

When you have two live-scanners on a system, both will try to be the first to open a file. When virus scanner A detects that scanner B opens a file, A will try to access it first to protect B from any viruses in it. B will register this attempt to read the file, and in turn will try to scan it before A does. The result is that both virus scanners are caught in an infinite loop.

This problem, however, only applies to live-scanners. When you use on-demand scanners which don't monitor file access and only scan a filesystem when they are prompted to do so, you can use multiple of them one after another.


How can I check wifi activity? I have a LAN network with three computers connecting to the Internet both through wired and encrypted wifi connections. Is there a way I can check who is connecting to the Internet via the wifi connection?

On the wireless routers I'm familiar with, there is an admin page that lists the MAC addresses of devices that are connected. Take this with a grain of salt: a malicious user could easily change the MAC address (to either look like one of your devices, or so that it appears to be a completely different device each time he connects).


Risk of self signed certificates with Android In the OWASP top ten list  for mobile, it is mentioned that self-signed certificates should never be allowed.

I want to check with others why is this so ? If I have a server back end for my mobile app, and I sign a key-pair myself (assuming myself as a CA). If I use pinning, I will use my own CA's public key to check the certificate, and then use the server's public key (this part seems safe to me - assuming attacker doesn't know the private keys).

But if I don't use pinning, then is the risk there because now the default CA's in Android can't be used to verify the certificate, and I will have to use trust all certificates to make it work ?

In Summary: I am asking about the situation when self-signed certificates are used without pinning for an Android app.

It sounds like your use of a self-signed certificate is safe. But any variation in your usage pattern runs risks. For example, if you connect to your server via a web browser or other tool, you will not be able to automatically validate the certificate. You can still do that manually, but it won't be automatic and is somewhat error prone.

I suspect that the T10 was focused on the general case and didn't bother saying "Unless you pin the cert to your app and only access the server via the app or always manually validate the cert."

If you care, you can go get a free SSL cert from StartSSL.com and just bypass the problem altogether (though cert pinning will add security even with a signed cert).


Host an application on a virtualbox? I want to host an application locally, but I was worried about security of my local files. I decided to 'encapsulate' the application using VirtualBox.

Is that safe for my host OS (Windows)?

Yes, this approach will certainly help protect your host OS. As a matter of fact, it's an approach I take for most untrusted applications I use, including browsing untrusted web content.

This however is not an absolute way of protecting your host system, it simply increases the attacker's workload substantially. And as a matter of fact there have been exploits that enable applications to escape the virtual "sandbox."

For added security, you should save your guest OS in a known clean state and revert to it after each use.


How secure is my method? I want to select data from a MySql database on an iphone device. The method I seem is the easiest one is to connect to a php file with GET arguments and then return it as a string.

Now I'm just wondering what are the chances that someone will find the IP-address and the file and use it from a place other than the app.

The chances are 100%. It's easy for anyone to look at your code and find the URL inside it, or to watch the network traffic and infer how your requests are performed.

When you should think about your app's security, assume that this information is public and go from there.

If you want to slow down the attacker's work (but keep in mind that you won't be able to prevent it!), you can look into obfuscation and think about encrypting your HTTP traffic (be sure to verify the certificate in your application!).


Can firewalls get affected by the traffic they process Does such attack exist? Forgive my wild imagination but is it possible for a hacker to pretend/try to communicate with a service on the server and when the firewall examines the traffic it get's poisoned or taken control of?
If such scenario exists what is the name of such attack?

To my understanding firewalls are unlike proxies, they don't receive the traffic and regenerate it but they only examine it which makes things more difficult

Yes, definitely. See the Witty worm for an example of a vulnerability in a firewall product that was exploited by a network worm.

Firewalls are nothing but software and affected by the same flaw. The more complex the firewall, the more likely it is for a bug to be introduced.

For instance, a simple port filtering firewall is very unlikely to be affected by the data content of the packets but it can be affected by anything that is in the IP or protocol headers (TCP/UDP/ICMP/etc.) while a deep packet inspection firewall might include a vulnerable parser that could be exploited.


Airodump-ng and my iPhone Yesterday I run the Airodump-ng tool to check out the invisible.
I noticed that in the client section there was a somewhat familiar name of a Probe. The person that this nickname reminded is a tech-savy friend. I thought of switching my phones wifi on and off, and with each turn on the Airodump-ng tool detected my phones client with the same Probe name, which confirmed that it is my device. Today I went to that friends living place and turned on my phones wi-fi, and it found a wi-fi with a name which appeared as my iPhone when Airodump-ng was turned on. Dows this mean he was spying on me?

What this might be is a probe for known SSIDs by your iPhone. You might have saved his wifi and this probe might be trying to connect to a hidden SSID (your phone is probing to see if the SSID is in range). This is not abnormal.


Fake bank text message I recently tried to use my card to buy something on my phone for £29.99. My card was declined so I used a different card and the payment went through.

A couple minutes later I get a message from a number, the same as my bank's, telling me "you've paid £29.99. if this is true send Y if not true send N" for the declined card. Since that wasn't true and the payment wasn't made on that card I sent N.

After speaking with the bank they told me it was not a legitimate text so they made me cancel my card. But is my phone hacked now that I've responded to the malicious text?

Replying to an SMS message will not have infected your phone.

(I am assuming your phone is secure enough not to be infected by trivial means like displaying an SMS)


Is it possibile to send NaN value to a param to bypass (PHP)? is it possibile to bypass some check like this:
$amount = (int)$_REQUEST['amount'];
if (!($amount >= 10)) {
   // authorize
}

by sending a NaN value to amount param?
like: https://www.site.com/?amount?<NaN>
and if it is, how can I pass this value?
Because as Wikipedia show:

Theoretically, this should work but I can't figure out any way to "assign" a NaN value in order to test it.

While the code is incomplete, there are a few things that stand out...
That if statement logic is terrible if not ($amount is greater than 9) == true is a werid way to write if ($amount <= 9). As the comparison uses the double compare you could potentially have performed type juggling. However $amount is cast to int making this a non issue. Also by assigning it to a temporary value via an int cast further use will contain the same number, however if the check uses $amount and the authorization code uses $_GET['amount'] or $_REQUEST['amount'] you could bypass the check and perform SQL in a later step.
Sometimes you can break PHP logic by making the variable an array, ie: https://www.site.com/?amount[]=1 however, this doesn't work against a cast to int. In this case it looks like you can just straight up authorize by setting the value to something less than 10. ie:

https://www.site.com/?amount=0
https://www.site.com/?amount=BBBB

This kinda feels like homework, so maybe post the code and objective in full?


SSL CDN, non-SSL origin; How secure is this? How secure is a setup that consists of an SSL-protected CDN and a http-only origin? In other words, the client connects to the CDN using SSL, but the CDN talks to the origin via http.

Generally, man in the middle attacks occur in locations with public wifi. But what about CDN data centers? Is there enough vulnerability for me to look for different options?

I'd say avoid this. You don't want your customers to find out you're not using real HTTPS.


ret2libc - why need 4 bytes of garbage So I started to learn reverse engineering, and I came across the ret2libc exploit.

I tried to understand how it works and I got a bit confused.

They say that when you return to the address of system you then need to give 4 bytes of garbage and the after that give the address of /bin/sh.

Why do you need to give these 4 bytes of garbage and can't just jump to system and from there to /bin/sh?

Let's say we're exploiting buffer overflow in some foo function. Consider the following stack after overflowing the buffer, stopping at ret instruction in foo function:

   ....
------------------------
"system" fn address         <-- stack pointer
------------------------
4 bytes of garbage
------------------------
"bin/sh" address
------------------------
   ...

After that, when we execute ret instruction, we'll jump right to the system function. Then, stack will look like this:

   ....
------------------------
4 bytes of garbage          <-- stack pointer
------------------------
"bin/sh" address
------------------------
   ...

so, now we are in system function. Those 4 bytes of garbage are now the return address for system function, and the values below return address are system function arguments – in our case it's single *char argument that points to "/bin/sh" string.


While logged in to Google etc., can a malicious site discover my ID? If I visited a malicious site while being logged in to Google, Hotmail, Facebook, or Twitter in the same browser window, how hard is it for the site to discover my account IDs without my explicit permission?

Assume:

fully patched operating system,
fully patched web browser with plug-ins disabled,
fully patched router with strong password and remote administration disabled,
all hardware, software, and Internet are bona fide and not tampered with,
all accounts are protected with strong passwords,
I am computer literate and aware of good security practices,
no additional software (malicious or legitimate) are present.

Bonus question:

If you can invalidate any assumption from the above list, which one would you want to invalidate? What is the weakest link of the security?

This really depends on the sites you're logged in to and how alert you are as a person. I can imagine the following scenarios (not specific to any of the sites you mentioned, but just general scenarios):

Sensitive information is transmitted in the URL: For each request, a  session ID is transmitted in the URL. In this case proxy servers will log the session ID and anyone access to these log files is able to perform session hijacking. This information could also be stored in your local cache, anyone having physical access to your machine might use it.
Cross Site Request Forgery: Missing or poor implementations of anti CSRF tokens could lead to un-validated actions on your behalf because the origin of the request is not validated. An example of a poor implementation of anti CSRF is transmitting these tokens in the URL (see #1.)
Cross Site Scripting & Insufficient cookie settings: If a website does not properly secure its cookies (e.g. missing the HTTPOnly attribute) and an XSS vulnerability exist in the same website, your session ID might get stolen while visiting a malicious site (e.g. cookie stealer).
HTTP Resonse Splitting: Also known as CRLF injection (%0A%0D) is a vulnerability due to the lack of input validation. It may lead to poisoning of the client’s web-cache, cross site scripting, theft of sensitive information and other.

Does this apply to the sites you mentioned? Unfortunately yes, it does! Although most of these sites are known to be secure, every once in a while certain vulnerabilities are discovered.

A question you should ask yourself is, should I always have an active session while browsing possible malicious websites?

Another question could be, why do I browse possible malicious websites with the same browser I use for the sites mentioned?

Your bonus question:

I would like to invalidate the "fully patched operating system". There are 0days out there that are not reported to the manufacturer(s) (that's why they're called 0days in the first place). There's no such thing as being 100% secure.

Your router: We've seen in the past that even though the router's remote administrative interface was not enabled, there was a backdoor in a specific router which could access the administrative interfaces with a specific User Agent (no credentials required).

Having said that, it doesn't mean you should get paranoid.


Sign PKCS#7 and verify PKCS#7 signature with OpenSSL If someone have to transfer X.509 certificates in a single bundle, usually, it is recommended to pack them into PKCS#7. And content of PKCS#7 can be signed.

OpenSSL allows to pack certificates into PKCS#7 in the following way:

  openssl crl2pkcs7 -nocrl -certfile domain.crt -certfile ca-chain.crt -out domain.p7b

As I understand from the man page of 'openssl crl2pkcs7', this PKCS#7 is signed:

  The output file is a PKCS#7 signed data structure containing no signers and just
  certificates and an optional CRL.

A few questions here:

What does 'containing no signers' mean?
If the content (certificates) of PKCS#7 is not really signed, how can it be done using OpenSSL?
How signature of PKCS#7 can be verified using OpenSSL considering that it was signed?

If I understand overall concept wrongly, please, clarify that.

TLDR: It's not actually signed. You do understand wrongly. To explain I'll start from the beginning.

PKCS#7, and its slightly modified and enhanced IETFized[1] form CMS Cryptographic Message Syntax http://tools.ietf.org/html/rfc3852 et pred et amici, is a standard that defines a whole series of different but similar messages for various cryptographic functions. One type of PKCS#7/CMS message is called SignedData and its original purpose, as you might reasonably guess, is to convey data with a digital signature, or for generality one or more signatures, for example a contract signed by both parties. PKCS#7 (mostly) uses public-key cryptography and needs/expects a way to properly match public-key values to entities like people and organizations and systems, called a PKI Public Key Intrastructure; in practice the PKI we use is X.509 Certificates issued by CAs Certificate Authorities which can revoke bad certificates using CRLs Certificate Revocation Lists (and nowadays also using OCSP, but that came after PKCS#7).

A SignedData actually consists of three main parts: the actual data in a structure named ContentInfo; a variable number of SignerInfo structures each containing one signature and some metadata including an identification of the certificate containing the public-key needed to verify the signature; and a variable number (maybe none) of certificates and/or CRLs that the recipient may need to determine and verify the (signing) public-keys or for any purpose. For generality the number of SignerInfo's, and thus signatures, may be zero, in which case the data is useless and is omitted.

Thus a SignedData with no data and no "signers" (zero SignerInfo structures), only certificates and/or CRLs, provided a standardized format to contain several related certificates and/or CRLs, at an early date when there was no other good standardized method for this. As a result it was widely adopted and became ubiquitous. This format is commonly identified by the extensions "p7b" and "p7c". See What's the difference between X.509 and PKCS#7 Certificate?  .

So as to your questions: this format is a PKCS#7 or CMS structure of the type named SignedData, but it does not actually contain data or signature(s) on that data, it contains only certificates and/or CRLs. Because it isn't signed, it can't itself be verified.

Each certificate or CRL in itself is signed, using a signature specific to the cert/CRL format not a general data signature. This is independent of whether it is in a p7b or separate. Each (nonroot) cert or CRL after you extract it can be verified, if you have a valid chain of certs "above" it, and should be if you use it for anything. However all PKI signatures only propagate trust from a (usually small) set of trusted "roots" or "anchors" (such as Verisign, GoDaddy, etc but hopefully not DigiNotar) to an unboundedly large set of other entities (HTTPS or other SSL/TLS servers on the net, email senders in the world, program developers in the world, etc). Ultimately you decide what anchors to trust, or delegate that decision to someone (like Microsoft for Windows, Oracle for Java, Mozilla for Firefox, etc).

In OpenSSL all (AFAICS) operations that use certificates, and (optionally) CRLs, verify them, against a truststore of CA (root) certs that you can choose or default. You can also manually (re)verify a cert with the commandline verify utility; see https://www.openssl.org/docs/apps/verify.html . Other tools and programs will do something equivalent, but details vary some.

[1] for comparison, the Netscape protocol SSL Secure Sockets Layer was turned over to IETF where it was slightly modified and enhanced and renamed TLS Transport Layer Security. Although there are technical differences that do matter sometimes (like the recent POODLE vulnerability that affects SSL but is fixed in TLS, at least in correct implementations), for the most part SSL and TLS are functionally the same and people often just say SSL to mean both. Similarly PKCS#7 and CMS are so similar many people use either name for both.

Update 2/06 per comment: If you send a valid chain to a recipient who correctly validates the lowest (leaf) cert using that chain, that will prove whether the chain is valid as received.

If an attacker or fault modifies or deletes any (needed) cert or replaces one with an invalid or wrong cert, the received chain won't validate.
If an uneeded cert (either valid or not) is added it won't be detected, but won't harm security at the recipient either.
If you sent an unneeded cert (or several) and that uneeded cert(s) is modified, deleted or replaced it won't be detected, and won't harm.
If you omitted a needed cert and it is added (particularly an intermediate CA cert is likely to be widely known and available), the recipient won't detect the change, but security will be helped.
If there are multiple valid chains -- as is often the case with public CAs, especially now when many have recently upgraded to one or more of RSA-2k ECC SHA2 -- if you send one chain and it is modified to another chain that is also valid, the recipient won't detect the change. This is the only case I can see where the recipient can be harmed: if there are multiple valid chains but not equally "good" on some metric, like long-term sustainability, the recipient can be tricked into using a worse one.

PKCS#7/CMS can be nested. This is commonly used to both sign and encrypt (aka envelope) but other combinations are possible. If you really care the recipient get the exact chain (or other set) you send, not just a valid chain, you can put the p7b as the content of a second, outer SignedData message. In this case you have another choice: mostly for historical reasons PKCS#7/CMS can generate a "detached" signature, where the SignedData object does not actually contain the data, only the SignerInfo(s) and some metadata like the hash algorithm(s); in this case you must send both chunks of data in a way that the recipient can reliably connect them, e.g. Message12345.dat and Message12345.sig . Alternatively it can "embed" the data in the content slot of the SignedData message; this is probably simpler for your case. OpenSSL commandline can do this just by doing two steps, and much email software can handle the SignedData part or at least its S/MIME variants (which OpenSSL can also do), and the remaining p7b part can be handled by most if not all cert/security software.

RFC 4510 (and 2510) has lots of capabilities and options that I haven't dug through, and I'll readily believe there's something in there that does what you want, but I've never seen any implementation of it. You may well have to write -- and support -- the software at both (or all?) ends yourself.


How to explain to a customer that spamfilters don't catch everything I used to work in a small office which provided basic desktop support for users.

One day I had to answer a call from a very angry customer and he asked for my boss. He wanted to know how could one email slip through their spam filter/network-based antivirus software (if there is such a thing, that's what he claimed), and the attachment got filtered/caught by the antivirus software on his desktop.

Till I could reach my boss I had to tell him that a spam filter is not flawless/perfect and sometimes one email mange to pass.

Also to support my claims, I explained to him Gmail themselves allowed that email to attachment despite that his antivirus software had detected and removed it.

Was my explanation right? How would a security expert deal with this situation?

Your answer is pretty OK, but you could explain the ongoing "game" between spammers and spamfilters a bit more. This makes it understandable why some spam always will find its way to the customer.

Spam filters try to catch all mail that is spam.

Spammers try to create mails that are trusted not to be spam - both by spam filters and by humans.

For spammers, this comes down to creating mails that...

can pass spam filters;
when arrived in the inbox look like legit email so the user opens it;
and then is interesting enough so users click on the link inside to buy something or have malware installed.

Spammers buy spam filters, and test their new spam tactics to see if their mail passes the filter. If the mail passes, they are one step ahead. Then they go out in the wild, send out millions of mails, effectively showing their new tactic. The spam-filter makers notice, and they update their filter. This is an ongoing game. It's similar in the virus industry.

When you see spam that has no links or attachments, it is probably spam to poison filters, to confuse filters, to make it easier to fool them later on.


Why don't we reward users who choose strong passwords? Suppose there is a web property that has some sort of reward system or commodity that its users desire. It could be reputation on Stack Exchange-like sites, rank badges on message boards, or add-on features that are unlocked over time.

I have often seen forms with a "password strength meter" -- as the user enters their password, the bar changes from red to yellow to green to indicate how strong their password choice is. But I have never seen a combination of these two concepts.

Why don't we reward users who pick strong passwords by giving them more rep upfront, or bestowing badges, or unlocking exclusive features? I imagine publicly-viewable badges might not be the smartest move; if there was a bronze badge that could be taken to mean "this user chose the second-weakest complexity" that would divulge way too much info to a potential attacker. (A cursory glance at a user's public profile would reveal which accounts had the weakest passwords, and they'd focus their efforts on the lower-hanging fruit.)

Has anybody ever tried this? Did it work?

EDIT: Would it change anything if the benefit was not publicly advertised? For example, if a bank gave a slightly higher savings account interest rate to users that opted to use an MFA token?

We don't know how to measure the strength of a password, by looking at the password. Of course, there are many tools that purport to be "password strength meters" and give you a nice green colour. However, they are all baloney and do not give you the "true" strength; instead, what the password strength meter tells you is: "assuming the attacker is a chimpanzee, then your password is good".

So while a "red" value from the meter is an interesting information (it tells you: "your password is so poor that even a chimpanzee could break it"), concentrating on getting a "green" result will not get you far. It will, in all generality, make you immune to chimpanzee hackers.

In fact, password strength meters, and even more your proposed badge system, are toxic: they encourage users to find "witty" passwords that go out of the couple of "password rules" embedded in the password meter system. This trains users into trying to reach password security through wit and cunning, the exact opposite of what they should do. Password strength comes from randomness. Randomness cannot be measured from the output.

What could work is a password generator, that uses randomness to suggest a password to users when they choose it. Then they may get the badge if they elect to use that password. If they make another choice, in the privacy of their mind (where randomness is hard to obtain, unfortunately), then they don't get the badge.


Reflected XSS in form action - understanding I am trying to learn basics of web security vulnerabilities.
I have found a website, where on reset password, you get a link in the email with a token, and when you click this link, the webpage opens and the url is reflected in a form action. Something like this:
password reset url: https://target.com/token=q123sefgetrt3dfe
and this is how it is reflected:
<form action="https://target.com/toekn=q123sefgetrt3dfe" method="post">

Based on this, i am trying to figure out if this can lead to reflected XSS. So in the url i tried something like this:
https://target.com/token=q123sefgetrt3dfe"/><script>alert(document.cookie)</script>

so that the form tag is closed, and a script is inserted inside the form.
This reflects in the form action, but with url encoded, so quotes are turned to %22 and angular brackets to %3E.
Does this mean that reflected xss can't be achieved here?
is the browser encoding this , or the web page itself must be encoding this ?
is there a way to bypass to see if there is a vulnerability?

Does this mean that reflected xss can't be achieved here?

The xss can not be achieved here because the context of outbound encoding(URL encoding) is correct which means URL encoding is applied to data reflecting in the URL and as owasp suggests, the outbound encoding is one of the solution for XSS vulnerability.
CSP and xss auditors in browser also plays a role in preventing xss.


Is email sent form a Java web-app over a HTTPS connection encrypted? I'm working on a Java web-application which runs on a HTTPS connection. This application sends emails to its users. I want to protect those emails from man-in-the-middle attacks and other potential threats. My questions are:

Do I need to encrypt my email content? Why and How? Why not?
Doesn't HTTPS encrypt the data transmitted automatically?
If I have to encrypt them manually, how will the receivers decrypt it?
Whatever solution you suggest, what is the likelihood and severity of potential threats?

Assuming that everything is done right (everything, which is not a given especially if one does it oneself), HTTPS still would't protect your email as emails are not using that protocol to be transmitted. Because you actually need to send the actual email to other servers using the "email protocol": SMTP. But even then, this is a bad idea.

For instance, what are these "other servers" exactly? If you recipient is at gmail for instance, you have to send the email to the gmail servers, right? However this is not exactly how SMTP is working: you email will hop from mail servers to mail servers until it reaches its final destination. This connection can be direct but there are no guaranty that it will actually be, far from it. This simple fact makes end-to-end encryption within SMTP impossible by design: each realy/MTA is a MitM! Yes, there were attempts at making SMTP secure but the design is still just bad from a security standpoint. See this Wiki article for instance, especially:

  Mandatory certificate verification is not viable for Internet mail delivery. As a result, most email that is delivered over TLS uses only opportunistic encryption.

Opportunistic here means that it defaults to clear text whenever someone illegitimately wants to read, if anything in the middle is broken, if anything is not configured properly, etc. And the worst is that it's not because your connection to the first relay (called MTA, in the other answer) is actually secure (because you did a good job wasting 8h of you time in configuration and thorough checks) that the connection between that very first relay with the second will be secure. You have no guaranty of that whatsoever (and again, the relays themselves can be evil).

Solutions?

Don't send clear-text emails. Use PGP/GPG, S/MIME or equivalent to crypt your emails if you want secrecy. These provide end-to-end encryption but require a fair bit of configuration from your side and from your user side. To be done properly (and actually provide privacy), you need to manually authenticate each user. This may not be possible.
Another solution would be to use a protocol already designed to be secure which provides end-to-end encryption (some IM protocols are actually quite good for this).
As proposed in the other answer, provide an email with a link to a protected HTTPS page only accessible to authenticated users (a token in the URL won't do).

However, never ever use SMTP (with or without TLS/StartTLS) if you need a guaranty of a minimal amount of privacy. SMTP is not secure.


Behavior when validating an expired certificate chain I have the following situation:

A server certificate (CServ) is signed by self-signed certificate (C0)
A client certificate (CCli) is signed by CServ
Client's trust-store contains C0, so the client application can trust CServ

Note: C0 is actually a simulation of a CA certificate for testing purposes.

Now, let's consider a situation when C0 either is expired or not yet valid. Since it's stored in client's trust-store, is it still trusted? In other words is chain [C0, CServ] still valid?

The trust store seems to contain certificates, but that's an illusion (or a tradition). Technically, a trust anchor, i.e. the basis for the trust in certificate validation, is a name coupled with a public key. It so happens that people found it convenient to store the name and public key as a file with the same format as a certificate; this required some trickeries, such as the "self-signature", which makes no sense but had to be included because the format for a certificate includes a non-optional field for a signature.

At that point, it really depends on the OS/browser internal conventions. Some implementations will look at the "validity dates" in the trust anchor "certificate" and will use them as, indeed, validity dates (i.e. beyond the end of validity date, they will cease to trust that trust anchor, even if it is still "there", in the dedicated store for trust anchors). Some other implementations will ignore these dates altogether. It is really up to each implementation to make these choices, since the standard is silent on the subject.

So you have to test.


Flood of email messages from @attacker.com I've been getting the weirdest email messages for the last 2 days on my personal gmail inbox.

On May 28th, exactly at 4:33 pm BRST I got about 2,000 emails that look exactly the same, here's the original.

Delivered-To: XXXXXX@gmail.com
Received: by 10.58.195.142 with SMTP id ie14csp9116vec;
        Wed, 28 May 2014 17:23:56 -0700 (PDT)
X-Received: by 10.194.48.80 with SMTP id j16mr4624897wjn.44.1401321530931;
        Wed, 28 May 2014 16:58:50 -0700 (PDT)
Return-Path: <482265052@attacker.com>
Received: from WIN-EB12TG1C3GU ([212.68.146.41])
        by mx.google.com with ESMTP id hl6si35599364wjb.55.2014.05.28.16.58.50
        for <XXXXXX@gmail.com>;
        Wed, 28 May 2014 16:58:50 -0700 (PDT)
Received-SPF: none (google.com: 482265052@attacker.com does not designate permitted sender hosts) client-ip=212.68.146.41;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 482265052@attacker.com does not designate permitted sender hosts) smtp.mail=482265052@attacker.com
Received: from wv3550 ([127.0.0.1]) by WIN-EB12TG1C3GU with Microsoft SMTPSVC(7.5.7601.17514);
     Thu, 29 May 2014 02:33:21 +0300
Date: Thu, 29 May 2014 02:33:21 +0300
Subject: 169992b1286fb7bb8701d0129fa8501a
To: XXXXXX@gmail.com
From:482265052@Attacker.com
Return-Path: 482265052@Attacker.com
Message-ID: <WV3550vAdxaQ6shalxy0002f4b7@WIN-EB12TG1C3GU>
X-OriginalArrivalTime: 28 May 2014 23:33:21.0825 (UTC) FILETIME=[367F9910:01CF7ACD]

Attacker Message

I just changed my email address, everything else in untouched. All 2k messages look very similar, arrived at the same minute. The only difference is the from email address and Subject (the numbers look random).

Today, I got yet another chain, this time over 7,000 email. Same methodology but this time with a different message. Here it is:

Delivered-To: XXXXXX@gmail.com
Received: by 10.58.195.142 with SMTP id ie14csp14708vec;
        Fri, 30 May 2014 08:05:10 -0700 (PDT)
X-Received: by 10.180.11.37 with SMTP id n5mr6680977wib.41.1401455833882;
        Fri, 30 May 2014 06:17:13 -0700 (PDT)
Return-Path: <634231594@attacker.com>
Received: from WIN-EB12TG1C3GU ([212.68.146.41])
        by mx.google.com with ESMTP id cw1si4703530wib.7.2014.05.30.06.17.13
        for <XXXXXX@gmail.com>;
        Fri, 30 May 2014 06:17:13 -0700 (PDT)
Received-SPF: none (google.com: 634231594@attacker.com does not designate permitted sender hosts) client-ip=212.68.146.41;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 634231594@attacker.com does not designate permitted sender hosts) smtp.mail=634231594@attacker.com
Received: from wv3550 ([127.0.0.1]) by WIN-EB12TG1C3GU with Microsoft SMTPSVC(7.5.7601.17514);
     Fri, 30 May 2014 16:16:42 +0300
Date: Fri, 30 May 2014 16:16:42 +0300
Subject: ac2ca78349d53cfa502088e3bf537927
To: XXXXXX@gmail.com
From:634231594@Attacker.com
Return-Path: 634231594@Attacker.com
Message-ID: <WV3550kRaulR0GMhT6D00038f43@WIN-EB12TG1C3GU>
X-OriginalArrivalTime: 30 May 2014 13:16:42.0284 (UTC) FILETIME=[65E12EC0:01CF7C09]

I'm back i am Mauritanian im not using vpn or anything to hide my self
i am black from africa as You mister president
won the election we was happy because maybe we hope u will resolve all the problem
in asia africa but lol nothing just ur first jobs there in white house is to protect israel from what ?
who can beat israel
israel had nuclear bomb
plz before u going to leave white house resolve any problem syrian people and palestin and slavery in Mauritania plz do something
thanks

A search on Google returns nothing. What is that? Should I be concerned?

This is a pretty standard "mail bombing", and I'd have expected Google to cotton up to it and prevent most of the emails from reaching you.

However, if you mark them as "spam", Google ought to do just that - several almost-identical emails are a dead ringer for undesired communications.

As for the source, granted that this information may be fake, but

 Return-Path: <634231594@attacker.com>
 Received: from WIN-EB12TG1C3GU ([212.68.146.41])
    by mx.google.com with ESMTP id cw1si4703530wib.7.2014.05.30.06.17.13

at least looks as if it originated at ArtVision hosting in Raanana, Israel.

The computer appears to be a Windows Asus Tablet. You might try writing to support (at) artvision (dot) co (dot) il and ask them whether they have noticed anything, such as an unexplained sluggishness in their unsecured guest WiFi network :-), or a creepy fellow sporting an Asus 12" slate spending time nearby.

Finally as for the "why", it again looks as if we have a very sick/disturbed/incompetent person who writes to you believing he's somehow reaching someone else.

It's difficult to do more than guess without a lot more information.

For example: when you fly abroad, is the plane you travel on usually referred to as "Air Force One"? :-)


Avast can hijack email content sent through Frirefox? The other day I send an email through Gmail in Firefox. Right after I clicked "Send" Avast popped up asking if I wanted to include their signature at the bottom of future emails. Surprised, I accepted and proceeded to send another email.
I was shocked to see that it worked, it actually added their message "This email is virus-free".

Now, my question is, how is that possible?
How can third-party software change email content I'm sending though Gmail with https encryption from Firefox?

You should be aware that most of antiviruses have a full control about the flux of your Internet Browser.
FYI, they even create fake certificates, because they need to decipher the content before sending it to the browser.

Actually, when you install an anti-virus, it copies a top CA cert file into your certificates directory, so all the certificates the anti-virus will create will be accepted.


random-string spam probe messages? For years, we've been receiving messages through our contact form in the following format:

name: vlsyekcz
email: jjthiy@toaagq.com
subject: BdsQiWYlYo
body: 2BLgIr aixfhxcynapd, [url=http://kfsriuqfsuer.com/]kfsriuqfsuer[/url], [link=http://lyiusjazrqvl.com/]lyiusjazrqvl[/link], http://hfxsdwgylvpa.com/

The contact form is a basic HTML  with no anti-robot measures whatsoever (we want to maximize user-friendliness here; we don't believe we should make people who are looking for support jump through any additional hoops).

We have, over the years, received many a hundreds (thousands? we didn't count them) messages like the above. All of them follow the exact same format, string lengths may vary a bit, but other than that, format stays the same.

I've always thought that these messages send to see if a system is vulnerable for something. The URLs point to non-existing domains, so they can't check to see if any of the links get clicked. So, I thought it most likely they are checking our website to see if the unique random strings show up so that they then know that they can post spam messages or something close to that. But it doesn't make sense: if you want to post spam links, why not just post the spam directly and be done with it?

I searched online, found: What is the purpose of "gibberish" comments posted to my blog? and decided to start monitoring our traffic log files.

We have been monitoring for a month now, and the IP numbers that post those messages don't come back for anything else. From what we can tell, this is a fire-and-forget script (unless it is part of a larger bot-net of course; but it seems inefficient to delegate the checking to another node?). Also, as pointed out before, we have been receiving those message for years, so I would expect the system sending those messages to have learned that they have a 0% success rate by now...

Does anyone know anything more about those messages? Are they generated by a known bot-net? Are they generated by some sort of spam tool/package?

thanks,
Monika

It's an automatic probe to see which URL syntax, if any, you support.  They're trying raw HTML, two versions of BBCode, and a bare URL, all with unique URLs.  They'll then scan your site (either directly or indirectly, eg. through Google) to see which ones, if any, have been turned into working links, in order to guide actual spamming.

Since the whole thing is automated and is probably running on a botnet of hijacked computers, perpetual failure doesn't cost them anything.


What is the current state of RFID / NFC security? I'm attempting to do some RFID and NFC cloning and replaying research, as I'm hoping to be able to demo physical security as an attack vector to a few of out clients and prospects.

The downside (ironically) is that from what I can tell, RFID and NFC as a means of physical security (read: office / server room door locks) is relatively secure at this point.

The most recent relevant info I could find was BishopFox's Blackhat 2014 demo.

Yet, their hardware approach seemed more "heavy-duty" than I was planning to have to set up. I was hoping for something less overt.

I was also desperately hoping that the XDA-forums would have some obscure Android NFC exploit I could use, since that seemed "new" enough to be relevant in 2016, but I was shocked to read an overwhelming number of posts saying that current iterations of NFC ID cards aren't even susceptible to cloning.

Even Adam Laurie's most recent public exploit was apparently all the way back in 2010.

So, is RFID and NFC no longer a relevant threat to companies in terms of physical security (read: door locks, ID badges, etc.)?

If so, what current tech has mitigated that risk?
If not, what am I missing / am I living under a rock?

Most proximity card based systems use some variation of ISO 14443 to communicate between the card and the reader, but are not necessarily based on NFC.  (RFID is a rather all-encompassing term, itself covering almost any use of radio waves to identify a target.)  Beyond that, there has been significant evolution in what is sent across the RF.

Many people think of RFID tags that send a single static number when they're interrogated, and these tags do exist -- they're often used for inventory tracking or similar functions.  They're not, however, generally used for access control.  Systems for access control involve challenge-response and cryptography in their operations.

Even the long-broken MIFARE Classic uses cryptography, but it uses an only 48-bit key, and some weaknesses were identified that allow for ciphertext-only attacks or active attacks when talking to the reader.  Since 2015, NXP has recommended new installations not use MIFARE classic.

More modern systems like DESFire EV2 have not yet shown cryptographic weaknesses, but that is no guarantee of long-term strength, it's just not currently possible to clone such a card.  (As you don't have the right keys to talk to the card.)  Of course, if you can get your hands on a legitimate reader with the keys baked in, you can read them, but I believe NXP recommends a per-site key.

Over in the HID side of things, they use a slightly different technology.  HID proxcards (iClass and so forth) have actually been remarkably resilient in general.  iClass was problematic because of a globally shared key -- IIRC, it was originally extracted from a reader that did not use a secure element to store the key.  iClass SE rotated the key and allowed individual sites to reprogram readers to use custom keys.  iClass SEOS actually runs a full JavaCard so can do a number of things with the embedded chip.  At the very least, it will be able to emulate iClass SE (and I believe they've licensed DESFire EV2 and can emulate it as well).

Despite all of that research, very many sites are still using HID iClass, classic Proxcard, or MIFARE Classic for access control.  In the consulting world, you'll see no shortage of opportunities for badge cloning.


How do I create comparable security to PHPmyadmin? I have a website hosted by netfirms, and phpmyadmin is part of the package.

It's a very powerful general tool, but it takes a while to load and there are some very long and specific tasks I need to do weekly.

I could easily write a php page that does all of these tasks for me, but some of these tasks include "changing prices" or "removing products". These are tasks I would not want anyone on the internet to be able to perform.

I know I'll never reach perfect security, but I'd like it to be no worse than it is now.

Ideally I'd like a solution that will work on any computer with internet access I can get a USB stick to. (I don't want to have to run an installer for each new computer.)

PHPMyAdmin is not a security tool, and using it is risky in itself. You log in directly using the database account, with all the privileges the account has. If your task is to update the database, this means write access. Of course you could create a limited database account that has only access to certain tables, but that's not really practical and most likely the hosting company has given you exactly one account with full privileges. If this database account gets compromised, the whole database gets compromised. It's exposed to several risks when your requirement is to be able to work on any computer with Internet access.

Having a separate tool that is limited to certain use cases is recommendable, as it can have an authentication that is totally independent from the database account, and own account for every user. The tool can also have detailed access control over who can update what, and logs for auditing the changes etc.

The cons are that creating such a tool from scratch and making it secure is not an easy task. The authentication might be bypassed, you might leave vulnerabilities for SQL injections or expose the database password with configuration mistakes. Using anything that has been developed for years, is widely used by others and gets regular security updates is preferable.

To achieve both you would look for a widely used ecommerce platform. If you really must perform administrative tasks from external non-trusted computers, it's recommended to have some multi factor authentication.


On Windows, how to restrict access to a folder, sub folder and files to only some applications (not users) We have an application which is not per user and can be used by multiple users simultaneously. Data is also shared by all users.
The path to the data folders we use is ProgramData\OurAppName\Data (post Vista), and we give full control to all users, so that our application run by them can make changes to files under the Data folder.

Now the issue with this is, now any other application (malware/virus) can also modify files -  i.e. an attack can be made on our application's data files. Our applications is a Win32 Desktop application.

Is there any way in which we can restrict access to the Data folder to only our applications?

Applications on Windows Operating Systems run in the context of the user executing it and therefore inherit the ACL of that user.

When looked at abstractly your program is doing nothing more than Word (winword.exe) or Excel (excel.exe) is doing with .doc or .xls files. You shouldn't need to restrict access of the data to only the application, risk reduction comes though:

limiting the users who have access to the data (ACL's, aka file permissions, ideally though a group)
limiting the operations a user can do (e.g. application installation to prevent malware)
application whitelisting
anti-malware protection
auditing for data integrity