This weeks question of the week was asked by user Yoav Aner, who wanted to understand the legal and ethical concerns of executing an attack on a web site which carried a notice inviting attacks. Yoav specifically wanted to know what, if any contractual implications there were and if it were not specified, how far would be too far. This spun off into two further questions – What security measures to have before openly allowing security researchers to hack your site and What security concerns should one bear in mind when hacking open-invitation websites? so this post will look at all three.

Before we start, I must re-iterate: we are security professionals here, not lawyers, so if in doubt, consult a lawyer.

Legal and ethical concerns:

The answer Yoav accepted was provided by Rory McCune, who raised the point that ultimately, a no holds barred approach is extremely unlikely to be acceptable in any circumstance. Rory highlighted the importance of ensuring the page in question was written by the administrators of the site, as opposed to being supplied through user content. Clearly, unless it is clear the page was written by someone with the authority to make that kind of invitation, attacking it would definitely be hostile.

Another excellent point raised in this answer was that some companies actively invite finding bugs in their web sites and products, provided you follow a number of guidelines. More on this can be found in the answer itself.

Finally, Rory touched on what many people may forget – although the website may invite attempted break-ins, it may actually be illegal where you are even to make the attempt.

Our next answer was provided by Security moderator, user and blogger Rory Alsop. According to Rory, one problem when dealing with this kind of issue is that no test cases have yet passed through the courts – so until they do, it’s unlikely any precedent has been established for dealing with these kinds of issues. Rory also raised the criminal activity point again. Always understand that the law of your country/jurisdiction still applies.

Next up, Rory explained that during a penetration test a contract established for the work may include rules about what should happen, how far a test may go, who should be notified if a vulnerability is found etc. Even with this safeguard, there is still the potential for legal action should something break. Rory advised logging absolutely everything that was going on so as to have proof of actions.

When applied to the website scenario, Rory pointed out that in this case there is no signed contract establishing this understanding, just an implication of one which neither party is legally bound to.

That is all for answers on this question. I tend to miss questions on ethics on the main site, so writing them up is actually quite interesting. As such, I am going to summarise the key points below:

1. The rules of engagement are not well established. Assuming a “feel free to hack this message” we have no idea to what extent that is actually what they mean. By contrast, penetration testing is usually better scoped.
2. The author of the page might not have the authority to make such an invitation. As I was reading this, I did wonder – if this is a shared host, the administrator of the site is a different person from the company who owns and maintains the box. So even though the site author can put up this message, they’re not actually entitled to make that call (and it probably violates the ToS on their hosting package).
3. It may be illegal to engage in the act of attempting, whether or not the site in question has given you permission.
4. Some sites actively encourage hunting for bugs.

Security concerns when hacking open-invitation websites:

Iszi raised the following worries on his question

• The site could be a honeypot, run by government or other entities looking to gather information about active (or would-be) hackers.
• The site could be set up by a black-hat as a honeypot to gather a list of interesting, hackable amateurs to target.
• A third-party black-hat could potentially access the site’s logs and farm them for data about interesting, hackable amateurs to target.

Lucas Kauffman confirmed that he had a school project where he faked an open sendmail relay and

just piped all the incoming emails to a python script that got all the destinations out, generating my own spamlist. I think in the end after about 3 weeks I had close to 300.000 different email addresses.

Rory Alsop focused on the reputational and professional risks, as the host of the site will be able to see everything you did in their logs…do you ever mistype commands, use dir instead of ls, accidentally stray outside the scope of the test? This will be recorded and could negatively impact you.

Think about what you are divulging when hacking a website….

• Your methodology
• Your tools
• Your mistakes?
• etc

Finally – Yoav also asked a question focusing on the other side,

What security measures should I have in place before inviting people to hack my website?

Ttfd’s answer went into some considerable detail on the practical logistics – how you think about the problem is probably as important as actually implementing security in this situation:

1. Do you have the money to do that?
2. Do you have the resources? (servers, security teams and etc)
3. How far can you limit the damages a hacker can make to your system? I.E. If a hacker hacks into your server what access will he have ? Will he be able to connect to your database and retrieve/store/update data? Is your data encrypted ? Will he be able to decrypt it? (and so on)
4. Can your security team find how a hacker exploited your system?
5. Does your security team have the skills to fix problems that may occur ?
6. Probably many more questions that you need to ask and answer before you decide.

M15K gave a summarised answer

I can’t imagine very many positive scenarios in declaring open season on you’re front door will result in something useful. But let’s say you do, and you do get some positive feedback. Are you and your security team in a position to remediate those vulnerabilities?

Interesting stuff! All in all, this looks like a relatively risky business on both sides, so core to the decision must be a full understanding of the risks, and how these match to your risk appetite. If you are hosting such a site, you may get some valuable information into attack techniques, but you need to protect yourself from an escalation from the attack environment to your own systems. If you are testing the site, think about the risks you may be facing, and plan accordingly.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com. 

My workplace recently, for some definitions of recent, switched the company we use for certificate signing to InCommon. There were quite a few technical/administrative advantages, and since we’re educational, price was a big factor. Everyone has been really happy with the results. Well, except for this one thing.  InCommon is not a top level trusted CA, they chain through AddTrust. This isn’t actually all that big a deal, really, as AddTrust is a common CA to have in your trusted bundle, and all we had to do was configure the InCommon chain certificate on our web servers. Other than the occasional chain breakage on some mobile browsers everything seemed peachy. Except, that is, when we ran a vulnerability scan.

Shortly after we switched we started noticing some odd alerts coming out of our vulnerability scans. At first one or two were reporting that the SSL certificate could not be validated. We manually verified the certificates, declared them as false positives, and moved on. Over time more and more systems started reporting this error. Eventually the problem had propagated out far enough that I started digging into it. For reference, the PluginID we’re looking at here is 51192.

I learned two very important, and relevant, pieces of information that day:

1. Nessus was not properly validating the chain.
2. Chain Certificate files are a little stranger than expected.

Instead of using a system default CA bundle, Nessus ships with its own. You can find the bundle, called known_CA.inc, in the plugin directory. So on Linux systems you should be looking at /opt/nessus/lib/nessus/plugins/known_CA.inc. If you are using a Windows scanner, well, you’re on your own. This is a fairly standard looking CA bundle, and I found that AddTrust was, in fact, included. I did not, however, find any reference to InCommon. Since they are somehow related to Internet2 I looked for them, also no luck.

This isn’t really that big a deal, though. Nessus will also look for, but will not update, a secondary bundle called custom_CA.inc. In most cases, this file would be used to include a local CA, for instance in a closed corporate network where one generates self-signed certificates as a matter of course. However, since you can use it to include arbitrary CA certs we can use it to fix our problem.

It’s easy enough for me to get the intermediate cert, what with it being public and all. This is where things started to get a little weird, though. In order to stay consistent with the known_CA.inc I included the certificate as a decoded X.509+PEM. Placing only the intermediate cert in this file resulted in, again, the certificate chain failing to validate. Next, what follows is a Nessus debugging tip that was roughly an hour’s worth of swearing in the discovering:

If you don’t think the web interface is showing you sufficient information, look at the plugin output in the raw XML.

You can get this by either exporting the report, or by finding it in the user’s reports folder on the scanner. What I discovered was that all of the various and sundry certificates were being read and validated. The chain, however, was being checked in the wrong order, in this case: webserver->AddTrust->InCommon.

After a little more trial and error I learned that, not only, did I need to have both the InCommon intermediate, but also the AddTrust certificates in my custom_CA.inc file, but that the order of the certs in the file also mattered. As it happens, AddTrust had to be entered first, followed by InCommon. This does make some amount of sense, when I adjusted my thought process to an actual chain where AddTrust was the “top-level”.

For completeness, I copied the newly complete custom_CA.inc file to my test webserver and included it as a chain cert using the SSLCertificateChainFile option. This is Apache httpd on Linux, you nginx or IIS folks are on your own. After removing the custom_CA.inc on the Nessus scanner and re-running the scan resulted in the certificate properly validating.

This left me in a good place in two ways:

1. I now had a properly formatted custom_CA.inc file that I could put into puppet for all the scanners.
2. I now also had a properly formatted chain cert file for inclusion on the web servers.

This fixes the problem from both sides, the server presenting all the correct information, as well as the scanner for cleaning up a false positive. For reference, included below is the chain cert file that was generated. As mentioned previously, it is the same format as a CA bundle. For each certificate you’ll find the ASCII text decoded certificate information, followed by the Base64 encoded PEM version of the same certificate. In my testing, Nessus would accept only the PEM versions, however I wanted to include both outputs since it appears to be the standard.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7f:71:c1:d3:a2:26:b0:d2:b1:13:f3:e6:81:67:64:3e
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: Dec  7 00:00:00 2010 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, O=Internet2, OU=InCommon, CN=InCommon Server CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:97:7c:c7:c8:fe:b3:e9:20:6a:a3:a4:4f:8e:8e:
                    34:56:06:b3:7a:6c:aa:10:9b:48:61:2b:36:90:69:
                    e3:34:0a:47:a7:bb:7b:de:aa:6a:fb:eb:82:95:8f:
                    ca:1d:7f:af:75:a6:a8:4c:da:20:67:61:1a:0d:86:
                    c1:ca:c1:87:af:ac:4e:e4:de:62:1b:2f:9d:b1:98:
                    af:c6:01:fb:17:70:db:ac:14:59:ec:6f:3f:33:7f:
                    a6:98:0b:e4:e2:38:af:f5:7f:85:6d:0e:74:04:9d:
                    f6:27:86:c7:9b:8f:e7:71:2a:08:f4:03:02:40:63:
                    24:7d:40:57:8f:54:e0:54:7e:b6:13:48:61:f1:de:
                    ce:0e:bd:b6:fa:4d:98:b2:d9:0d:8d:79:a6:e0:aa:
                    cd:0c:91:9a:a5:df:ab:73:bb:ca:14:78:5c:47:29:
                    a1:ca:c5:ba:9f:c7:da:60:f7:ff:e7:7f:f2:d9:da:
                    a1:2d:0f:49:16:a7:d3:00:92:cf:8a:47:d9:4d:f8:
                    d5:95:66:d3:74:f9:80:63:00:4f:4c:84:16:1f:b3:
                    f5:24:1f:a1:4e:de:e8:95:d6:b2:0b:09:8b:2c:6b:
                    c7:5c:2f:8c:63:c9:99:cb:52:b1:62:7b:73:01:62:
                    7f:63:6c:d8:68:a0:ee:6a:a8:8d:1f:29:f3:d0:18:
                    ac:ad
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A


            X509v3 Subject Key Identifier:
                48:4F:5A:FA:2F:4A:9A:5E:E0:50:F3:6B:7B:55:A5:DE:F5:BE:34:5D
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies:
                Policy: X509v3 Any Policy

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.usertrust.com/AddTrustExternalCARoot.crl

            Authority Information Access:
                CA Issuers - URI:http://crt.usertrust.com/AddTrustExternalCARoot.p7c
                CA Issuers - URI:http://crt.usertrust.com/AddTrustUTNSGCCA.crt
                OCSP - URI:http://ocsp.usertrust.com

    Signature Algorithm: sha1WithRSAEncryption
        93:66:21:80:74:45:85:4b:c2:ab:ce:32:b0:29:fe:dd:df:d6:
        24:5b:bf:03:6a:6f:50:3e:0e:1b:b3:0d:88:a3:5b:ee:c4:a4:
        12:3b:56:ef:06:7f:cf:7f:21:95:56:3b:41:31:fe:e1:aa:93:
        d2:95:f3:95:0d:3c:47:ab:ca:5c:26:ad:3e:f1:f9:8c:34:6e:
        11:be:f4:67:e3:02:49:f9:a6:7c:7b:64:25:dd:17:46:f2:50:
        e3:e3:0a:21:3a:49:24:cd:c6:84:65:68:67:68:b0:45:2d:47:
        99:cd:9c:ab:86:29:11:72:dc:d6:9c:36:43:74:f3:d4:97:9e:
        56:a0:fe:5f:40:58:d2:d5:d7:7e:7c:c5:8e:1a:b2:04:5c:92:
        66:0e:85:ad:2e:06:ce:c8:a3:d8:eb:14:27:91:de:cf:17:30:
        81:53:b6:66:12:ad:37:e4:f5:ef:96:5c:20:0e:36:e9:ac:62:
        7d:19:81:8a:f5:90:61:a6:49:ab:ce:3c:df:e6:ca:64:ee:82:
        65:39:45:95:16:ba:41:06:00:98:ba:0c:56:61:e4:c6:c6:86:
        01:cf:66:a9:22:29:02:d6:3d:cf:c4:2a:8d:99:de:fb:09:14:
        9e:0e:d1:d5:c6:d7:81:dd:ad:24:ab:ac:07:05:e2:1d:68:c3:
        70:66:5f:d3
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIQf3HB06ImsNKxE/PmgWdkPjANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEwMTIwNzAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
UTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UECxMISW5D
b21tb24xGzAZBgNVBAMTEkluQ29tbW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAJd8x8j+s+kgaqOkT46ONFYGs3psqhCbSGErNpBp
4zQKR6e7e96qavvrgpWPyh1/r3WmqEzaIGdhGg2GwcrBh6+sTuTeYhsvnbGYr8YB
+xdw26wUWexvPzN/ppgL5OI4r/V/hW0OdASd9ieGx5uP53EqCPQDAkBjJH1AV49U
4FR+thNIYfHezg69tvpNmLLZDY15puCqzQyRmqXfq3O7yhR4XEcpocrFup/H2mD3
/+d/8tnaoS0PSRan0wCSz4pH2U341ZVm03T5gGMAT0yEFh+z9SQfoU7e6JXWsgsJ
iyxrx1wvjGPJmctSsWJ7cwFif2Ns2Gig7mqojR8p89AYrK0CAwEAAaOCAXcwggFz
MB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBRIT1r6
L0qaXuBQ82t7VaXe9b40XTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB
/wIBADARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMIGz
BggrBgEFBQcBAQSBpjCBozA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1
c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QucDdjMDkGCCsGAQUFBzAChi1o
dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RVVE5TR0NDQS5jcnQwJQYI
KwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEF
BQADggEBAJNmIYB0RYVLwqvOMrAp/t3f1iRbvwNqb1A+DhuzDYijW+7EpBI7Vu8G
f89/IZVWO0Ex/uGqk9KV85UNPEerylwmrT7x+Yw0bhG+9GfjAkn5pnx7ZCXdF0by
UOPjCiE6SSTNxoRlaGdosEUtR5nNnKuGKRFy3NacNkN089SXnlag/l9AWNLV1358
xY4asgRckmYOha0uBs7Io9jrFCeR3s8XMIFTtmYSrTfk9e+WXCAONumsYn0ZgYr1
kGGmSavOPN/mymTugmU5RZUWukEGAJi6DFZh5MbGhgHPZqkiKQLWPc/EKo2Z3vsJ
FJ4O0dXG14HdrSSrrAcF4h1ow3BmX9M=
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:f7:1a:33:e6:f2:00:04:2d:39:e0:4e:5b:ed:
                    1f:bc:6c:0f:cd:b5:fa:23:b6:ce:de:9b:11:33:97:
                    a4:29:4c:7d:93:9f:bd:4a:bc:93:ed:03:1a:e3:8f:
                    cf:e5:6d:50:5a:d6:97:29:94:5a:80:b0:49:7a:db:
                    2e:95:fd:b8:ca:bf:37:38:2d:1e:3e:91:41:ad:70:
                    56:c7:f0:4f:3f:e8:32:9e:74:ca:c8:90:54:e9:c6:
                    5f:0f:78:9d:9a:40:3c:0e:ac:61:aa:5e:14:8f:9e:
                    87:a1:6a:50:dc:d7:9a:4e:af:05:b3:a6:71:94:9c:
                    71:b3:50:60:0a:c7:13:9d:38:07:86:02:a8:e9:a8:
                    69:26:18:90:ab:4c:b0:4f:23:ab:3a:4f:84:d8:df:
                    ce:9f:e1:69:6f:bb:d7:42:d7:6b:44:e4:c7:ad:ee:
                    6d:41:5f:72:5a:71:08:37:b3:79:65:a4:59:a0:94:
                    37:f7:00:2f:0d:c2:92:72:da:d0:38:72:db:14:a8:
                    45:c4:5d:2a:7d:b7:b4:d6:c4:ee:ac:cd:13:44:b7:
                    c9:2b:dd:43:00:25:fa:61:b9:69:6a:58:23:11:b7:
                    a7:33:8f:56:75:59:f5:cd:29:d7:46:b7:0a:2b:65:
                    b6:d3:42:6f:15:b2:b8:7b:fb:ef:e9:5d:53:d5:34:
                    5a:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
                DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
                serial:01

    Signature Algorithm: sha1WithRSAEncryption
        b0:9b:e0:85:25:c2:d6:23:e2:0f:96:06:92:9d:41:98:9c:d9:
        84:79:81:d9:1e:5b:14:07:23:36:65:8f:b0:d8:77:bb:ac:41:
        6c:47:60:83:51:b0:f9:32:3d:e7:fc:f6:26:13:c7:80:16:a5:
        bf:5a:fc:87:cf:78:79:89:21:9a:e2:4c:07:0a:86:35:bc:f2:
        de:51:c4:d2:96:b7:dc:7e:4e:ee:70:fd:1c:39:eb:0c:02:51:
        14:2d:8e:bd:16:e0:c1:df:46:75:e7:24:ad:ec:f4:42:b4:85:
        93:70:10:67:ba:9d:06:35:4a:18:d3:2b:7a:cc:51:42:a1:7a:
        63:d1:e6:bb:a1:c5:2b:c2:36:be:13:0d:e6:bd:63:7e:79:7b:
        a7:09:0d:40:ab:6a:dd:8f:8a:c3:f6:f6:8c:1a:42:05:51:d4:
        45:f5:9f:a7:62:21:68:15:20:43:3c:99:e7:7c:bd:24:d8:a9:
        91:17:73:88:3f:56:1b:31:38:18:b4:71:0f:9a:cd:c8:0e:9e:
        8e:2e:1b:e1:8c:98:83:cb:1f:31:f1:44:4c:c6:04:73:49:76:
        60:0f:c7:f8:bd:17:80:6b:2e:e9:cc:4c:0e:5a:9a:79:0f:20:
        0a:2e:d5:9e:63:26:1e:55:92:94:d8:82:17:5a:7b:d0:bc:c7:
        8f:4e:86:04
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----

Asked over on Programmers in January, this question is our 5th highest rated of all time, so it’s obviously resonating with our community.

With businesses the world over reliant on the accuracy, availability and integrity of IT systems and data this type of request demonstrates not only unethical behaviour, but a willingness on the part of the boss to sacrifice the building blocks used to ensure their business can continue.

Behaviour like this, if discovered by an audit team, could lead to much wider and deeper audits being conducted to reassure them that the financial records haven’t been tampered with – never mind the possible legal repercussions!

Some key suggestions from our community:

MarkJ suggested getting it in writing before doing it, but despite this being the top answer, having the order in writing will not absolve you from blame if you do actually go ahead with the action.

Johnnyboats advised contacting the auditor, ethics officer or internal council, as they should be in a position to manage the matter. In a small company these roles may not exist, however, or there may be pressure put upon you to just toe the line.

Iszi covered off a key point – knowing about the boss’s proposed unethical behaviour and not reporting the order could potentially put you at risk of being an accessory. He suggests not only getting the order in writing, but contacting legal counsel.

Sorin pointed out that as getting the order in writing may be difficult, especially if the boss knows how unethical it is, the only realistic option may just be to CYA as best you can and leave quietly without making a fuss.

Arjang came at this from the other side – perhaps the boss needs help:

This is not just a case of doing or not doing something wrong cause someone asked you to do it, it is a case of making them realize what they are asking

I am pretty cynical so I’m not sure how you’d do this, but I do like the possibility that the best course of action may be to provide moral guidance and help the boss stop cheating.

Most answers agree on the key points:

• Don’t make the requested changes – it’s not worth compromising your professional integrity, or getting deeper involved in what could become a very messy legal situation.
• Record the order – so it won’t just be your word against his, if it comes into question.
• Get legal counsel – they can provide advice at each stage.
• Leave the company – the original poster was planning to leave in a month or so anyway, but even if this wasn’t the case, an unethical culture is no place to have your career.

The decision you will have to make is how your report this. At the end of the day, a security professional does encounter this sort of thing far too regularly, so we must adhere to an ethical code. In fact, some professional security certifications, like the CISSP, require it!

Liked this question of the week? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

ZM15 asked this interesting question just before Christmas over on Superuser. It came over to Security Stack Exchange for some security specific input and I was delighted to see it, as I have done a fair bit of work in the practical elements of securing communications – so this blog post may be a tad biased towards my experiences.

For those not in the know, Powerline ethernet is a technology which allows you to transmit ethernet over your existing mains wiring – which is very useful for buildings which aren’t suitable for running cabling, as all you need to do is pop one of these where you want to connect a computer or other ethernet enabled device and they will be able to route TCP/IP packets. There are some caveats of course, the signal really only works on a single phase, so if you have multiple phases in your house the signal may not travel from one to another, although as DBasnett commented, to get around this, commercial properties may inject the signal deliberately onto all phases.

 Early Powerline adapters had very poor signal quality – noise on the mains caused many problems – but since then the technology has improved considerably, partly through increasing the signal strength, but also through improving the filters which allow you to separate signal from mains.

This is where the security problem lies – that signal can travel quite far down wires, and despite fuse boxes offering some resistance to signals, you can often find the signal is retrievable in the neighbour’s house. Damien answered:

I have experienced the signal bleed from my next door neighbor. I … could identify two other powerline adapters using the same network name. I got anywhere between 10 to 20Mbps of throughput between their adapters and mine. I was able to access their router, watch streaming video and see the computers on the network. I also noticed they had gotten IPs on my router also.

This prompted him to enable security.

Tylerl gave an excellent viewpoint, which is as accurate here as it has ever been:

Many of the more expensive network security disasters in IT have come from the assumption that “behind the firewall” everything is safe.

Here the assumption was that the perimeter of the house is a barrier, but it really isn’t.

Along even weirder lines, as is the way with any electrical signal, it will be transmitted to some degree from every wire that carries it, so if you have the right equipment you may be able to pick up the traffic from a vehicle parked on the street. This has long been an issue for organisations dealing in highly sensitive information, so various techniques have been developed to shield against these transmissions, however you are unlikely to have a Faraday cage built into your house. (See the article on TEMPEST over on Wikipedia or this 1972 NSA document for more information)

For similar wireless eavesdropping, read about keyboards, securing physical locations, this answer from Tom Leek and this one from Rook – all pointing out that to a determined attacker, there is not a lot the average person can do to protect themselves.

Scared yet?

Well, unless you have attackers specifically targeting you, you shouldn’t be, as it is very straightforward to enable security that would be appropriate for most individuals, at least for the foreseeable future. TEMPEST shielding should not be necessary and if you do run Powerline ethernet:

Most Powerline adapters have a security option – simply encryption using a shared key. It adds a little overhead to each communication, but as you can now get 1Gb adapters, this shouldn’t affect most of us. If you need >1Gb, get your property wired.

Liked this question of the week? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Are you a systems administrator of professional computer systems? Well, serverfault is where you want to be and that’s where this week’s question of the week came from.

New user mucker wanted to understand why, if hashing is just an algorithm, it cannot simply be reverse engineered. A fair question and security.SE as usual did not disappoint.

Since I’m a moderator on crypto.se this question is a perfect fit to write up, so much so I’m going to take a slight detour and define some terms for you and a little on how hashes work.

A background on the internals of hash functions

First, an analogy for hash functions. A hash function works one block of data at a time – so when you hash your large file, the hash function takes so many blocks (depending on the algorithm) at once. It has an initial state – i.e. configuration – which is why sha of nothing actually has a value. Then, each set of incoming blocks alter those values. (Side note: collision resistance is achieved like this).

The analogy in this case is like a bike lock with twisty bits on. Imagine the default state is “1234” and every time you get a number, you alter each of the digits according to the input. When you’ve processed all of the incoming blocks, you then read the number you have in front of you. Hash functions work in a similar way – the state is an array and individual parts of it are shifted, xor’d etc depending on each incoming block. See the linked articles above for more.

Then, we can define input and output of two things: one instance of the hash function has inputs and outputs, as does the overall process of passing all your data through the hash function.

The answers

The top answer from Dietrich Epp is excellent – a simple example was provided of a function – in this case multiplication – which one can do easily forwards (O(N^2)) but that becomes difficult backwards. Factoring large numbers, especially ones with large prime factors, is a famous “hard problem”. Hash functions rely on exactly this property: it is not that they cannot be inverted, it is just that they are hard.

Before migration, Serverfault user Coredump also provided a similar explanation. Some interesting debate came up in the comments of this answer – user nealmcb observed that actually collisions are available in abundance. To go back to the mathsy stuff – the number of inputs is every possible piece of data there is, whereas for outputs we only have 256 bits of data.  So, there are many really long passwords that map to each valid hash value, but that still doesn’t help you find them.

Neal then answered the question himself to raise some further important issues – from a security perspective, it is important to not think of hashes as “impossible” to reverse.  At best they are “hard”, and that is true only if the hash is expertly designed.   As Neal alludes to, breaking hashes often involves significant computing power and dictionary attacks, and might be considered, to steal his words, “messy” (as opposed to a pretty closed-form inverted function) but it can be done.  And all-too-often, it is not even “hard”, as we see with both the famously bad LanMan hash that the original poster mentioned, and the original MYSQL hash.

Several other answers also provided excellent explanations – one to note from Mikeazo that in practise, hash functions are many to one as a result of the fact there are infinite possible inputs, but a fixed number of outputs (hash strings). Luckily for us, a well designed hash function has a large enough output space that collisions aren’t a problem.

So hashes can be inverted?

As a final point on hash functions I’m going to briefly link to this question about the general justification for the security of block ciphers and hash functions. The answer is that even for the best common hashes, no, there is no guarantee of the hardness of reversing them – just as there is no cast iron guarantee products of large primes cannot be factored.

Liked this question of the week? Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

Rather than focus on a specific question this week, we have 9 questions related to the destruction of data, 5 of which are specifically interested in destroying hard drives, as in this modern age where everything is recorded, there are good reasons for ensuring data is deleted when required.

So this post will concentrate on destroying the the drive itself. For the deletion of data from a storage device, have a look at our blog post for Question of the week number 4: How can you reliably wipe data from a storage device?

Matthew Doucette asked simply: How do you destroy an old hard drive?

To which Scott Pack produced the following incredibly detailed answer:

When it comes to drive destruction you typically see one of two main fields:

1. Disk Degaussing
2. Physical Destruction

Degaussing

Degaussing used to be the norm, but I am not such a big fan. On the plus side it is fast, you’ll normally just dump the disks on a conveyor belt and watch them get fed through the device. The problem is auditability. Since the circuitry is rendered wobbly, you won’t be able to do a spot check of the drives and verify that the data is gone. It is possible, with some level of probability unknown to me, that data could still exist on the platters. Retrieving the data would, without question, be difficult, but the fact still remains that you cannot demonstrate the data is actually gone. As such, most companies now will actually be doing physical destruction.

Physical Destruction

At the low end, say a small box of drives at a time, you’ll have hard drive crushers. They’re often pneumatic presses that deform the platters beyond useful recognition. At the risk of supporting a specific product, I have personally used this product from eDR. It works well, and is very cathartic.

At a larger scale, say dozens or hundreds of disks, you’ll find large industrial shredders. They operate just like a paper shredder, but are designed to process much stiffer equipment. The mangled bits of metal that are left over are barely identifiable as hard drives.

At an even larger scale you can start looking at incinerators that will melt the drives down to unidentifiable lumps of slag. Since most electronics can produce some rather scary fumes and airborne particulates, I would not recommend doing this on you own. No, this is not a good use of your chiminea.

Manual Dis-assembly

If you are dealing with one or two drives at a time, then simple dis-assembly might be sufficient. Most drives these days are largely held together with torx screws, and will come apart with varying levels of difficulty. Simply remove the top cover, remove the platters from the central spindle. Taking a pocket knife, nail file, screwdriver, whatever, have fun scoring both surfaces of each platter. Then dispose of the materials appropriately. I cannot speak to how recoverable the data is afterwards, but it is probably sufficient. The biggest thing to keep in mind is that while most desktop hard drive platters are metal, some are glass. The glass ones shatter quite extravagantly.

Additional Considerations

Before you decide on a destruction method, make sure to identify what kind of data is stored on each device and treat it appropriately. There may be regulatory or legal requirements for information disposal depending on what data is stored on the disk. As an example, see section 8-306 of DoD 5220.22-M.

For hard drive destruction, DoD 5220.22-M section 8-306 recommends: “Disintegrate, incinerate, pulverize, shred, or melt”

All that being said, performing a single pass zero wipe is probably sufficient for your purposes. Modern research indicates that modern hard drives are largely immune to the “magnetic memory” problem we used to see on magnetic tape. I would never bother doing anything more on a household drive unless the drive itself was exhibiting failures

Ryan M asked a very similar question – What is the best method of retiring hard drives?

And Scott also gave these 2 excellent points in his answer:

Electrical Scrambling

In the olden days when you had a room packed with tape there were few things better than a big honkin’degausser for making sure that you knew what left the room. As hard drives supplanted tape, their use simply got transferred to the new medium. The biggest advantage to using a degausser to take care of hard drives is speed. Just pass a box through the unit, ignore the jiggling in your fillings, and walk away with clean drives. The downside is the lack of ability to audit data destruction. As discussed in the Wikipedia article, once a hard drive is degaussed, the drive is mechanically unusable. As such, one cannot spot check the drive to ensure cleanliness. In theory the platters could be relocated to a new device and we cannot state, categorically, that the data will not be accessible.

Wanton Destruction

This is without question my favorite. Not only because we demonstrate, without question, that the data is gone, but the process is very cathartic. I have been known to take an hour or so, dip into the “To Be Destroyed” bin, and manually disassemble drives. For modern hard drives all you need is a torx set and time (possibly pliers). While one will stock up on their magnet collection, this method of destruction is very time consuming. Many companies have developed equipment specifically for hard drive destruction en-masse. These range from large industrial shredders to single unit crushers such as this beauty from eDR. I have personally used that particular crusher, and highly recommend it to any Information Security professional who has had a bit of a rough day.

I’m thinking if I ever need to destroy hard drives, I’ll either blow them up / give them to my kids / use them for target practice or ask Scott to have fun with them.

Dan Beale points out that exactly what approach you take depends on:

• how sensitive is the information
• how serious are the attackers
• do you need to follow a protocol
• do you need to persuade other people the data has gone

Auditability is essential if you are susceptible to regulations around data retention and destruction, and for most organisations this will be essential around regulations such as the Data Protection Act 1998 (UK), GLB or HIPAA (US) and others.

Slightly later than officially planned, question of the week number 17, a weekly feature on security stack exchange is a rather unusual but very interesting choice. We’ve featured it by community votes – and because it’s an interesting study of “how to think about security”.

So, without further ado, Security.SE member Incognito asked: What would one need to do in order to hijack a satellite?.

I did warn you! Well, never fear, it turns out our members know exactly how to do it! So without further ado:

Overview

In terms of radio communications security, most satellite communications systems are repeaters, accepting communication from the highest strength incoming signal at will. Most satellites then contain a command module to order the satellite to perform certain actions as necessary. Due to the highly custom nature of individual satellites, the commands that are accepted and the security for them is highly variable, so there’s a lot of potential for exploitation. As one of our answerers puts it:

When it comes to satellites, the word general does not apply.

Legal Concerns

As a result of the wide variety of frequencies and power requirements in use, chances are, attempting to send commands to a satellite are likely to violate local radio laws – as such, we do not recommend it (although we find the study of security very interesting, all the same).

Finding and talking to a satellite

Clearly, if you’re going to communicate with a satellite, you need equipment with sufficient power and range. You’ll need to be aware of the carrier frequency, the maximum satellite range, the data rate and satellite transmitter power. The location and altitude of satellites also matters – some are geostationary and as such are always in range, while others orbit and may only be in range for a specific period of time. Directional antennas with tracking motors will help an awful lot if the satellite changes position at all. Our answers provide even more detailed radio advice and links, so if you’re interested in your radio, do have a read!

Taking control of a satellite

There are several means by which you can take control of a satellite:

1. Direct comms: If you have identified your target satellite, the most obvious method would be to communicate directly with it, sending it the commands you desire. Depending on the satellite you target your options will vary. You’ll need to be aware of the protocol and options available to you.
2. MITM: One option for hijacking a satellite is to identify its command and control – the ground station – and intercept its communications. If you can afford to rent a small plane and can fly it over the site, possibly allowing you an advantage.

Doing it legally

It may be possible to purchase satellite time, depending on who you ask – and as such it may be possible to legitimately control a satellite, even if only for a brief period!

The expensive way

Many of the answers given focused on the radio communication protocols – however, Security.SE member and former moderator Graham Lee highlighted the physical security of satellites as a major concern – the only problem being the cost of getting into space. If you can, being able to nudge the satellite is enough to deny service by altering the antenna direction – you may be able to exploit it in other ways, whilst you’re up there. Of course, you don’t need to go up there yourself necessarily – a rocket will do the job adequately well and apparently doesn’t even need explosives!

Summary

Satellite security is an interesting area with many concerns that has perhaps been overlooked in our focus on the security of online stores and the like. Thankfully, people are looking at the security of communications systems that rely on satellites!

This QotW writeup relied on answers from Jeff Ferland, this.josh and Graham Lee primarily. Thanks to all our answerers on this particular question for providing their insights!

Can you improve on these answers? Feel free to visit the question and provide additional detail!

This week’s blog post was inspired by camokatu‘s question on what to do when a Utility company doesn’t hash passwords in their database.

It seems the utility company couldn’t understand the benefit of hashing the passwords. Wizzard0 listed some reasons why they might not want to implement protection – added complexity, implementation and test costs, changes in procedures etc. and this is often the key battle. If a company doesn’t see this as a risk they want to remediate, nothing will get done. And to be fair, this is the way business risk should be managed, however here it appears that the company just hasn’t understood the risks or isn’t aware of them.

Obviously the consequences of this can range from minimal to disastrous, so most of the answers concentrate on consequences which could negatively impact the customer, and the main one of these is where the database includes financial information such as accounts, banking details or credit card details.

The key point, raised by Iszi, is that if personally identifiable information is held, it must be protected in most jurisdictions (under data protection acts), and if credit card details are held, the Payment Card Industry Data Security Standard (PCI-DSS) requires it to be protected. (For further background information check out the answers to this question on industry best practices). These regulations tend to be enforced by fining companies, and the PCI can remove a company’s ability to use credit card payments if they fail to meet PCI-DSS.

Does the company realise they can be fined or lose credit card payments? Maybe they do but have decided that is an acceptable risk, but I’d be tempted to say in this case that they just don’t appear to get it.

So when they don’t get it, don’t care, or won’t respond in a way that protects you, the customer, what are your next steps?

from tdammers – responsible disclosure :

Contact the company, offer to keep the vulnerability quiet for a limited amount of time, giving them an opportunity to fix it.

In the meantime, make sure you’re not using the compromised password anywhere else, make sure you don’t have any valuable information stored on their systems, and if you can afford to, cancel your account.

from userunknown –

contact their marketing team and explain what a PR disaster it would be if the media learnt about it (no, I’m not suggesting blackmail…:-)

from drjimbob – 3 excellent suggestions:

Submit it to plaintext offenders?

Switch to another utility company?

Lobby your local politicians to pass legislation that companies that do not use secure hashes (e.g., bcrypt or at very least salted hash) on their password data are liable for identity theft damages from any compromise of their systems?

But in addition to those thoughts, which at best will still require time before the company does anything, follow this guidance repeated in almost every question on password security and listed here by Iszi –

Use long and complex passwords for all websites & applications, and do not re-use passwords across any websites & applications. Additionally, limit the information you give these websites & applications to only that which is absolutely necessary for them to serve their purpose

You may have noticed all the blacked out sites on the Internet on the 18th of January, but possibly aren’t aware of why they were doing this. The answer is SOPA – the poorly named “Stop Online Piracy Act”

In itself, that sounds fine, right? We want to cut piracy so this must be good. Well, no.

We already have laws in many countries which already allow us to take down websites hosting pirated content, but in many countries the process is one of “Innocent until proven guilty” – this means evidence needs to be provided, legal processes have to take place, and a court can rule that a website must be shutdown. The DMCA lets the US do that.

What SOPA does is change the balance to “Guilty until proven innocent” – which means that a website can be taken down just because of an allegation of copyright infringement.

For StackExchange, for example, occasionally people post plagiarised content. We rely on the community flagging this content, and moderators then remove it as fast as possible. (Look at Joel’s answer to this question to see the full process under DMCA and how this protects StackExchange legally). If SOPA was in force, StackExchange would be in danger of being removed from the Internet for any violation as it would be seen as guilty.

And this holds true for websites large and small – personal blogs, comics, Wikipedia, Reddit, Google and many others.

What is also very worrying is the US’s history of going after individuals in other countries citing US law, when those individuals have no connection to the US. See Richard O’Dwyer’s case – while what he did may have been used for nefarious purposes, all he really provided was links to other websites, and yet the US have forced the UK to extradite him. With a significant portion of the Internet under some US control, it wouldn’t be stretching the truth to assume this US bill would affect many other countries.

Another outcome if SOPA came into force would be an acceleration of businesses away from networks owned or controlled by the US, which may directly lead to greater piracy threats.

The Electronic Frontier Foundation – a strong force for free speech on the Internet has this handy guide to SOPA. 

So why didn’t StackExchange join the blackout? – see this answer:  the content is owned by the community, so the entire community would have had to agree on the blackout.

Have a look at this video by Fight for the Future or this awesome TED talk for some further info.

This week’s question was asked by mdegges – What is the difference between $200 and $1,000+ firewalls?

This sparked some interesting discussion, as well as making me think quite deeply about it. In general, like many other IT people, I see enterprise level firewalls in my day job and run cheap SoHo firewalls for my home network and while it makes sense at these two extremes that there would be cost differences, what are the actual differences in practical terms?

tylerl flagged the two most important differentiating factors for an enterprise, and they aren’t even security features

• bandwidth
• latency

In addition Paul listed the number of concurrent connections as a third factor. Again, this is not a security feature.

For an organisation with thousands of connections or large data flow this makes perfect sense – you can’t allow the security device to become a bottleneck which hampers your business.

So does this just mean that you are paying for the firewall to be faster?

No –  there is more to it than that:

SoHo firewalls tend to be very simple – applying rules based on source or destination address, port and protocol, sometimes with some intelligence around matching responses to requests, whereas enterprise-grade firewalls often have deep inspection capability. tylerl gave some good comments around this functionality.

Paul also described the different frameworks – with home firewalls usually being single function devices, and enterprise firewalls providing multiple features dependent on licence, including IPSec, VPN etc.

David also pointed out a final factor that is very important for large organisations – availability. So firewalls at this level need to have High Availability or cluster capability to minimise downtime.

As a quick summary then, the difference is mostly about speed, with a few extra security capabilities.

If you have more information on other differences, please add an answer of your own over on http://security.stackexchange.com/q/9409/what-is-the-difference-between-200-and-1-000-firewalls