What risk do International Domain Names (IDN) pose? I understand that IDN's are basically a GUI display change for domains that have a prefix of "xn--".

What should I advise companies do in regards to these domains?

For example, should companies actively seek out and register domains in alternative (similar looking) character sets? What tools, or logic should be followed?

Are there any known certificate validation issues?

The most risky are so called IDN-spoofing attacks that are possible due to visually similar symbols. That is some side-effect when trying to introduce Unicode.

Regarding this topic I can recommend official Unicode consortium technical report: http://www.unicode.org/reports/tr36/, titled Unicode Security Considerations and article on Wikipedia: http://en.wikipedia.org/wiki/IDN_homograph_attack, and some more interesting reading: http://www.lookout.net/test-cases/idn-and-iri-spoofing-tests/.

Also, as addendum - FireFox extension to protect yourself: https://addons.mozilla.org/en-US/firefox/addon/621/.


Use one subkey for signing + encrypting I'm phasing out my old OpenPGP key and am creating a new one. I plan to lock away the main key and do daily work only with subkeys.

The subkeys will be valid for a year and I'll add new ones after that time.

Should I make one subkey each year that is used for both signing and encryption (RSA keys support that)?
The alternative would be to have two keys, one for each task.

There is a question about that in general, but I don't think it applies to me:

I'm specifically talking about OpenPGP/GnuPG
Key escrow at work is no problem since I only use the key for private communication

If the answer is "potentially insecure" - does this hold for RSA OpenPGP keys? Why?

You're right, a single RSA key pair supports both signing and encryption; all restrictions are imposed by key flags configured during key creation time. Other public/private cryptography algorithms only allow one or the other action because of technical reasons (for example, DSA for signature and el-gamal for encryption).

The reasons in the linked Q&A apply also to OpenPGP. On one hand, you have key management advantages like individual key escrow. Generally, by "reusing" the same key, you might enable (known or yet unknown) attacks on the key that would not have been possible otherwise.

All in all, you have some benefits of using distinct keys for encryption and signature, at the same time OpenPGP takes all the hassles in maintaining multiple subkeys. The costs mostly boil down to some additional kilobytes added to your key and a negligible amount of computation time for creating the keys. Apart from running addkey twice, there is no additional administrative effort in creating a second key pair.

Considering there are some advantages (or at least might prevent possible attacks) for no costs, I do not see any reason not to create a second subkey pair.


Should I remove all non-FIPS providers from java.security to be FIPS-compliant? I was tasked to implement FIPS certified providers in Java in our Docker images. We are going with Bouncy Castle's bc-fips. I see many providers listed in java.security:

security.provider.1=SUN
security.provider.2=SunRsaSign
security.provider.3=SunEC
security.provider.4=SunJSSE
security.provider.5=SunJCE
security.provider.6=SunJGSS
security.provider.7=SunSASL
security.provider.8=XMLDSig
security.provider.9=SunPCSC
security.provider.10=JdkLDAP
security.provider.11=JdkSASL
security.provider.12=SunPKCS11

Should I remove all other providers and add only the two the Bouncy Castle provides to be FIPS compliant?

Based on the Bouncy Castle user guide, you can definitely update the security providers list to include BC FIPS.

As the JSSE requires the presence of the SUN provider in FIPS mode,
the minimal static provider configuration to support the JSSE is:
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS
security.provider.3=sun.security.provider.Sun

If you remove other entries, then "other" Java programs in your Docker container won't be able to use those security providers. If everything uses the BCFIPS provider, it makes sense to remove others.


Phone call to try and gain access About a hour ago I received a call from a suspicious phone number. They explained that they had received an alert from my PC and needed to gain access to correct the problem before my PC was "downloaded" which was getting ready to start in a few minutes. I played along and they walked me to the event viewer where they proceeded to ask me to open the Administrative Events and asked me to see if there were any warnings or errors because this was supposed to show me that I was indeed already infected and they were there to help. At this point the phone was passed to another person on their end that didn't speak with as heavy an accent and then they muffled the phone and began to argue, at which time I hung up. After I hung up they called back a couple of minutes later but I didn't bother to answer.

My question is, now that I have this number whats the chance that it was spoofed, the number is from Saint Paul, Minnesota area. Also, has anyone come across this before and what was it they were going to ask me to do next to try and access my PC? I might be able to put something in place to lock out any other attempts. I wish so bad I had kept them on the line longer.

As an update, not much of an edit, I think what I found was in the second answer with the honey pot idea. Thank you Andre for the suggestion.

This is a basic and quite popular scam that uses social engineering to make gullible people believe there's something wrong with their computer in order to sell them some fake security solution and/or possibly steal data from the machine in the process.

The scammers are often based in India and use VoIP providers to call at cheap rates and appear as a local number, and for card processing they obviously use shady payment gateways that don't mind this illegal activity.

Most of the social engineering works by making the user open the event viewer and telling him that the errors in there (which are often benign and to be expected on such a complex OS like Windows with so much services running) are critical and mean that remote attackers are trying to take over the computer. They will then get the user to download a Remote Desktop server like TeamViewer (but TV has a warning specifically against these social engineering attacks so they fall back to some other, less known remote desktop solutions that have no such warnings) to take control of the computer and further show that the machine is in bad shape, sometimes by opening a command prompt and copy/pasting some command that produces lots of output with something scary appended at the end like the "tree" command with the text Warning: computer infected. Attacker's IP: 192.168.1.1 after it, which causes the window to list every single file of the system and display the text at the end as if it was part of the command's output, which unfortunately is an effective scare tactic. Once the user is convinced they make him go to their webpage to buy a solution which is often a fake security product, and assuming that's done I suppose they either just leave or install a rogue (fake antivirus). Note that most remote desktop services include a way to silently transfer files that can be used to exfiltrate confidential data from the victim's computer in addition to exfiltrating their money.

There are a lot of these scam calls posted on YouTube, you can look up "tech support scam" on there if you want. You can also play with them by setting up a virtual machine; just try to make it a bit fun (like creating actual malware, disguising it as a "passwords.txt.exe" with a text document icon and hope the idiots steal the file and run it on their computer).


FIPS 201(-2): Central requirements for PIV? I was recentely asked in the comments on some details on tamper-proofing of a smartcard in question. The term "FIPS-201" was used to specify what kind of details was needed.

I understand that FIPS 140-2 defines four levels of hardware (/software) security for smartcards / software / HSMs for these devices to protect, use and manage keys.

When "asked" for FIPS-201, Wikipedia says that this is a set of requirements for personal identity validation (PIV). So a piece of soft-/ hardware can either be FIPS-201 compliant or not.

But none of the pages stated what those requirements actually are, hence my question:

What are the central requirements for PIV as per FIPS-201?

Here is a link to the FIPS 201 document on NIST's website.

This is pulled from the linked document and might directly answer your question:

The PIV Card shall contain security features that aid in reducing counterfeiting, are resistant to tampering, and provide visual evidence of tampering attempts. At a minimum, a PIV Card shall incorporate one such security feature.
Examples of these security features include the following:
• optical varying structures;
• optical varying inks;
• laser etching and engraving;
• holograms;
• holographic images; and
• watermarks.


Using secp256k1 and ECDSA with IKE I just tried using an IKE daemon and EC certificates. I used the secp256k1 curve for key generation. The daemon claims

  signature scheme ECDSA-256 not supported by private key

Now I am wondering if that is due to incompatibilities in the IKE daemon or cryptographic incompatibilities. In other words, is it generally impossible to use secp256k1 keys for ECDSA or is it only impossible with that specific IKE daemon?

This is because RFC 4754 only defines three ECDSA signature schemes for use with IKE, each using exactly one predefined elliptic curve:

ECDSA-256: secp256r1
ECDSA-384: secp384r1
ECDSA-521: secp521r1

Therefore, it is currently not possible to use private keys/certificates with other curves for authentication with IKE.

A solution to this problem is currently being standardized.


Is it possible to get a flash src after a redirect or an element inside an embed/object/iframe tag (cross-domain)? The URL example.com/auth will automatically redirect the user (HTTP 302) to example.com/signed_in.SWF?token=SENSITIVE.

Is it possible for an attacker to steal the token, using javascript or flash, in the following example? How?

<!DOCTYPE html>
<html>
    <body>
         <embed id="foo" src="https://example.com/auth"></embed>
         <!-- Remember that example.com/auth will be automatically redirected to example.com/signed_in.SWF?token=SENSITIVE -->

         <!-- The code to steal the token value must go here -->

    </body>
</html>

Consider that:

The above .html is hosted in cross-domain.com, just like any other file involved in the "solution" (.swf, .js, .html, .css, etc.);
You do not have control over example.com;
You do not have control over signed_in.SWF;
You can change the <embed> tag to <object> or
<iframe>;

If the user is authenticated and an attacker manages to use some kind of exploit to inject javascript (or flash) into the page, then yes, the attacker will be able to steal the secret token. They simply make a request using AJAX to the /auth endpoint and read the redirect URL that comes back. This was made possible recently by the addition of the responseURL parameter to XHR requests.
They can then do with the token as they wish.

To avoid this, you could use some method of sending back the token that javascript and flash can't access (such as setting an HTTPOnly cookie). That way, the attacker can make requests all they want to the endpoint, but they won't be able to access the cookie using javascript.

If you need the token to be readable by your javascript, then you've got a bit more of a tricky problem.


blackbox pentest newbie - find valid internal IP adress from unknown range I`m a beginner and would like to know, how can you find a valid IP adress to start your scan, if all you have is the LAN cable....nothing more.
No DHCP is enabled.

Any hints or clues on how to figure out a valid IP for usage?

Thank you all for your ideas and input on this.

Cheers

What I would do is start a packet capture (in promiscuous mode to get the maximum information by preventing the IP stack to drop packets not for your subnet) and wait for some ARP requests to be broadcasted, after a while you'll have an idea of the subnet on your segment.

If you never receive a broadcast, then there's probably some kind of Network Access Control (NAC) disallowing your mac address or just waiting you to send some kind of specific packet to announce yourself.

If you get broadcasts:

You'll first be able to guess roughly the subnet and its class (ARP who has requests).
Next you pick an IP in this range, try to keep close of any detected IP to avoid falling out of "weird" CIDR subnetting.
Now you can try to nmap the network you're on to get a better idea.

If you capture long enough you'll find "interesting" targets, unless there's workstations sharing files or servers in the same subnet the IP requested the most often should be the gateway of the subnet.
Anyway an address frequently requested will denote a server, hence an interesting target to scan deeply.


Bittorrent Sync encryption Sync, a new product from BitTorrent, Inc., has been cited as a viable alternative to other cloud-storage platforms. The Sync FAQ indicates that an encryption scheme is being used, but does not comment on specifics.

Does there exist any information about the type of encryption that BitTorrent Sync is using, and whether or not the implementation is secure?

The information you asked for is given here on their official site. I am copy/pasting a small relevant excerpt below.

  BitTorrent Sync was designed with privacy and security in mind. The
  system uses SRP for mutual authentication and for generating session
  keys that ensure Perfect Forward Secrecy. All traffic between devices
  is encrypted with AES-128 in counter mode, using a unique session key.
  Modification requests are all verified using Ed25519 signatures and
  only systems with full access keys can generate valid modification
  requests.


Is forward secrecy useful for an application where keeping message history is an integral part? I am writing a decentralized application that lets certain privileged users post messages to other users. These messages should be encrypted so that only the two of them can read it. Messages are posted onto IPFS, so that anyone can read the ciphertext.

Currently, I am using OpenPGP to encrypt from one user to the other. However, I was reading about perfect forward secrecy's usages (e.g. in Signal, Megolm), and it seems like a requirement for a secure chat app.

However, in my case, users must always be able to read message history, ideally from any device with the private key. I could still do this with PFS, but I'd have to keep decrypted message history on the device, correct? Thus, (as keybase alludes to), isn't perfect forward secrecy useless if compromising a device always yields both the long-term key and all past history?

Essentially, are there any benefits that PFS still offers versus traditional public-key encryption, perhaps augmented with the ability to stop encrypting to compromised devices in future messages?

It depends on the capabilities of the attacker. If an attacker can compromise your device, then yes, storing the full message history obviously means they'll be able to see everything.

But what if the attacker can only see communication between the users? In this case forward secrecy is still useful, as it means breaking a user's long-term key at some point in the future won't compromise every message for that user, instead each individual key would have to be broken.

Forward secrecy works by using an "ephemeral key", which means a new key is negotiated for each message. It's the difference between an attacker in the future spending a couple weeks breaking your key and having every message you sent for several years vs breaking a single message's key and having only that message. Once keys can be broken quickly enough (perhaps with quantum computing) forward secrecy doesn't help much. In either case, the attacker still needs to have the ciphertext. If they don't have the ciphertext they can't decrypt it.

As an example, suppose you had a 512 bit RSA key a couple decades ago. 512 bit RSA was first broken in 1999, taking 6 months. Today it can be done in a few hours for less than $100. If you had many hundreds of messages encrypted for that key that an adversary had previously intercepted and wants to decrypt, all they have to do is spend a couple hours and under $100 to break your key and they'd have all of them. If each message had used an ephemeral key, they'd have to spend that much time and money per message.

You can think of forward secrecy as a stop-gap measure, making each individual key much less valuable. This works because once it's possible to break a key, it still often takes significant effort to do so, with the effort required steadily declining over time.


Automatically ensure that a site's certificate (authority) has not changed My Situation :
I've setup my own certificate authority, and generated a certificate for a server used primarily internally.
As I understand it, I can configure my browsers/computers to trust the certificate of the internal server by importing the cert of the higher authorities.
My Concern :
How can I be made aware (before I submit sensitive info to the rogue server or MITM device) of any attack whereby a pre-trusted authority is used to generate a new certificate for an imposter server ?
Can I configure my browser (Chrome, Firefox) to throw an alert if the certificate issuer / fingerprint changes ?
In short, how can I untrust trusted authorities on a per-domain basis ?

Can I configure my browser (Chrome, Firefox) to throw an alert if the certificate issuer / fingerprint changes ?

Chrome and Firefox both support HPKP which allows you to pin the public key of the certificate for a specific host. this does not throw an alarm if the issuer changes but only if the public key of the certificate changes. This is an even more strict protection because anybody who would like to impersonate your site would need to have your original public/private key pair, no matter which CA is used at the end.

  In short, how can I untrust trusted authorities on a per-domain basis ?

There is no way to say up-front which CA you will accept for which site. But once there is a certificate for a site you can use HPKP to accept only certificates with specific public keys for a site.


Creating a secure home network - Which firmware should I use and how should I configure my firewall? I am starting to take on more and more enterprise clients while working remotely from my home office.  I have a pretty secure network at the moment, but I have a lot hardware that I am not using and should be.  I am a programmer, not a network specialist, so I would like to reach out and ask for some advice on how to make best use of the hardware I have at hand.

My hardware:
Linksys 17351
CISCO model 1721 series router with
CISCO 1 Port 10BT Ethernet WAN Interface card
and the router my internet connection came with, Arris DG860/TG862 with firmware 7.5.63C

I currently have about 5 wireless devices that I use, and they are currently setup via a MAC whitelist.  I use WPA2 TKIP/AES security with WPS disabled.

Any advice would be appreciated.

Beside what you have already done disabling WPS and using whitelisting:

Use the latest firmware
Disable TKIP, just use AES.
Obviously... change default login / wifi credentials. Use a decent password.
Disable UPnP.
Firewall policies to DROP, only allowing what you are going to use (80,443,22,53,3389...).
Limit the amount of DHCP devices, also set them to expire every 24h.

But also remember that securing a home network is not just secure the networking devices. Harden your systems, configure the host-based firewall, always install updates, etc.


Dealing with the dangers of self-hosting a webserver? Assuming for a self-hosted webserver:

the webserver only hosts a static html website
iptables is used to reject every IP except a few known ones
only Port 443 is forwarded and the website requires SSL via client certificates

What kind of dangers remain? (Disregarding security holes in a patch)

Sounds like you've done a good job doing taking care of the usual suspects.

How good is your web development skills? In my work experience, misconfigured web servers are the most common threat vector for a breach. Having it be only static is a good move. Have you disabled all the default pages? Is the webserver up to date? Have you run any vulnerability scans against it (at least run ZAP, it's free). Opening up an inbound port into your network with a server on it is, let's say riskier, as you now have a footprint on the internet for scanners to find. Granted, your home router is also getting scanned and attacked on the regular.

If this is on your own home network, and someone breaches it, you are in a really bad spot. Have you considered hosting it on AWS or etc? That at least segments it away from your home systems with critical information on them. I am not saying don't do this, as some might, but I highly suggest network segmentation for it, though, away from the rest of your home network.


Getting a Root CA accepted in systems and browsers I would like to ask about the procedures for a given CA to get one of its root CAs (SSL issuance CA) to get accepted and installed as a trusted root CA in operating systems and browsers.

Different browsers and operating system have different procedures. For example Chrome takes the trust store of the operating system (with the exception of EV certificates) as seen on the Root CA Policy of chromium.

Firefox, on the other hand, maintains all its CAs themselves and doesn't use the systems store at all. They also have a published Inclusion Policy. And of course operating system, like Apples Root Certificate Program.

Generally, all of them require that the CA is certified by an acknowledged authority like WebTrust or something equivalent. To get certified the CA has to prove a few things, like how it determines the owner of a domain, how it keeps the root CAs private key secure, processes and a lot of other things. There is a PDF online from WebTrust with all the requirements. Some examples:

  The Certification Authority:

  Discloses its Business, Key Life Cycle Management, Certificate Life Cycle Management, and CA
  Environmental Control practices in its Certification Practice Statement; and
  Discloses its Business, Key Life Cycle Management, Certificate Life Cycle Management, and CA
  Environmental Control policies in its Certificate Policy (if applicable).
  The Certification Authority maintains effective controls to provide reasonable assurance that:
  The CA’s Certification Practice Statement is consistent with its Certificate Policy (if applicable); and
  The CA provides its services in accordance with its Certificate Policy (if applicable) and Certification
  Practice Statement

and

  Service Integrity

  The Certification Authority maintains effective controls to provide reasonable assurance that:

  The integrity of keys and certificates it manages is established and protected throughout their life
  cycles;
  The Subscriber information  is  properly authenticated (for the registration activities performed by
  ABC-CA); and
  Subordinate CA certificate requests are accurate, authenticated and approved

Then of course the CA has to provide some value to the operating system or browser vendor. Private CAs won't be added to the root CA store of any browser or OS. A list from Apples Root Certificate Program:

  What is the business purpose of the certificates issued from this root certificate? What business is this root enabling?
  To whom will you issue certificates? For example, the general public, members of a certain organization, and so on.
  What Extended Key Usages does the root support? For example, SSL server authority, secure e-mail, code signing, and so on.
  What is done to validate the identity of someone requesting a certificate issued from this root?
  Pointers to Certificate Practice Statement
  List of any third-party audits your CA practice has undergone.
  URL of a publicly accessible server where certificates issued from your roots can be verified

As you can see, it isn't that easy to get into the root stores, and the vendors will reevaluate each and every CA in its store periodically. They also remain the right to kick out any CA it deems isn't secure enough, as has happened with DigiNotar.


PHP Image Upload - Security of storing outside root and accessing via readfile() I recently began storing image uploads outside the webroot and retrieving them via readfile(). I implemented this and it's working fine, but I was curious if there are any further vulnerabilities that still exist in this method.

If I take the contents of a malicious script from outside the web-root via readfile() and output it on a php script that has an image content-type will this force the browser to always interpret this data as an image or is there some way a user could circumvent this and use it to run a malicious script?

Reading the file from outside the webroot with readfile(), it won't be able to run a malicious script on the server.

Providing the proper content-type means that it won't be mishandled as something else in most cases.

However, there are still some cases such as Gifar where a polyglot content is provided in a way that can affect the user (these are actually problems in Java or Flash, but breaking the same-origin), so you should check that the content really is what it to be, and it is not one of certain undesirable formats (for instance, zip-based formats are quite problematic).


Anonymous access over SSL I am using a paid VPN service and I just realized IP privacy does not exist at all when the connection is made over SSL.

If I Google "what is my ip" using the HTTP version of Google, it will give me the IP behind the VPN. But as soon as I use the SSL encrypted version of Google, it reveals my real IP address.

Is it possible to stop that from happening? End-to-end encrypted communications is not my concern, I just don't want the other end to have my real IP.

A VPN works by tunnelling connections initiated by your PC through the VPN, so that they come out on the Internet at the VPN endpoint and not at your PC's primary Internet access point. This happens at the IP level, there is no difference between HTTP and HTTPS in this regard. So the behavior you describe indicates that your HTTPS traffic is not going through your VPN, i.e. your VPN setup is misconfigured.

If you want all traffic to go through your VPN (except obviously for the VPN tunnel), it's best to configure it at the IP routing level: make sure your default route goes through the VPN and only the VPN entry point is routed through your Internet gateway. If you've set up a VPN only for web access through a proxy setting, make sure to activate it for HTTPS as well as HTTP.


Why would someone use my email address in his Gmail registration? I got an email from Google no-reply@accounts.google.com saying the following about the gmail address of an acquaintance that is supposedly connected to a non-gmail account I use:

> The password for your Google Account - &&&&&&(changed)&&&&&@gmail.com
> - was recently changed.  If you made this change, you don't need to do anything more.
>
> If you didn't change your password, your account might have been
> hijacked. To get back into your account, you'll need to reset your
> password.
>
> Sincerely, The Google Accounts team    This email can't receive replies.
> For more information, visit the Google Accounts Help Center.   If
> &&&&&&(changed)&&&&&@gmail.com isn't your Google Account, click here to
> disconnect your email address from this account.

As you can see, gmail is giving me the option of disconnecting my email from his gmail account, but before I do and without asking him I am wondering what earthly reason he could have for giving my address to gmail as his own.

Is this some kind of technique to build history to eventually hack into my gmail? I don't see how.

TL;DR: It's probably exactly what it purports to be.

I got a Gmail address during the beta, so mine matches my (very common) name.  I routinely get messages from Google saying that some account has been created and my address used as an alternate contact.  I routinely click the "unlink this account" link and am never bothered by that address again.

Why?  Well, in a small number of cases I think people really are too clueless to know their own email addresses.  More likely the person creating the account is up to something, not necessarily extremely bad, but requiring anonymity.  In the alternate address field, they put a plausible but (to them) fake address that turns out to be mine.  That could be the case with your acquaintance.

What to do?  Examine the "click to unlink this account" link very carefully by viewing the message source.  A real link from Google looks like this:

https://accounts.google.com/AccountDisavow?adt=AOX8kir9Wk1MCXKhmJxH-rEC[redacted]

If so, click the link; problem gone.  (I removed a part of the opaque token from the example link, but I probably didn't need to.  Even if someone navigated to my example link, it would just try to disconnect an account that's already disconnected.)

I didn't really understand the "acquaintance" part of your message.  If you are telling us that you recognize the alternate address as that of someone you know, disconnect it anyway because your account should not be connected to one you don't control.  Then ask your friend what's going on.  It might be as innocent as your friend wanting your help if he ever locks himself out of his account.  But he (or she) should have asked you first.

It is possible that this is a phishing attempt and the sender wants to steer you to a particular link.  Looking at the link should tell you.  In any case, real Google "disconnect" links just tell you that the address has been disconnected and tell how to undo that if it was a mistake.  They do not ask for authentication.  So, never, ever supply authentication information like a password after clicking such a link.


Do openssl CA certificates get updated with apt-get upgrade? I use Ubunut 18.04. I need to know if OpenSSL CA certificates that are in this file:

/etc/ssl/certs/ca-certificates.crt

get updated when I upgrade my system using: apt-get upgrade?

I have a program that uses OpenSSL and validates servers' certs using the CA certs in this path. I need to know if I can assume that my file has an updated CAs list if I upgraded using apt-get upgrade.

The global trust store in /etc/ssl/certs/ is part of the ca-certificates package and receives regular updates as can be seen from this Changelog. These are normal updates which get installed by apt-get upgrade.

The specific file itself is not part of the package but is generated by update-ca-certificates. This command gets automatically called on updates of ca-certificates as needed to reflect the changes in the trust store.


Do any tracking networks or ad networks not use JavaScript and only track based on IP address? If yes, how can they be prevented? Are there any websites that collectively track one computer based on its IP address alone? Browser extensions such as Ad block plus, Do Not Track Plus and Ghostery modify the client side script but is it not conceivable that a server would just associate your IP address with the page you requested and share it with some network? For example if you search for a suit on a site hosted by server A and server A passes along your search information and IP to other servers in its tracking network, such as server B, then you go to a page hosted by server B and you start seeing targeted advertisements for suits. Even with scripts completely disabled this wouldn't be prevented against, is there any way to prevent against this? Is this scenario, or any similar, happening?

It is most likely that some ad network uses this method. To be honest I don't know, but I'm going to answer your second question.

How can they be prevented?

1) Change your IP: You can use a vpn or a proxy or TOR to change your ip. But you have to trust your data with the VPN service provider or host.

2) Confuse them: You can confuse them with an automated bot that browses random pages of the sites that use the ad network, giving them false information about your interests.


What would be the most efficient way of brute forcing a wifi key I was wondering how can a brut force of my wifi be prevented so I want to know the best technique that can be used to brute force it first, so protection isn't my question. My question is: What brute forcing techniques (in detail) would be the best (efficient/ fast) to perform a brute force attack on a WPA2 wifi to get the passcode.

Brute force is brute force

By definition, "brute forcing" a password or key involves trying every single combination of characters until you find the one that works.

There are differences in strategy which might be faster: for example if attacking a specific ISP's router you may know that they always assign 8 character upper-case-and-numeric passwords, which leaves you with a smaller sub-set of possible keys.

But there's no guarantee that the key hasn't been changed to use a different approach - for example I routinely change my WiFi passwords to a longer, more complex password - in which case you won't even know that your strategy is wrong until you've tested every combination in your strategy. At which point you'd then have to revert to a full brute force approach.

Similarly you can attempt to use a dictionary attack, if you expect the key to be a word (or combination of words, or bastardization of words, for example P4$$W0rD!), but again there's no guarantee that the password has been changed to use this scheme, and the only way to be sure is to test.

And finally if your basic strategies fail, you're back to trying to crack all the possible combinations... which is a number bigger than I can be bothered trying to remember the word for.

In short

There is no "efficient" way to crack a password - there are a few ways that may be efficient if the password is insufficiently complex to be secure, or follows a simple strategy - but they only work if you (the cracker) pick the correct strategy. If not, you're actually being more inefficient.


What is the key when facial recognition is used as a password? I get the basics of what face recognition is and the fact that it is used to protect PC's and as a login replacement.

However, if it was to be used for encryption, where the role of the key is played by the password, what is the key used when face recognition is used? Is it hardcoded in the app used to do the face recognition, or are some parameters from the face itself used as the key?

From here.

Most biometric authentication methods, including face recognition, need to allow for variations in the biometric. Due to this the biometric authentication process doesn't have a precise value that could simply be used as an encryption key.

To solve this problem Juels and Sudan invented the concept of a Fuzzy Vault (PDF). With a fuzzy vault:

  A player Alice may place a secret value K in a fuzzy vault and "lock" it using a set A of elements from some public universe U. If Bob tries to "unlock" the vault using a set B of similar length, he obtains K only if B is close to A, i.e., only if A and B overlap substantially.

A fuzzy vault scheme for face recognition is presented in this paper by Wang and Plataniotis (PDF). I don't know if currently available face recognition software implement such a fuzzy vault scheme.


Will WPA Enterprise give any advantage on home network with one user? I understand some of the reasons why WPA Enterprise is more secure from this question: Why is WPA Enterprise more secure than WPA2?

However, given a home network with only one single user where that user has a long and complex password (at least 28 random chars), is there any advantage for WPA Enterprise?

From what I read, I believe that in this specific situation, there is no meaningful advantage for WPA Enterprise. I wonder if the increased complexity of WPA Enterprise might actually work against security in this scenario (single user, home network). Am I right or wrong?

The main benefit of WPA Enterprise is that it uses a radius server for authentication, which allows you more control on a per user basis.

Each user gets their own key to secure their connection. This means a user can't Snoop on other people using the same network (in WPA2 Personal you can read all users wifi traffic if you have the PSK).

Each user can be assigned a VLAN, further segregating the traffic, and allowing you to partition your network based on the user.

If a device is lost or stolen it won't cause you to reconfigure the other devices, you would simply deactivate that user.

While most benefits apply to multiple devices/user scenarios, there is one benefit for a single user, which is that it disables WPS, which is only available on personal.

I'm your case it seems like the benefit is minimal, and the overhead of setting up and maintaining a radius server likely isn't worth it.

Overview of enterprise http://techgenix.com/why-use-enterprise-wi-fi-security/


Reverse SE: Technology or Human based? In Reverse Social Engineering the hacker deliberately sabotages a network, causing a problem to arise. That hacker then advertises that he is the appropriate contact to fix the problem, and when he or she comes to fix the network problem, the hacker requests certain bits of information from the employees or staff and acquires the information he or she was looking
for.

I would categorize RSE under technology, because I can't seem to come up with an example that is not based on technology.

Can you come up with a RSE scenario that does not involve technology?

What could be sabotaged?
How will you justify your request for security information?

Social Engineering and Reverse social engineering are mainly used in computer security however they can be applied outside this field as well.

Both social and reverse social engineering exploit the non-technical human weakness in security therefor the actual exploitation occurs outside the computer.

One example of social engineering is creating distrust, which in fact can be used in reverse social engineering as well. After creating distrust between two target parties (possibly by falsifying or altering information) he can then introduce himself as a "mediator" for fixing the conflict. The mediator is then able to acquire security information from both parties.

Another example is causing a maintenance problem in a building (power black-out) and then arriving dressed-up as the maintenance repair-man to fix the problem and in doing so, gain access to the building and maybe the sensitive systems inside.

The main reasons that make social engineering attacks successful are:

Poor Security Awareness: An extremely large
percentage of users do not understand the importance of a password for authentication and
access to a computer system. They do not realize that their account can be accessed from
anywhere in the world, given the proper access point.
Users also do not understand the lengths that people will go to obtain the information
that the users have access to on a daily basis. They also do not realize that throwing
something in the garbage does not mean that the information is destroyed. What is garbage
to a user might be extremely valuable to a hacker.
Human Weaknesses: People give out information for many reasons. In most cases, they just want to be
helpful, because that is their job and/or nature. People can also be intimidated to release
information, either by being made to believe that a superior wants the information or by just
trying to make an annoying person go away.
Untested Plans and Procedures: Organizational procedures that require an authenticating mechanism must carry with
them additional procedures that protect the mechanism. This is where a large number of
security plans fail. Many organizations test a specific part of a security plan or procedure,
but these plans and procedures must be tested as a whole.

Based on the above, most social and reverse social engineering scenarios are based on technology because the general public is not aware of the security significance of certain information. But social engineering was used long before computers were born (the words "con" and "scam" refer to a more general non-technological form of social engineering). However with the evolution of technology there has been new and intuitive ways to accomplish this procedure.


Can a .exe file scanned and verified safe by many antivirus hack my personal information? I recently downloaded a .exe file from a person's github. I scanned the file in virustotal.com and it showed none of the antiviruses detected a virus. When I checked its behaviour, it had access to network adapters. Nevertheless, I opened the .exe but it just opened a terminal and showed something and disappeared. When I asked the guy who sent it to me, he said the program just hacked my personal information from my computer. But the antivirus shows no risk. Can anybody help me with this?
Giving the file link below:
https://github.com/constantinDev/hacktoolv2/blob/master/Tools/GTool/bin/gtool-src-win.exe?raw=true
I have a Windows 10 PC and I was connected to internet at the time of the incident and the program ran in administrator mode.

Online antivirus scanners detect known malware.
New malware is not known to them, so it is absolutely possible to have malware that is not detected by any antivirus.
An antivirus installed on your PC can use some more heuristics to detect potentially bad behavior of running software, but this is far from perfect.
You should absolutely not run executable software which you don't trust, and never run anything that is not 100% trustworthy with administrator permissions.
If you look at the source in the repo, this is pretty harmless, it just sends your IP and some system data to a telegram channel. Probably created by a bored teenager.
If the source code actually is the one used to create the executable you ran, that is. I didn't bother to verify that.


Anyone can identify tool used to perform this attack? recently I've identified that some hack attempt was performed at one of my servers.

I have dumped nginx logs to github, please take a look and try to identify which tool was used to perform this attack.

Excerpt from log:

195.154.41.132 - ktuser [04/Nov/2016:12:59:18 -0400] "POST /apply.cgi HTTP/1.1" 404 459 "-" "-"
195.154.41.132 - ktuser [04/Nov/2016:12:59:18 -0400] "GET /cgi_bin/user_network_connection.asp HTTP/1.1" 404 459 "-" "-"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/phpmyadmin4/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/2phpmyadmin/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/phpmy/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/phppma/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/myadmin/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"
162.243.79.108 - - [01/Nov/2016:16:39:57 -0400] "HEAD http://8.8.8.8:80/shopdb/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee"

Full log can be seen here:
https://gist.github.com/acosonic/772971fee7b4b20c5ba3da7657a42430

Also, please advice if there is some behavioural tool that would learn and identify that above is a threat, and ban such IP's.

It is a vulnerability scanner called Jorgee. The log actually tells you this because it is displaying the user-agent for each request. A quick search on the user-agent reveals a whole host of information about Jorgee.
There's a couple of steps you can take, you could setup something like Fail2Ban. If you didn't want to setup anything too complicated then you have a few configuration options you can do. They won't stop everything, you would need to do a lot more if you were trying to defend against anything other than an automated bot.
Firstly, you could look for any user-agents which you don't want, for example in this case, you can look for any user-agents which show Jorgee and you can drop those requests.
Secondly, you can setup rules to block unwanted host headers. This is fairly trivial to do, and you can create rules to only allow host headers that you want specifically and drop any host-headers that are either numeric or not in your list.
As I said, you would need to do a lot more than this to stop anyone even remotely serious but this is a start.


Is Apple compromising network security with its default settings, which allow users to provide network credentials to other users with one tap? This article summarizes the functionality that has been recently added to Apple devices.

My colleagues have expressed concerns about this feature eroding network security at the office.

My questions:

Should we consider this a security risk? Only people who are on our contacts are supposed to trigger this, but this also makes the perhaps-unreasonable assumption that we completely trust all persons we place on our contact list.
How could we switch this capability off?

First off - why would anyone consider this a security risk? Apple's implementation of the WiFi password sharing feature is much better implemented than Microsoft's attempt from a while ago. For starters:

You can only share the password knowingly, and with someone you trust: You still receive a notification when your friend wants to connect to your network and also have to both press a button to accept the request and have them in your contact book.
The underlying principle of a pre-shared key remains the same: This isn't changing the functionality through which the client connects to the router (like with a RADIUS server in WPA2-Enterprise) but just removes the requirement for you to speak out the key. In fact, I'd even argue that this method is more secure as you said in another comment since there's no chance that someone you don't trust or an eavesdropper might be able to lift the note with the password or just record you shouting it out to your friend.

Additionally, in an enterprise, you should already be using WPA2-Enterprise with a RADIUS server instead of a PSK. This already seems like a flaw in your current implementation.

Finally, the implementation doesn't automatically share your password with every user in your contact book. It still makes you explicitly approve each user through a dialog box.

And to:

  How could we switch this capability off?

It seems like an inbuilt feature without a way to turn it off. I'll update this answer if I come across anything in the future though.


Transforming keystroke dynamics raw data I'm writing keystoke dynamics identifcation as an assignment and I'm having trouble with storing data. I was instructed only to "don't keep raw data" as it should've been transformed. I wasn't told what form data should take to not be considered raw or how to transform it.
Unfortunately I couldn't find any articles/publications that'd tell me either.

I am recording raw data as follows:

key | Pressed/Released | Time since last event
Z P 64
Z R 96
A P 88
P P 72
A R 9
P R 64
O P 88
O R 81

Then I process it by separate metrics: UpToUp, dwell, flight, interval and latency.
Let's look at UpToUp data (they all output frequencies in the same format). Timings are calculated:

Z -> A: 169 (88+72+9)
A -> P: 64
P -> O: 169

Then grouped and counted:

[(64,1), (169,2)] or more general [("60-70",1), ("160-170",2)]

Keystroke recording can be of any length. If it were bigger, we'd get more diverse frequencies that'd be normally distributed .

I'm looking for confirmation or recommendation, whether these frequency countings can be transformed further, so it's more distant from raw data. As I said, I couldn't find any publication which would answer me.

With voice biometrics I came across FFT, but I couldn't find it in keystroke context.

As you mention, if you gather enough data, each key-feature pair will be well approximated by a gaussian distribution. In that case, instead of storing the timing counts ([(64,1), (169,2)]) or even the histograms ([("60-70",1), ("160-170",2)]`), you might want to consider storing the parameters of the inferred distribution - the average and the variance. Of course, that only works if your model can still work correctly from the inferred distribution.

Another thing to take in mind is to avoid storing short runs. Even if you store it in aggregated form, if you capture the moment when a user is typing a password, and the only keys that have valid distributions are 1, 5, 3, 4 and 2, that's not really ideal!


Is changing default admin URLs an effective security measure? Consider WordPress, which houses all of its admin functions in the /wp-admin/ directory. Accordingly, its admin URLs all begin with /wp-admin/.  I'm wondering if it would  be significantly more secure to have each installation use a unique name for the admin folder and URLs, For example, the admin folder for a particular installation might be /8404f25a73ec25d1/.

The first thing that comes to mind is that this is security through obscurity. However, this seems like it could be an effective, first-line-of-defense against automated scripts. If the name was sufficiently random and long enough, there is no way an attacker could guess the name of the admin folder. Also, in zero-day attack against a newly found security hole against
the admin side, this might be the only defense.

Should off-the-shelf web applications like WordPress provide a way to change default admin URLs?

To be clear, I am not thinking that this should replace any other security measure; I'm only wondering if the additional security (if any) would be worth the effort.

It will unquestionably protect you from automated attacks that rely on the location of the wp-admin directory as part of their programming, which is not insignificant, since automated attacks make up the vast majority of wordpress compromises. You may call it security through obscurity, but you're not actually replacing any of your security apparatus with obscurity, you're augmeting it. So a better term would be defense in depth.

Note that a far better strategy is to require HTTP Authentication to access the wp-admin directory. Just plunk an .htaccess file and .htpasswd file in there and you're done. This is widely regarded and recommended as a good idea. That way not only do you have to log in to wordpress to use the admin features, but you also have to provide a password to the server just to allow it to show any content from that directory. That protects you against all sorts of authentication-bypass vulnerabilities if they ever crop up.

See the rest of the Hardening Wordpress documentation for more similar "good ideas".


Could receiving a URL link, not clicking on it, ever pose a security problem? Could receiving in a text or an email, a URL link just like https://security.stackexchange.com/questions/ask of a website, which could be a pernicious one, ever pose a security problem at all? What I am asking is that: if I receive such a link but do NOT click on it, will it ever do harm to my account, computer or other website I will ever visit?

Edit: As a specific example, I would like to ask about the situation for receiving a link, https://down[.]nnjah68[.]me/app.php/Mjl1to, in WhatsApp.

Many browsers send "pings" to any links on a page by performing a DNS query on them to populate the cache. This makes clicking the link faster because the IP is already in the DNS cache. In theory, a bug in this code could be exploitable simply because the link is there. In practice, this isn't an issue. Just because a link exists doesn't mean it can do much to you.


Reading about security by design? Security folks often encourage people to build security in from the start, and architect systems that are secure by design.  What are some readings you would recommend for someone who wants to learn more about how to go about doing this?  I'm particularly interested in reading about secure-by-design languages and APIs, and how to go about designing languages/APIs for security.

These aren't books, but you may find the info useful:

BSIMM - the Building Security In Maturity Model
OpenSAMM - Open-Source Security Software Assurance Maturity Model

Security Maturity Models tend to provide a lot of info on building security in from the start, defining Secure Development Lifecycles and managing governance and change in order to raise security baselines.

They don't go into any depth on languages or api's though, more around what you would want to look for or measure or control, so this answer may not work for you. Have a read of them both anyway and see.


Android application level encryption cracking We come across Android applications which use the custom encryption. When we proxy the Android phone or emulator, the proxy captures traffic which is unreadable.

Is there a known technique to read this traffic or reverse engineer the encryption?

It depends upon the encryption.  However, if they are using modern secure encryption, then there will be no way to read this traffic from the proxy.

Your best bet will probably be to instrument or monitor the application so you can see the data inside the app before it gets encrypted.  Alternatively, it may be possible to modify the application to turn off the encryption, or to make it less secure (e.g., if it is using SSL, modify it so it doesn't check the server's cert or so that it accepts your cert as a valid CA, and then mount a man-in-the-middle attack).

All of this is likely to involve some amount of reverse-engineering the code of the Android application, which may take some work if the app has been obfuscated.


Can multiple transactions of the same amount in a short time be considered fraud/corruption? Back story
In South Africa there is a website where I can buy prepaid electricity online for my apartment. When buying I did not get the token to use on my metered box. I had a chat with them today and they gave a reason why I did not get my token. I'll paste the exact reason below.
Response from company representative

The reason for the delay is due to the following:
Your transaction will be delayed if we receive a transaction for the same amount with the same cellphone number within 5 days of a previous transaction.  Please change your transaction amounts slightly to avoid delays. i.e. R200, R210 and then R220.
This is a precautionary measure to prevent fraud and corruption, and protects both you and us. Should you require more electricity within 5 days of a previous transaction please do a transaction with a different amount as the previous transaction.

I responded by saying there is a bug in their system as far as I am concerned, this is no security in my opinion.
It is a 12 hour delay now and they have apparently been using this for some time now.
Question
Is the response above really true? I did computer security in Varsity for a semester but I'm not deep into it. This response gives me an uneasy feeling.
Is this one of the ways of detecting fraud for a company that sells prepaid electricity?

Can multiple transactions of the same amount in a short time be considered fraud/corruption?

Yes, its something I monitor (or rather an agent I built monitors).

  a transaction for the same amount with the same cellphone number within 5 days of a previous transaction

erk?

Personally I'm looking for multiple events occurring within a timescale of up to 10 seconds - but then I'm comfortable that the systems being monitored are not subject to replay attacks. However, you mentioned cellphone numbers implying that there is a high risk of SMS's being duplicated on the aggregator and the carrier before they arrive at the end point.

i.e. unless you stretch the definition of "integrity" as it is usually applied in the Security domain, their policy appears to address functional issues in the transaction process.

Is the payment charged via your cellphone provider or are you merely sending a mandate to the electricity company who bill you directly? The former provides a means for all sorts of chicanery, in the latter case, there is no obvious Security spin to this story.

  I responded by saying there is a bug in their system

As per above - it may not be the fault of the electricity company. However since you had to chase them to get this explanation, they are clearly more interested in protecting themselves against fraud than protecting you.

Update

It has since occurred to me that it's possible the "token" might be data rather than physical (again a lot of guesswork about whats actually going on here)  and hence might be the subject of the attack, or more specifically the algorithm by which the token is generated.

The service still sucks.

And if its possible to derive the algorithm from multiple orders for the same amount, then the security sucks too.


What is the advantage of buying an SSL certificate from the CA rather than a reseller? I am trying to do some research on SSL certificates, and I've come across a number of reseller sites such as GoGetSSL, which offer certificates at much lower prices than what you would pay if you bought them directly from the certificate authority.  I understand resellers buy certificates in bulk which allows them to pass on discounts, but I can't understand what the advantage would be to go to the directly to the certificate authority?

There is in most cases no real significant advantage in buying directly from the CA to my experience. Especially since the prices are often higher - resellers provide nearly the same value for less money (might depend on your specific needs though). If you take advantage of a promo by a reseller you may even get the first year for free or so.

The main difference that I observed is that in case you buy from a reseller the certificate lifecycle management processes and also support processes are also provided through the reseller and the CA usually does not support you if you contact them directly.

Apart from that I noticed that some non-standard or cutting edge features are sometimes not available through resellers, i.e. if you want to have your cert SHA-2 signed it may not be possible in every reseller/CA constellation. Best is to ask beforehand if you know that you have any special needs.


Does openssl store the certificate of the server after verification is done? As per my understanding , openssl will verify the certificate of the server during ssl handshake , using the trusted CAs present in the CA certificate dir in the context. After the  server certificate is verified and handshake is done , does the openssl cache/store the verified server certificate?

The certificate is available as long the SSL connection is open by calling SSL_get_peer_certificate, see https://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html. It is no longer available after SSL close.


Does the glibc getaddrinfo vulnerability affect mobile applications? Recently Google discovered the "glibc getaddrinfo" vulnerability (CVE-2015-7547)

Is this a server side only issue, or can apps be affected by it as well? I'm developing both an iPhone and Android app, and don't know exactly what to look for, or what to update.

Thanks

Neither Android nor iPhone use glibc, so these are not affected.
Android uses as libc Bionic and iOS is also using their own libc implementation.


Configure Windows Firewall Inbound Rule for Program Not Installed on Server How can I configure an inbound rule on a Windows Server 2016 firewall to allow access from a program which is not installed on the server? When searching for a program browse is only offered for locations on the server. Is the path specified for the rule applied to the machine accessing the server? Is it possible to create a rule based only the executable program file name, irrespective of where it is installed on the machine accessing the server?

You need to find out which network ports your application uses to communicate. Usually, firewalls do not support to choose some programs. The standard is to define source, destination and ports.


Is having a GUID in a https url secure enough? Is having a GUID in a https url secure enough? Are there any security risks of using this way of authenticating users?

https://mywebsite.com/......?Guid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Also what measures can be taken to make this kind of URLs more secure.

A session id should be a Cookie parameter,  and should never appear in the URL.  Any value in the URL A will show up in the referer header,  as well as access log files.   A web application will end up transmitting authentication credentials to other websites,  and storing them in plaintext on the filesystem.

Additionally, when you pass a session id in the URL, you open the door for Session Fixation.


If I unzip a password-protected zip file, will the person I downloaded it from be notified in anyway? If I access a password protected zip file, that i've downloaded through tor, and then opened the zip file, is there any way the person who posted the zip file would be able to find out that I've opened it?

Unless you open some executable within it or open it with archivator with known vulnerabilities, there is almost no way he can know. You can always airgap it by using VM's or literally disconnecting PC from any network.


Software can be audited, is there an equivalent for hardware? In software, code auditing can be used as a mean to gain trust into a software. Of course closed, proprietary software would complicate this, and require to do reverse engineering. Anyway there seems to be a way for software to eliminate distrust to some extend.

Recent events have once again shown that hardware components in computers have become a powerful attack vector. Indeed the DMA-attack is problematic and can be inside the following hardware components: hard disks and SSDs, PCI, USB devices when they can compromise the USB host controller. Of course the CPUs themselves and the side-microcontrollers, e.g. Intel vPro/AMT/ME can also be backdoored (from a design of IC perspective).

Provided the technology used in manufactoring of the IC it seems doubtful that one can "look into the hardware" in  a way that would correspond to the code auditing and or at least the reverse engineering of software.

Are there some best practises developed to audit hardware to some extend against malicious backdoors?

The current way I have found to mitigate the risk of hardware is to connect them with airgaping components or configure them with hardware jumpers, hence providing some sort of isolation. Obviously this is the exact opposite of what an integrated circuit or a SoC (System on Chip) are conceived for.

Software auditing is easier since code is mostly done on standard platforms, whereas HW has at least two components: SW (firmware) and electronic components, which are sometimes proprietary and under patent laws.

Reverse engineering a HW firmware is also possible, however you must deep understand how the electronic components work and what kind of vulnerabilities they have (or could have) from a component as well as from an entire system perspective.

CC - Common Criteria addresses this concern by ensuring that a solution (HW and SW) is delivering what is supposed to (from a security perspective). They even have a classification level to security assurance. However the vendor must explicitly mention against which vulnerabilities they have protection in place.


Is there a safe way to use external display with USB Type-C laptops? Somewhat related to Is malware or screen capture possible with iMac as external display?, where we investigate the possibility of a DMA attack through DisplayPort, nowadays, many machines don't even have a dedicated port for connecting an external display, but instead of rely on a single USB Type-C port type to accommodate both in and out power delivery and charging, as well as networking, external display graphics (through DisplayPort or HDMI Alternate Mode), as well as the plain-old USB.

With the advice against using USB ports in airports finally becoming mainstream now in 2019 — https://www.zdnet.com/article/officials-warn-about-the-dangers-of-using-public-usb-charging-stations/ — what are you supposed to do as an end user to use an external display?  Do manufacturers do any sort of threat modelling here, or are we supposed to assume that noone would spend the time to develop fully functional malware infecting computers and networks of speakers at various conferences?

Is the best practice now to outright refuse giving a presentation from your own laptop in auditoriums where the laptop and the external monitor equipment have distinct owners?  Or is there a way to protect yourself from being potentially exposed thanks to such a versatile port as USB Type-C?

You could disable removable storage devices using group policy while still allowing the other devices such as monitors to function. I believe this is something similar to what we do: https://serverfault.com/questions/576768/disable-usb-mass-storage-access-on-client-machines


Is a TPM which boots a full-disk-encrypted computer to login secure? Currently the laptops in use are encrypted using Pre-Boot-Authentication, so the entire disk is encrypted. A user has to enter a password before booting the operating system.

A new concept suggests using the laptops TPM to store the key. While the disk itself is still fully encrypted, the boot process continues until the Windows Login Screen without the user entering a password.

On these laptops, USB-drives are not blocked before login and BIOS (tries to) prevent(s) booting from another drive (which can probably be bypassed). In my opinion, this makes the Full-Disk-Encryption as secure as the Windows login screen, which is a considerable downgrade.

The question is:

Is allowing the boot process to continue until the Windows Login Screen without requiring the user to enter a password considered secure?

Which attack vectors can be used and are they just academic problems or reasonably possible?

Assume the laptops are corporate devices, containing potentially sensitive/internal data. I argued that any flaw in the Windows Login Screen effectively kills the Full-Disk-Encryption. Any software like KonBoot may be used to nullify the encryption. A colleague mentioned, that employees leave their devices in sleep mode 80-90% of off-work hours, so it doesn't really matter, even when using the pre-boot-authentication which is currently in place.

In my opinion, this makes the Full-Disk-Encryption as secure as the Windows login screen, which is a considerable downgrade.

Yes. And in a sanely configured, domain joined, patched, laptop, this is fairly secure.

As the disk is encrypted, you can not bypass the login my editing configuration files easily. You can not decrypt the disk if the TPM refuses to unseal, which it should refuse if boot options has changed.

It will reduce security over having to enter a pass code on boot. It will also increase convenience and probably reduce number of support calls. It will for sure thwart opportunistic thieves, that find or steal a laptop without any aim, from discovering the content.

You will have to balance this against who and what you protect. An answer applicable to the budget spreadsheet of Moms & Pop Cornerstore LTD may not be applicable to the engineering drawings of Boeing - to take two extreme examples.


Form submissions over HTTPS are not encrypted? My question is regarding HTTPS form submission. One of our website is using HTTPS, we display the login page to the user via HTTPS protocol.

When the form is submitted, if we try to intercept the request using a tool called "Burp Suite" before sending it to the server, I see that the form Data is not encrypted.

Is this the right behavior? or is it something like the request is being secured only in transmission over the network?

Burp is an intercepting Proxy, which lets you inspect and modify traffic between your browser and the target application. Burp is actually serving it's own certificate so that you can see what's inside the request. Normally you will have accepted a security warning for a certificate issued by Portswigger, this is the certificate generate by Burp.

If you want to assess your application you should use Wireshark instead and look at the HTTP requests. Those should not be visible to you.


Does displaying images on profiles by URL have security implications? I am Developing a Web Application Currently, in which users can Make a Profile and Fill out the User's information, In this i have also kept a Section for Profile Picture, in that i have used a logic that No Users shall be Upload any Image to the Profile picture just for Testing and instead of that i am showing Images like

In this i have made a Input for user to place the path of jpg image from any site he likes and I directly display the image from that site only, which is http://example.com/image.jpg in our case.

I want to consider the worst situation here, I haven't placed check nor whitelisted any domains into the example.com/image.jpg. I placed a URL like http://stackoverflow.com/index.html it shows me blank, I tried many PHP scripts like http://attacker.com/omg.php and it doesn't run the script on my domain.

Is there any possibility of attack vector here? If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

Note: In the URL Section, i am making First validating check at scheme of URL where http:// , // and https:// are WhiteListed & in the Image section i have ONLY whitelisted Numbers + Alphabets and special characters like ., - & / .Rest else are blocked

i tried many php scripts like http://attacker.com/omg.php and it doesn't runs the script on my domain ..

The problem here would not be a server side vulnerability but more of a reflective XSS vulnerability that runs on the browser not on the server which is why the php file did not work.

Taken from OWASP (see here):

  Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

If I attached a file (lets call it script.html) and had Javascript execute there then any one viewing the "image" will run the Javascript on their browser.

For example:

I am a user on your website  and I attach a profile picture with the link http://mymalicouswebsite.com/script.html and in the script.html file I have the following code:

...Some HTML...
<script>
    window.onload = function(){
        //Anything I put here will run on any viewers browser
    }
</script>
...Some HTML...

This can be even worse, the attacker can do the following:

Replace your whole html body with any content he wants (he can load an iframe which is a phishing page)
He can steal users cookies and send it to his page using AJAX
Redirect the user to a drive by where a virus will be downloaded and the user will think its coming from your website

  Now, Is there any Possibility of Attack vector here, If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

CORS is when an HTTP request comes from a script which is not this case. What you are doing is as if you are loading an iframe.

About CSP: I would have to see your setting that are set to see if an attack can be made...


Oauth2 vs APIKey in a server to server communication A third party service provider is exposing a payment API that we need to integrate on our backend.
As transport communication we will consume this API using TLS with Client Certificate and over a MPLS private network.

As authentication framework, the third party is suggesting Oauth2;
I'm instead suggesting a "ligther" authentication like an APIKey/ClientSecret.
Why?
Because, from my "limited" experience, I don't see any benefits in using Oauth2 in this scenario.

The Api will be consumed by just one single service user used by our backend.
We don't have any level of authorization (no claims).
In Oauth2, to protect credentials, you use them just to get an access token and you authenticate to the API using it; in our scenario, credentials are not personal credentials but a single service credentials provided by the third party API provider.
Leaking them would be like leaking an APIKey from my point of view.
In case of some security breach you will just have to revoke the APIKey; having
Oauth2, you have to revoke the refresh token leaving the granted access token
still valid.
This will force us to create some utility library (based on Restsharp) and database tables to handle all the back and forth imposed by Oauth2 protocol. One thing that I saw in other projects is that this library need to be "synchronized" in case of concurrent access.

Probably I am missing some important points and my oversimplification is not admittable in an crucial service like a payment API.
In your experience, does Oauth2 have some advantages over a "basic authentication" in this specific scenario?

This is an interesting topic and there are a couple of things to consider. First we need to come at it from the API provider, not just the consumer.

Who?

The main consideration is Authentication vs. “Identity” and Permissions. Refresher:

Identity = Who say you are
Authentication = Who you really are
Permissions = What you can do

Check out this post for more detail on API ID and Permissions.

While, in this instance permissions may be implicit (where by virtue of being authenticated you are able to use the API), consider this: As the provider of an API to a service with the level of sensitivity payments require, I want to know that the consumer is who they say the are.

Passing an API Key only confirms that you have the API Key: it does not prove that you are authorised to access the API.

Now, possessing an OAuth Access Token may initially be viewed the same, however the OAuth RFC states

  The authorization server MUST authenticate the client whenever
     possible.

OAuth enables this by providing refresh token, as you said, along with a registered redirect URI. It also suggests a minimally scoped token for all initial and re-authentication requests.

This gives the API provider much more control, more visibility and thus more confidence that their API has not been compromised.

OAuth also plays nicely with permissions. If the payment gateway company decided to extend authentication to require permissions to GET and to POST, this would be less work and more secure than if you had to try to tie a key to permissions.

Exposure

A secondary but relevant consideration is what to do if the API Key is exposed.

I know I want be able to trust the key, however it might have been breached. So I also whitelist the clients IP... IP’s can change, depending on configuration, and they can also be spoofed... How can I know if the key is being used nefariously or not?

If the API key is then re-issued post breach it can be easier for someone to determine possible new keys once the initial key is known. This means that the providers key gen algorithm may also need to be adjusted.

If you were issued an Access Token that somehow got exposed, once it comes up for refresh, the unauthorised user should not be able to get reauthorised. I can log them log this erroneous request and work with the consumer to diagnose root cause.

Summary

The API key was only ever meant to serve as a form of ID. As such they are basically misused when implemented as a primary security measure.

If API Consumers need to be authenticated - as in you need to verify the caller of the API and provide access to certain resources based on that verification - OAuth is the better choice.

Hope this helps!

NB For arguments sake, I have assumed no one has root access to your internal services or network, and all over-the-wire comms are via HTTPS.


Java with LIS system I'm not well versed in technology but have a problem that maybe you experts could answer. We have a software application that supports our laboratory - obviously must be secure. We want to be able to have outside parties interact with the application through a webmodule that we bought for the application. However our IT folks are concerned because the application currently needs Java 1.6 on the server - and they cite many security vulnerabilities. The vendor indicates they haven't completed testing for any future versions of Java.

This application is in use in many large hospital systems, so finding it hard to believe that vendor wouldn't have addressed this somehow.  Its causing some contention and we users are stuck in the middle.

Can someone help me understand - in lay terms if possible:

Is this is a concern?
What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?
Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?
Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Not sure where to begin or who to believe about this...   Thank you!

Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used.  Almost all of the security vulnerabilities in Java are client-side.  That is, most are only applicable when you are using Java plug-ins on your browser.  Very few of the Java vulnerabilities are server-side.  A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities.  I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities.  This is strongly suggested by the fact that they seem unable/unwilling to retest their code on a new version of Java.  Backwards compatability is very well maintained in Java.  It's really unacceptable for them to respond in this way.  It implies they have very weak development processes.

  What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start.  You probably need to have some help though.  You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

  Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would.  It really should not be an issue.  They won't need to change any code, to my knowledge.  It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor.  It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application.  There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

  Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013.  You can buy extended support, however.


Can applying second cipher (including home brew) reduce security I have asked a question regarding the benefits (if any) of the following scheme: AES(HomeBrew(plaintext)). There are many good answers for that, but many people say that it's theoretically possible that your algorithm will reduce security of the whole scheme, so it will be possible to break it without breaking AES itself.

Assuming this is correct, what if we now invert the transformations to HomeBrew(AES(plaintext)). It seems there is no way of doing it wrong, because if you really compromise the security of the scheme in your algorithm that will really mean you have found a vulnerability in the AES itself, which can probably make you famous, but does not seem very likely to happen.

Even though security by obscurity is known to be bad, it can still require a lot of resources for an attacker to break. The famous Enigma example proving security by obscurity is bad still proves my point as well: even though it was broken it did cost enormous efforts to do so. So I have few questions with regards to all this:

Is it possible to compromise security by doing AES(HomeBrew(plaintext)) [Provided we do not mess with keys between algorithms]?
Is it possible to compromise security by doing HomeBrew(AES(plaintext)) [Again provided that we don't mess with keys or open text in the out algorithm]?
Will the scheme from point number 2 raise cost for an attacker, perhaps proportionally to you ability to keep the scheme secret and you crypto skills? (So even if someone hacks it, they have to pay the cost and bump into AES after that).

From a mathematical point of view: when you cascade two encryption functions f and g in that order (you encrypt with f, then encrypt the output of f with g), then g cannot make the data less confidential than with f alone, provided that an important condition is fulfilled: the secret key used for g must be unrelated to the secret key used for f.

It is not that easy to make a formal and correct definition of what "unrelated" means here. Basically, suppose that f is applied by Alice, who then hands the encrypted data to Bob, who applies g; decryption would go in the reverse direction (Bob, then Alice). Alice knows the key for f, Bob knows the key for g. By definition, Bob only works on what Alice produced, and Alice uses a key that Bob does not know. Thus, regardless of who much incompetent Bob is, he cannot unravel the encryption done by Alice: if Bob could through using a really poor algorithm, then any attacker could do as well, and that would mean that Bob's incompetence would count as a break on f (the encryption performed by Alice).

This points out that the "unrelatedness" of the keys for f and g can be obtained by either generating both independently of each other, or by producing the two keys from a Key Derivation Function. For instance, there is a master key K, and you run it through a KDF to obtain 256 bits of output; the first 128 bits will be the key for f, the other 128 bits will be the key for g. If the KDF is secure as a KDF, then the two keys will be sufficiently "unrelated".

Using the same key for both algorithms ("AES" and "HomeBrew") could prove deadly. Deriving one key from the other could also be problematic, depending on how you derive them. Deriving both keys from the same source with a KDF that is sufficiently one-way ought to be safe.

The above is the "mathematical" answer. But cryptography does not happen in the ethereal world of mathematics. At one point, you run it on actual hardware. Even with "unrelated" keys, the combination HomeBrew(AES) can still be harmful in the following ways:

Software is secure only insofar as it is reviewed and reviewed again and fixed. This is a time-consuming process. By implementing two algorithms instead of one, you doubled the quantity of code to review, and thus, mechanically, halved the available workforce for the review of either algorithm.
Computing "HomeBrew" might be fast, but certainly not as much as not computing "HomeBrew". By cascading the two algorithms, you increased the computational cost of doing encryption. This may imply increased hardware costs, or higher latency, and possibly degraded user experience. If the user experience is too much degraded, then the user may want to actually skip the encryption step, and then security has been seriously harmed.
"HomeBrew" being, well, home-brewed, it is not compatible with anything else on Earth. When you use standardized algorithms, you may have the choice between several implementations. For instance, is using normal SSL/TLS, you can rely on the existing OpenSSL library, but if at some point you get fed up with the hole-of-the-month feature of OpenSSL, you can switch to another implementation like GnuTLS, which implements the same protocol -- you can do that on one side without impacting other systems, since they all run the same standard protocol. By using a home-brewed algorithm, you squander these advantages. You are now married with a single implementation and must stick with it until the End of Times.
If you use AES(HomeBrew) instead of HomeBrew(AES), you get all the disadvantages above, and you get a brand new one as well, which is that "HomeBrew" now processes the actual plaintext, and may leak information about it through side-channels. In that configuration, you lose all the mathematical security that I was explaining above: incompetent Bob cannot reveal anything about the plaintext when he only ever sees data encrypted by Alice; but if he gets the real plaintext, then anything goes.

  proportionally to your ability to keep the scheme secret and your crypto skills

Neither algorithm secrecy nor crypto skills can be measured or even quantified, so your "proportionally" is meaningless.

This is a fundamental point: as per Kerckhoffs's principle, we use public algorithms because we do not know "how much secret" a given algorithm can be, especially since it is implemented as software, and also exists as source code, and in the head of one or several developers. When we want security, we do not want just security; we also want to know how much of the stuff we have. And we cannot do that with a secret algorithm.


Authentication of temporary worker without a badge (physical security) In our company we have a procedure to verify internal worker but we cannot use it for temporary worker. We cannot use badges and because of privacy reasons we cannot use any photos. Is there any other way to authenticate them? For example I meet someone very late in the company building and nobody else is there. How can I find out whether the person belongs to the company or not?

Some years ago we used "generic" badges with the word Contractor and a number.  There was an intranet page with the names of current contractors and their badge numbers.  Contractors were required to wear their badges and told they must produce picture ID (like a driver's license) on request of anyone wearing an employee badge.

This was in a medium-security environment with few contractors or temporary workers, and it worked pretty well.


What is the point of making a complicated PUBLIC password? I have downloaded a couple of Virtual Machine images from http://modern.ie, in order to test different versions of Internet Explorer.

When running these images, a complete Windows environment is started, with a default user account. The details for the user account are displayed in clear text on the Windows desktop background:

What is the reason for complicating the password (e.g. Passw0rd! instead of just password), when the password is clearly visible to anyone, and is supposed to be public?

Reason may be:

This Windows has implemented a strong password policy, thus the user MUST HAVE a "strong" password.


Are passwords in memory? I have an encrypted HDD (dm_crypt). That's why I store my passwords in a simple text file. I usually copy/paste the passwords from it. Ok!
Q: If I open this text file then it goes into the memory. So all my passwords in clear text format goes "there"..will the passwords be deleted from the memory if I close the text file? Could the memory that I'm using accessed by other in real time? Are there any better/more secure ways to copy/paste my passwords? E.g. to set that if I press Ctrl+V then it should clear the clipboard? Running Fedora 14..
Or how can I "encrypt my RAM"? Are there any ways for it?

Thank you!

Bluntly put, yes, they could. That's the massively oversimplified answer.

The more complicated answer is that you need to understand how your operating system handles memory. You might hear talk of rings, privilege levels etc. Let me explain briefly:

When your operating system starts (getting passed the whole 16-bit BIOS thing) it basically has a whole pile of memory (your entire RAM) to work with and does so in a privileged mode, which means it can do whatever it likes to any part of memory.
However, x86 architectures since 1980-something before I was born have supported the concept of protected mode, where the CPU hardware provides mechanisms to allow the operating system to launch applications in such a way that their memory addresses are segregated.
Thus this protected mode allows the operating system the ability to create a virtual address space for each application. What this means is that an application's concept of memory is not the same as actual physical memory addresses and that the application does not have privileged access to memory. Indeed, applications are directly prevented from modifying each other's memory addresses because they can't see it, except via well defined requests to the operating system (syscalls) for requests for things such as shared memory, where two processes share an address space.

(this is a simplification and I'm skipping huge chunks for brevity's sake, but that's the gist - applications have their requests to access memory managed by the OS and hardware).

So theoretically, you're OK, right? Not technically true. As I said, operating systems do provide well defined ways to access other processes' memory. In terms of the possibilities, here are how a few might present:

If I dump the memory of the application, I can resolve that stored password fairly easily.
A debugger or an appropriately designed userland-style rootkit might be able to provide me access to that memory. I'm not an expert on such techniques, but know it can be done under certain circumstances.
Finally, the operating system may be self-defeating here. The virtual memory you have access to has some other consequences. Operating systems present it as virtual because they often swap memory in order to ensure there is sufficient RAM available for currently running apps. So an interesting attack might be to cause the system to swap, then crash it and examine the swap partition. Is your swap encrypted too?

Finally, I should point out that if your attacker is running code in the kernel via a kernel module, the game is over anyway, since there is nothing stopping them searching your memory space for ascii strings.

However, to be realistic:

If your kernel is compromised via a rootkit, a keylogger is probably easier to implement than something designed to scan memory in terms of grabbing your passwords.
Userland style rootkits involving debuggers for evaluating programs not designed to be debugged (i.e. without debugging symbols etc) are not going to be an easy thing to implement, even if they are theoretically possible. It also isn't easy to exploit this - you, the user, would have to be tricked into executing said editor under the debugger which probably implies social engineering or physical access.

My recommendation, however, is that you never store plaintext passwords anywhere. If you need a reminder, I suggest using a partial incomplete prompt that will jog your memory and allow you to deduce the passwords but reasonably prevent other people from doing so, even if they know you. This is very far from ideal, but better than plaintext passwords.


Authenticating on the client with OpenID Connect using Authorization Code flow? Our company has a series of software suites that we are tying into a single OpenID Connect Resource Server.  All but one of our applications can use Authorization Code flow as normal, redirecting Resource Owners to the Resource Server's authentication page to check credentials before being sent back to the Client.

However, we do have an e-commerce application in which we would like to allow the user to log in from the Client site itself.  For example, if a user has not logged in and is in the checkout process, we don't want the user to have to interrupt the flow in order for the Resource Owner to log in.

We own both the Resource Server and the Client, so I know that we can use Resource Owner Password flow in order to accommodate this scenario.  My question, however, is if we can somehow use Authorization Code flow in some way so that the Resource Owner does not have to leave the Client in order to authenticate?

The main idea of the authorization grant flow that the client does not know user credentials at all. So there is no legal way to do it.

But as WA you can try to send authorization request directly to Authorization Server and emulate redirect behind the scene (with assumption that you owns both client and server and takes the responsibility for breaking the spec ).


For LUKS: The most preferable and safest cipher? I'm about to encrypt two of my hard drives using LUKS, since I can't really do it myself I use the guide on the Arch Linux wiki (which can be found here). In an example in the guide the cipher specified is aes-xts-plain with a 512-bit key size.
Is aes-xts-plain the best choice or is there a better cipher to use? I'd prefer security over speed.

There's three components you need to understand in any block cipher usage and they apply explicitly here:

The block cipher primitive. This could be one of your familiar, AES-candidate ciphers such as, well, AES, Serpent, Twofish, Blowfish, ...
The mode of operation. Using a block cipher as is, block by block is called electronic code book, but there are other modes such as cipher block chaining and counter mode, with their various advantages and disadvantages.
The initialisation vector generation scheme, such as essiv which combats various fingerprinting techniques available to attackers against CBC used for disk encryption.

So when you pick an option, e.g. aes-cbc-essiv, you're actually asking for AES, used in CBC mode with encrypted IV's based on some per-block identifier, whereas aes-xts-plain uses AES in XTS mode with plain old IVs generated from some per-block information.

It boils down to whether you trust that XTS has sufficient resistance to whitening (which ESSIV combats) baked in to the mode of encryption. At this stage, XTS is a more modern mode with more technical advantages, but has undergone less cryptographic testing than say CBC.

One point to note with XTS, from wikipedia:

  Because of the splitting, users wanting AES 256 and AES 128 encryption will need to choose key sizes of 512 bits and 256 bits respectively.

Care needs to be chosen generating key sizes with this mode such that each block uses a key of the desired bit size. I have not looked at the LUKS information to see how it, or cryptsetup, divide up its keys; this may be something you wish to do to ensure you have the correct level of security you desire. As such, following your guide, 256-bit encryption has been used per block (with the 512 key split into two parts).


What are the tradeoffs between a common login site and login-per-site? If you have multiple products/sites under a common domain, what are the advantages and disadvantages, from user convenience to security, of having a common login page? For example, this site uses https://security.stackexchange.com/users/login for login. Google uses accounts.google.com and Microsoft uses login.live.com. However Apple doesn't have a common page, Facebook has the login form on the home page and most banks do too.

From a security point of view, both have their own issues and both have their advantages. Both can be made more or less equally secure.

If you use a login-page per service, you might want to synchronize passwords, using, as an example, LDAP or something like that. Otherwise, users may need different passwords per site/service. On the other hand, if you do not synchronize passwords, you allow users to have different passwords per service.

If you use a single login page for all your services, you need a security token to allow access to different sites. There are a number of frameworks for this, so try not to re-invent the wheel.

In general, when you make a choice, you will consider at least:

What is the image that you want to give to the users? A single entity or just a bunch of services?
Are the development groups of the different services sufficiently aligned with your security-token solution?
Do you want to allow your users to use different passwords per service? Did you think about password-resets?


How does HSTS stop MitM attacks? I know that until a few years ago, someone could set up a fake wireless AP, and use something like SSLStrip to lure the victims into connecting to insecure versions of the major websites, such as Gmail, Facebook, etc. Although, they had HSTS this was still possible. But, now as I see this is no longer possible for the major websites. What has changed since before few years. How does HSTS now prevent these type of MitM attacks?

The HSTS header stops MitM attacks by instructing the browser to always send HTTPS (as opposed to HTTP) request to the domain until the policy expires. So a browser that respects the header would send a request to https://example.com even if the user clicked a link to http://example.com.

The logic behind HSTS has not changed since it was defined in an RFC in 2012. What has changed is that today almost all browsers implement it. Remember that it is the browser that enforce this policy! Can I Use reports browsers supporting it from the following versions:

Internet Explorer 11 (2015)
Firefox 4 (2011)
Chrome 3 (2010, possibly also supported earlier)
Safari 7 (2013)

(How Firefox and Chrome managed to support HSTS before the RFC was out is a mystery to me.)

So people using browsers older than that will not be protected even if the header is set. That might account for why you have the impression that setting the HSTS header did not use to help against SSLStrip earlier.

Another reason for HSTS not helping can be that the user has never visit the page before the attack. If the browser has never seen the header it can not enforce it. This can be solved with preloading.