Stealing Facebook HTTPS cookies with captive portal I have a security concern. As we know, many public hotspots redirect you to a login screen when you try to surf the first web site.

For example, if I connect to such a hotspot and then visit https://www.facebook.com (from a computer where I'm already logged in that site) I get redirected to the hotspot login screen, without any certificate warning in my browser.

Obviously, the initial HTTPS request made from my browser contains my session cookie ("Cookie:" HTTP header).

While doing the redirection to the login screen (ICMP or DNS based redirection), will the hotspot know my HTTPS request content, and so, my session cookie?

I assume that a malicious hotspot can read my first HTTPS request:

When the browser tries to connect to facebook.com:443, it will do the certificate handshaking;
The hotspot will reply sending a valid IP-based certificate, so, the hotspot will impersonate "facebook.com" and will read my original HTTPS request content;
After that, it may reply with a 301/302 redirect to the hotspot HTTPS login screen, without any warning in the browser client.

In this way, it will be possible for a hotspot to know the content of the first HTTPS request?

If you visit HTTPS sites and get redirected without any warnings then the problem is that your browser doesn't correctly validate certificates - a good browser would display a warning as the captive portal's certificate does not contain the domain you wanted to visit in its common name field.

A possible vulnerability would be if you visit the site over HTTP, but there are solutions to mitigate this such as the Secure Flag on cookies that tell the browser not to send this cookie over HTTP - and HSTS which makes the browser automatically convert your HTTP requests to the site into HTTPS requests, in addition to preventing you from bypassing the certificate error if an HTTPS connection can't be made.


avoid hitting DB to authenticate a user on EVERY request in stateless web app architecture? Summary

Once a user logs into a web site and his username/password credentials are verified and an active session is established, is it possible to avoid hitting the DB for each and every request from that user? What is the recommended method of securely authenticating subsequent requests for the life of the session, while minimizing DB queries and other internal network traffic?

Background

In a stateless web app server architecture, where each request has no knowledge of any prior activity from the user, it would be necessary to query the DB on each and every request from that user (typically by querying the session ID stored in a cookie and transferred in the request header). But what if some basic information was encrypted and stored in that Session cookie that had enough information to validate the user for non-sensitive, non-editable requests? For such requests, you could as an example encrypt and store the user ID and something that uniquely identifies his machine as much as possible (user-agent + ip address) in the Session data. The key used to encrypt the data could change daily making it difficult for any hacker to clone the Session data on a different machine. When the Session expires you would need to fully validate the user's credentials. The fact is, the biggest threat to hacking a user's session would be someone using a user's computer that he or she left unattended. Should I just not worry about this and let some level of caching between the web app servers and the DB take care of expediting the authentication process? While it may seem to be unnecessary optimization, it seems like a candidate ripe for improvements in efficiency since each and every request requires this process. Thanks for any suggestions!

Yes it is possible, and this technique is widely used.

It does have some minor drawbacks compared to stateful sessions:

It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires.
The use of a server-side secret to create the tokens creates a single point of failure: if the secret is captured, an attacker can impersonate any user.

Deciding whether to use stateless or stateful sessions depends on your performance and security requirements. Online banking would tend of use stateful sessions, while a busy blog would tend to use stateless sessions.

A few tweaks are required to your proposed scheme:

Encrypting the token does not protect it from tampering. You want to use a Message Authentication Code (MAC) which does protect tampering. You may additionally want to use encryption, but that is less important.
You need to include a timestamp in the token and put a time limit on their validity. Somewhere around 15 minutes is sensible. Normally you would automatically re-issue shortly before the timeout, and usually the reissue would incur a database hit (although even that can be avoided)
Do not include the user's IP address in the token. Approximately 3% of users will legitimately change IP address during a web session, due to modem resets, changing WiFi hot spots, load balanced proxies and more. While you can include the user agent in the token, it is not normal to do that - consider it an advanced technique to use if you are sure you know what you're doing.
If an attacker captures a session cookie they can impersonate that user. There is nothing you can really do about. Instead, put all your effort into preventing an attacker capturing the cookie in the first place. Use SSL, use the "secure" cookie flag, fix all cross-site scripting flaws, etc. And have some user advice to lock their screen when their computer is unattended.

I hope this is helpful to you. If anything is unclear or you need further information, leave a comment and I will see if I can help you further.


Can I prevent timing attacks with random delays? I read recently about profiling for valid user accounts with timing attacks, IE the application-under-attack takes a predictably different amount of time to process say a login on a non-existent user from an existent user. Yet I've never seen in any examples or framework code any protection against this. Would it be sufficient to simply insert a random delay before the response so that the timing attacker is getting a whole mess of response times? If so, why haven't I seen this? If not, what's bad about this scheme?

This is actually a common misconception because intuitively, it seems like adding random delays should thwart timing attacks, until you think about it a bit deeper.

Theoretically, if the lengths your random delays are unbounded, ie drawn from [0, infinity] then it would thwart a timing attack for the reason that you suggest. In practice you A) don't want to make legitimate users wait an infinite amount of time for their login, and B) have to draw your random delays from some finite range [0, a]. This means that on average (ie with enough samples) you are simply adding a/2 to the time.

So let's say that without random delays you have the following timing profiles:

query existing user name: x ms
query non-existing user name: y ms

With random delays you now have (on average):

query existing user name: x + a/2 ms
query non-existing user name: y + a/2 ms

Since x - y = (x + a/2) - (y + a/2), the timing difference is still there for an attacker to exploit. The only thing that you've changed is that in addition to having to filter out network lag, cpu-scheduling lag, load-balancing lag, etc, they also have to filter out your intentional sorta-random lag. A successful timing attack will already be doing multiple queries for each username and averaging, but now they may have to add more samples in order to get their "clean" average.

Bottom-line: adding random noise may make the attack slower, but it will not make it any more complex.

The only real way to protect against timing attacks is to make sure that every possible code-path has takes the same amount of time.

query existing user name: x ms
query non-existing user name: x ms

Then there really is no way to tell those two apart.

Warning! Writing time-invariant code can be tricky, hence the maxim "don't roll your own". If you can find a login-manager that already implements timing-invariance, then using that would be both easier and safer.


Do you rather trust a widely adopted algorithm or an underdog if they're cryptoanalytically on a level playingfield? If it comes to the security a hashing or encryption algorithm provides, we never know the full story. There's that part that we (respectively the public research) understand and can reason about, but we also know that there might be weaknesses we do not know about and though we can't reason about things we don't know, still that unknown part is relevant AND is affected by certain parameters.
If you for example have two symmetric encryption ciphers, say AES-256 and TwoFish, which conceptually should provide about the same security, which one would you rather trust?
AES-256 is much more widely used than TwoFish. This means there is a much higher incentive in breaking it (and probably much more resources are poured into achieving exactly that). That might be an argument why to prefer the underdog. On the other hand, one can also argue that much more public research is going into AES-256 for the same reason and therefore IF something was fundamentally broken, the chances that it would be publicly known are higher.
Or do such properties cancel each other out anyway and thus adoption rate of an algorithm is of no relevance to security considerations at all?
What would you put more trust into and why?

Trust the widely accepted algorithm.
Not because the algorithm is better. Well, it does matter: if an algorithm is too much of an underdog, it won't have had enough scrutiny and so there's no reason to trust it. But mainly because comparing algorithms, as long as they're reasonably reputable, is meaningless: they're fine and that's it. It's not the algorithm that kills you, it's the implementation.
With a widely-used algorithm, you get a better selection of implementations, and the implementations themselves have better scrutiny. That's the important thing. So don't use an underdog for which there's only one or two implementations and nobody really looks at their code. Use a popular implementation of a popular algorithm. Popular AES implementations receive more scrutiny than those of any other block cipher. Among ciphers, only ChaCha20 receives as much scrutiny.
This is true especially if you're worried about NSA-level adversaries. We have some historical data about NSA's capabilities. We know that when they advised on the design of DES, they made it more robust to an attack technique that wasn't publicly known at the time (differential cryptanalysis), and vulnerable only to brute force with a budget that they didn't have, but were confident of reaching before anyone else. We know that when GCHQ invented Diffie-Hellman, it was rediscovered publicly less than a decade later. We know from the Snowden revelations that in the early 2010s, NSA couldn't break popular encryption primitives, but could effectively break most software due to implementation bugs.


How can I determine the common cryptographic suites I need to enable on my browser for common websites? How do I determine the common cryptographic suites I need to enable on my browsers (I use IE11, Firefox/Nightly 49, Chrome 51) running on Windows for common websites, for eg, www.google.com, www.w3.org, www.microsoft.com, etc?

The end game is to ensure that all (the above listed) browsers can access the specified sites I'm interested in.

To see which cipher suites are used by the browsers have a look at the client tests at SSLLabs (you need to look at the details for each browser). But it might be better to simply use known good configurations like the recommended configurations from Mozilla.


Segregating Offline Server and Internet Connection in one pc What I want to do:

Setup a PC with two routers. One router is directly connected to the internet, the other is connected to an offline workspace server. My client will be connected to both via a physical ethernet switchbox. The purpose of the server is to act as a database/webserver for various research. I would like to have the capacity to securely store my data away from my regularly used computer, but still have on-the-fly access when its needed.

My question:

What potential threats could be posed (by a remote attacker) to the offline server if the connecting device is temporarily not connected to an outside connection?

Possible Threats I see:

Any persistant spyware on the system would still be able to access anything recorded on my client machine and possibly see cached information about the server connection.

Other considerations:

Server and client will not have wifi/bluetooth hardware installed, only cable ethernet.

Any malware you get on your workstation can then do whatever you could do to the server, including copying any files, saving credentials, etc.  Additionally, while you're connected to the internet, the malware could essentially proxy attacker traffic to the server.

The setup you've described is arguably more secure if your client is not compromised.  Your server is essentially segregated from the internet, so reduces its vulnerability to attack.  Of course, you're also adding complexity: how will you install new software, patches, etc.?  You'll need some way to get that traffic to/from the internet.


Is it secure to automatically unlock encrypted system drive using the TPM PCR values? A simple way of automatically decrypting system drive at boot time:
clevis luks bind -d /dev/yourdrive tpm2 '{"pcr_ids":"4,5"}'
systemctl enable clevis-luks-askpass.path
When I booted another OS on the same machine, tpm2_pcrread listed mostly identical PCR values, except for 4 and 5. I understand that PCR 4 is a hash of the MBR and partitioning data, and PCR 5 is generated by the code in MBR. Besides, it's an EFI system.
If an attacker makes a copy of the entire disk, can he generate the PCR 4 value by hashing the stolen MBR and partitioning data?
Update:
If you google for enabling automatic unlocking of encrypted system volumes in Linux, you might find the above simple commands, but they aren't very secure. Based on CBHacking's answer, an attacker could read out or calculate the PCR values, which are used as encryption key of the disk encryption key.
Some other, much longer guides explain how to upload your key to the TPM and use TPM sealing to protect it.

While I don't know the specific details for LUKS, the way TPMs are usually used for disk encryption is that a key (typically used to decrypt or "unwrap" the master encryption key) is stored in the TPM and "sealed" to specific values in specific PCRs. TPMs let you specify a policy for when to unseal a key; in this case, the policy would be "don't unseal the key unless PCRs 0-5 (or even more) are <their current values>".
This means that the attacker can't simply figure out the expected hashes and then use them to decrypt the drive, because those values are useless by themselves. They need to actually be in the PCRs for the unseal policy to be satisfied. You can't write directly to the PCRs, or reset them (except as the system boots), either. You'd have to figure out the right input to take the PCR from whatever value it has to the one it expects. Assuming the hash algorithm used by the PCRs is strong against collisions and preimages, this is infeasible.
Of course, if you can control what gets hashed ("extended") into the PCRs from boot, then you can make them arrive at any value you want. Preventing this is the duty of the CRTM (Core Root of Trust Measurement), which is generated by hardware-enforced code (provided by the chipset vendor) that runs before anything else. This code measures the firmware (BIOS) of the system before executing it, extending all the code to be executed into PCR0 and the firmware configuration data into PCR1. The firmware itself measures the subsequent code-to-be-executed and extends that into suitable PCRs.
Because the CRTM is made using code that's integral to the chipset - possibly even integral to the CPU - an attacker can't replace it with something that lies about the measurement of the firmware. Because the firmware is measured, the attacker can't replace it with something that lies about the measurements of the boot metadata, etc. which means that the boot metadata can't be replaced with something that lies about the measurements of the bootloader, etc. The CRTM is - as its name implies - the root of a chain of trust; as long as the CRTM is what you expect (or the TPM's unseal function requires, per policy), you can be sure that each subsequent set of PCRs were extended legitimately and their values reflect the true hashes of the code that ran. Thus, if they are also the expected values, you can be sure that the boot code was not modified, such as to boot an alternative OS that will unseal the disk encryption key and then let you read the disk without having a valid login password.
As such, not only can an attacker not use the computed PCR4 value to decrypt the disk correctly, they can't even put it into PCR4 - not without having the wrong values in the lower PCRs - because the code that would extend the required sequence of values into PCR4 would itself have been extended into some lower PCR, and that code isn't normally there so the lower PCR would have an unexpected value and the TPM wouldn't unseal the key.

Mind, you do probably want to seal the key using more than just two PCRs. If you don't use PCR0, then modified firmware wouldn't be caught, and if your motherboard allows arbitrary (or buggy) firmware to be installed then the whole chain of trust would be broken. If you use PCR0 but not PCR2, then extensions to the firmware won't be checked, and those might override what data gets extended into PCR4 and PCR5.
For an example of which PCRs to use, consider BitLocker's default PCR policy when using the TPM on computers with native UEFI (search for "validation profile for native UEFI"): it checks PCRs 0 (CRTM, firmware code), 2 (firmware extension code), 4 (boot manager code from the UEFI system partition), and 11 (which Microsoft's boot code uses to store BitLocker access controls). This list is customizable; for example, if you want to prevent unsealing the key if the user changes any UEFI/BIOS settings at all, you might also check PCRs 1 and 3.


How to achieve other security compliances/certifications on AWS after satisfying HIPAA? Our infrastructure is built entirely on AWS and we went through the HIPAA process to ensure that our system is HIPAA-compliant. Where should we look or what next steps can we take to obtain other certifications (e.g. ISO 27001, SOC 1/2/3)?

That entire depends on what certification you are looking for. If you are looking to become PCI-DSS compliant as well, you have companies that will walk you through the process/ do the certification for you.


Can my employer monitor my web usage on my home network? I have a work phone and a personal phone, both using the same Apple ID account.  I noticed that the searches from my personal phone are showing in the browser history of the work provided phone.

Can my employer see this history even though it was done from my home on my personal wifi and personal cell phone? The work phone has an exchange email account set up to access my work emails if that matters.

I'd assume your browser history gets synced because you're using Safari with iCloud syncing, or something like that.

If you're worried about that, you should be able to turn of Safari's syncing feature on both phones. Or maybe (I haven't used Safari in ages, so I don't know if it exists on Safari, but I assume so) use private browsing mode; I'd assume nothing you do in private browsing mode would leave your phone.

Finally, you could use two different Apple IDs, one for your work phone and one for your private phone. Seems like that would be the smartest thing.

Still, even if you continue syncing your browser activities, your employer shouldn't have access to it unless they have access to the account the apple id belongs to. If you're using your own private apple id, and not a company-provided one, and you did a factory-reset on your work phone before returning it, I'd assume the danger was minimal.


Is Vimium (Chrome extension) really safe? I really like the Chrome extension Vimium. It significantly speeds up surfing for power users. However, when you install it, Chrome warns you because this extension injects JS code on every page you visit (which is potentially unsafe).

The author responds to this with "Don't be alarmed. Vimium never talks to any servers and does absolutely nothing with your data. Read the open source code if you're paranoid."

I have no reason to be suspicious except the fact that if there is malicious JS code in this extension, it could really do a lot of damage (steal passwords etc).

One way of verifying that this extension is indeed safe is by monitoring Chrome network communication.

Other would be (as author suggested) to inspect the code. Has anybody already did this, and if yes, what are the findings (preferably published on the web)?

It's not malicious. That doesn't mean that it's 100% safe (almost no piece of software is), but if there are any security holes, then they will be bugs, and not something the author has intended to do. It has 67 contributors on github and I'm sure a lot more people have wen't through the code without making any contributions (especially knowing the fact that it's mostly used by programmers who are used to VIM editor).

There are some 130+ reviews in the chrome webstore too.


How can API documentation helpful to exploit any application? Here I want to understand what if private API Documentation is exposed how can a hacker exploited the application as all the endpoints have authorization & authentication.
its is really going to be helpful for a hacker to exploit with documentation of the API?

This question is quite vague.
A service's API documentation is for end-users to utilize its service, it has information such as how to retrieve data, send data, store data, access data, manipulate data the list goes on. Usually, depending on the level of service, this API access can be restricted to different groups of people such as paid/premium users, public users, organization users or employees etc.
To answer your question, having access to your private API documentation that is meant for internal use do enable the hacker to find exploits/loopholes with how the API was implemented that is if there are loopholes to be found.

Hacker A (with no access to documentation) vs Hacker B (with access  to documentation)
Hacker B will have a heads-up over Hacker A, as simple as that. Knowledge is power!


What is the difference between a server and an appliance for PCI purposes? I administer a few hundred servers and am going through a yearly PCI audit.  This time around we need to prove that we've got anti-virus protection on our "systems commonly affected by malicious software (particularly personal computers and servers)"

The systems I work on consist of several intermediate hosts (all in PCI scope) and far-end servers (also in PCI scope) that function as glorified VPNs.

So I'd say I have 3 classes of Linux servers and 2 classes of Windows servers

Linux Servers used as bastions
Linux Servers deployed from proprietary companies as appliances
Linux Servers used purely for routing traffic
Windows Servers used as bastions
Windows Servers with proprietary software on them used as appliances

Of the five classes of servers, what arguments can I make (or steps can I take) to say that some (particularly the Linux Servers used as appliances and used for routing traffic) don't fit the requirement for being ones that require anti-virus installed on them.

Note, I'm not trying to skirt the security, some of these hosts are very lightweight (1 cpu, 192 MB RAM) and buckle under virus scanning and they're not all managed in the same platform to benefit from hypervisor level scanning and they're already locked down to prohibit outbound connections to all but a handful of Internet sites.  I deployed a Clam AV server as a good faith attempt to meet the requirement, but found the machines ran out of gas very quickly.

Being very general here, a server is generally where you install an OS on commodity hardware (or as a Virtual Machine) whereas an appliance is on proprietary hardware (e.g. physical switch etc).

While you're using each of the systems to mimic what an appliance would do, all five would be considered servers.

In terms of 'commonly affected by malicious software', Windows must have AV installed. You can consider going risk based on the Linux systems using controls such as : minimal system install, extensive hardening, file integrity monitoring (to identify newly introduced software), logging, host-based IDS (such as OSSEC) with alerting, increasing internal vulnerability scan frequency etc.


What can be done to defend against acoustic keyboard evesdroping? It is reasonably well established that it is possible to determine what one is typing based on keyboard sounds, and the difference between different keys (source). This provides a significant issue to anyone who wants to defend against it. The threat models that I have in mind are 1) VoIP software that is set to record audio, either where the VoIP provider does it or someone on the other end does and 2) audio recording in public places. Both seem feasible as the previously linked question has a link to open source software to implement this attack. What can be done to defend against these threats?

Not a lot in terms of practical efforts. The paper "Keyboard Acoustic Emanations" by Asonov, Agrawal gives rise to a few potential direct countermeasures:

Using a non-mechanical keyboard, e.g. a rubber membrane keyboard. This reduces a lot of the identifying transmissible audio. Unfortunately they're not very comfortable to type on.
Record key sounds from your keyboard and play them back continuously in a random order. Personally I think this would drive me completely insane.
Play very loud white noise and hope you don't end up with tinnitus.

An indirect countermeasure is to not have any microphones within range. Don't use a microphone on your computer, and put your phones in some sort of soundproof container.

Ultimately, though, I suspect this threat is only applicable to cases where you're being targeted by a nation state actor, at which point, to quote James Mickens, you're still gonna be Mossad'ed upon.


XSRF token appended to forms dynamically I haven't seen this anywhere in the wild so I am wondering if it is safe to inject into same-origin forms the hidden input containing the XSRF token using JavaScript like this:

document.addEventListener('DOMContentLoaded', () => {
    // Get token from <html> tag
    const XSRF_TOKEN = document.documentElement.getAttribute('data-xsrf-token');
    const uri = new URI(document.URL);

    // Loop through all forms
    Array.from(document.getElementsByTagName('form')).forEach(el => {
        let actionUri = new URI(el);

        // Only append hidden input to same-origin forms with method POST
        if (actionUri.origin() === uri.origin() && el.method === 'post') {
            let tokenInput = document.createElement('input');
            tokenInput.name = 'xsrf_token';
            tokenInput.type = 'hidden';
            tokenInput.value = XSRF_TOKEN;
            el.appendChild(tokenInput);
        }
    })
});

The token would be generated per user per session and delivered with the HTML page as an attribute value on the <html> element.

Of course this would only work in the parts of the application that we require JavaScript for. It is a lot easier than putting the hidden input everywhere.

Many sites suggest using a framework for this, however this isn't a feasible option and if it must be hidden inputs on page load then the best I can do is create a helper Twig function to output the tag but that still requires that sprinkled everywhere. And if this is the case then how would dynamically created forms work?

I don't think the JavaScript method is any less secure than <input type=hidden> everywhere because the token is retrievable from the form in the event of XSS anyways, but is there something else that I am missing?

Dynamically injected CSRF tokens are a field-tested approach without inherent security flaws.

E.g., the OWASP CSRFGuard project supports that feature:

  OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file.

The iFixit tech blog also has an article on their own "minimalist" implementation of that idea:

  We use a small amount of javascript to automatically set a cookie and add a form field immediately before a form is submitted. The server then compares the form field with the cookie and ignores the request if they don't match. This frees us from the hassle of ensuring every form includes a hidden csrf <input> in every template.

In their code sample you can see that the token is added just before submission which is probably safer than adding it on document load (since something could cause the form target to change in the meantime):

window.addEvent('domready', function() {
   /**
    * Setup triggers on the .submit() function and the `submit` event so we
    * can add csrf inputs immediately before the form is submitted.
    */
   $$('form').each(function(form) {
      // Ensure all forms submitted via a traditional 'submit' button have
      // an up-to-date CSRF input
      form.addEvent('submit', function() {
         ensureFormHasCSRFFormField(form);
      });
      // Ensure all forms submitted via form.submit() have an up-to-date CSRF
      // input
      var oldSubmit = form.submit;
      // Wrap the default submit() function with our own
      form.submit = function () {
         ensureFormHasCSRFFormField(form);
         return oldSubmit.apply(form, Array.from(arguments));
      }
   });
});

There are no inherent security problems with this approach as long as you ensure that the form target has the correct origin.
It even mitigates some attacks, e.g. in this scenario. (The article is about an XSS flaw where the CSP prevents all inline scripts, so the attacker is limited to pure HTML injection. The author presents a method to change the form-action target without any JS in order to exfiltrate a CSRF token set in a hidden input field. Now if that token was instead added dynamically, the attack would have failed because your script would recognize that the form submits to an untrusted origin.)


Phising test failed e-mail to my personal account, how does this scam work? I've recently gotten a pair of "User Selkie has failed the phishing test" emails to my personal account. The email has no other information, no links or anything, and while I'm not going to respond to it or do anything, I'm wondering how this particular scam works, and if there's anything else I should be doing.

Adding a few details: This is my personal Gmail account

A few possibilities I can think of.

1: Your employer pays for cyber security auditing, and included your personal email under your information.

2: It is possible that this is a precursor to an attack and you are just someone's guinea pig.  Emails can be embedded with things like X-Confirm-Reading-To or Disposition-Notification-To in the header to let the sender know how far his email got.  This means that the attacker knows that whatever he did validated through SMTP and anti-spam protection and that you opened his email.  If he's trying to build a list of marks for a future spam campaign, something simple like this would help him keep a small cross-section on his outbound list to avoid spam filters for longer.

3: What you are receiving is redacted.  Your accounts security features striped out whatever the real threat was; so, now all you get is the taughtning message.

4: There is a payload that runs on opening the email that you just can't see.  You don't generally hear about these very often anymore, but doesn't mean they can't still exist.


The best papers on WPA/WPA2 I have to write a term project about WPA/WPA2: I should find and read five articles and write a sort of summary of the technology citing those articles. And no, the professor will not help find articles.

It is a long shot, but if there is a reader who did academical reading on this, could he/she then please recommend me such articles.

Would be greatly appreciated.

I'd suggest the following:

Practical attacks against WEP and WPA  (see also this Ars Technica summary)
Brute forcing Wi-Fi Protected Setup, and Dan Kaminsky's explanation and follow-up
Cryptanalysis of IEEE 802.11 i TKIP
A Practical Message Falsication Attack on WPA
Hole 196

Read Wikipedia's article and search on this site for WPA and WPA2.  (Actually, that would have pointed you to many of these, and then standard literature search techniques find the rest.)


Custom email domain with a third-party provider: security holes to watch out for? If I'm switching to user@example.com emails and using a third-party email service provider that I trust (for example, Google Apps), what potential security threats do I need to secure my system against?

Note that I am not referring to security threats pertaining to the email provider here (e.g. so I'm not talking about my Google Account's password or 2-factor authentication here).

Rather, I'm talking about the parts of the system that come before that.

For example, one thing I can think of is locking my domain name so it can't be transferred (ClientTransferProhibited), although that's pretty general, and not specifically email related.
What else do I need to guard against?

one security threat is about content, and you can use PGP for encrypting your email, PGP is end-to-end and if you use a strong key your email provider can't decrypt your emails in reasonable time and cost.


Obfuscating "sensitive" strings in mobile client We have a client that runs some native (C++) code on both Android and iOS, to mitigate MITM attacks we use certificate pinning.

This means that the binary includes some strings (const char * const bla = "XXXXXXXXXX") that identify the allowed certs to enable HPKP.

Some are worried that nefarious users will easily identify those strings because they look like SHA256 and are passed to relevant functions, replace them and analyze the traffic.

Would it make it objectively harder if we obfuscated those strings in compile-time and then de-obfuscate them at run-time?
Would it make it worse because now instead of being in R/O memory (Speculation... I know... it's not required by the standard but it makes a lot of sense) we just read it at run-time from some regular object?

I would like to extend Joseph Sible's comment and build upon it.

There is a rule in Information Security, called "Never trust the client!", and it holds true so far. In your case, the client is the application on the phone of the attacker. The attacker has full access to the phone, and can modify it in any way they would like. This includes, but is not limited to:

Debugging the application at runtime
Analyzing the memory of the application
Modifying the executable
Emulating a runtime for the executable to see the System Calls the application does
Analyzing the network traffic

Basically, as soon as any data is sent to the client, you have to assume that the user will find it and get access to it in some way. How do we know? Because what you are trying to replicate is some form of DRM - also known as "Digital Restrictions Management". DRM essentially aims at giving users some form of access to content, but not any form the user likes.

This has proven, time and again, to fail. In fact, the most enthusiastic and restrictive forms of DRM are those that hurt customers the most, and are those that get cracked the quickest.

You still have not answered why exactly users getting access to the internals of your application is bad, but I am going to assume that your application stores some data there that you don't want them to access, or only want to access in limited amounts.

If it's information they don't need access to, then move them onto a server and not the app. And if it's information that you want your users to have access to, then give it to them. Sooner or later, they'll take it anyways.


CSRF protection on server side? I am aware that it is best to keep my web application patched and protected against those kind of attacks, but in my case this is more experimental thing.

Is there anything useful, like module that can be used for apache (2.4.7) in order to "protect" against CSRF attacks?

The general way is appending CSRF protection tokens to the input and comparing them on each request, Apache in its configuration is not capable of storing session data about users, so it wont be able to evaluate the authority of requests. Thus, Apache modules for CSRF protection don't exist. This is the job of your web application.

Edit: there are some scratches online like this, called mod_csrf, but it's not really an apache mod in its traditional meaning. (You have to copy files to the webroot)


Pitfalls of SSD encryption Encrypting an SSD is a process that is sometimes warned should be done with caution. E.g. http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS mentions how the SSD may keep hidden space used for wear leveling where arbitrary data may be stored at any given time, such as overwritten data.

My question is as follows: Is not this attack scenario exclusive to cases where the SSD has previously at some point contained unencrypted sensitive data and only after this has been stored unencrypted, is the entire device encrypted? In other words, if the SSD never contained anything besides encrypted data since it was new, what does it matter what (encrypted) data may or may not reside in this hidden space?

This seems pretty obvious to me can be just discarded if the SSD has always contained encrypted data, however am I missing something?

Assume that GNU/Linux with luks and 256-bit AES is used for any specific example, however are there any other software/SSD combinations in particular that are dangerous? It seems outrageous that the software would at any stage give the SSD unencrypted data.

Keep in mind that modern SSDs already encrypt your data at the firmware level, so that a reformat operation can be done simply by discarding the internal key, rather than wiping every sector. This doesn't mean your data is automagically encrypted at all times - the crypto is only used to fix the NAND-wear issue. However, it does mean that a proper firmware-level format operation renders the data on the disk entirely destroyed for all intents and purposes. If you're throwing away an SSD, I highly recommend using this option. Most major OSes recognise and support the appropriate firmware command, but use of it may differ - check the appropriate documentation.

As far as the wear-leveling spare sectors go, in practice you should be safe regardless of whether or not the stored data was encrypted. Due to the internal encryption, orphaned data blocks in wear-leveling areas shouldn't be recoverable, since the IVs and sibling blocks are destroyed / missing. However, this isn't to say that you might not be unlucky - it may well be that a few blocks of file data end up being kept, leading to a case where a small amount of plaintext is recoverable. It's difficult to say.

Ignoring the internal crypto for a moment, another interesting attack is related to old remnant blocks of ciphertext. If you encrypt a piece of data with a particular key and IV, then encrypt a new piece of data with the same key and IV, it may be possible to attack that data using differential cryptanalysis or other attacks. It also demonstrates active modification of certain areas of data,  which may or may not be problematic for you depending on your threat scenario.


In Same Origin Policy, why are different protocols considered a security violation? I can understand why content from different domains is considered to be unstrusted for the same origin policy. But, how can be content from diferent protocols from the same site/domain be dangerous?

Can somebody give an example of a situation in which this can be a security concern?

To begin, an ORIGIN is composed of Protocol + ResourcePath + Port, so http:// is different to https://.

The reason why the protocol is included in the origin is because the document/resource is served, potentially, from a completely different system. HTTPS uses port 443 by default, HTTP port 80 by default. Additionally, even though you can transfer a plaintext file via FTP (port 21) HTTP (port 80), HTTP (port 443) etc. etc. each of these protocols have very different protections and controls in place.

The security concern comes primarily from questions around provenance. Big word, I know. This means, simply, that content served over port 443 is KNOWN to have originated from the place saying so. It has a certificate to prove it, that certificate is tied to a particular domain name, and if no shenaningans have been taking place and the method used correctly, you can be really sure  that the content served over HTTPS came from who you expected it to come from.
This is not the same for content coming from port 80 via HTTP. In fact, HTTP was designed to allow midway points to cache, and indeed modify the data on its way to you.

Because of these differences, content served from different protocols is seen to be within separate trust domains, which do not necessarily trust the security of the other. For example, lets say you view a webpage serving content via HTTPS (the HTML) and content via HTTP (the advertising scripts and images). Cross origin prevents lower trusted objects (advertising) from reading higher trusted content (the balance of your bank account).

CORS, at its core (haha) goes back to the Bell - La Padula model which is widely used today to separate low security clearance from high security clearance interactions.


How to detect suspicious content in a TrueType Font (.ttf) font file I got curious about how to scan or assess the risk of a particular font file before deploying it to hosts.  First line of defense, of course, is to make sure that our hosts are patched against any TrueType font vulnerabilities.

I read the excellent research from Google Project Zero and it seems like it is worth understanding risks from fonts.  I also read the answer from Tom Leek that suggests (very sensibly) trying the font on Linux before trying it on Windows because:

  it would be very hard to craft a "malicious font" which can install a
  virus on a Windows system, but otherwise works "correctly" on a Linux
  system

Finally, I installed a python library (FontTools) that allows a conversion from a .ttf to a human-readable .xml file.  In the resulting file, there are hundreds of lines of assembly code as a "hinting mechanism" exists in each .ttf file.  It is into this assembly code that an attacker would insert exploits.

For further investigation, I would like to compare a known bad .ttf file, like the ones that were used to exploit font handling vulnerabilities, with a known good .ttf files.  I imagine it would be difficult to spot the differences without intimate knowledge of assembly, but I'd like to have a look, or at least hear from someone here if such a thing is possible.  So, the question is: does anyone know of a way to analyze .ttf files for suspicious commands and does anyone know where to get a .ttf file used to exploit font handling vulnerabilities.

This is an interesting question. Font files are like other media files which might be abused by malware or within exploiting attempts.

Detecting malicious blocks in such media files would follow a signature-based approach: You or your antivirus software would be looking for suspicious pattern.

I'm not aware of a public compilation of malicious code in font files. You might have to compile your own with the help of public vulnerability databases and exploit databases.

Opening an untrusted file on another platform might be able to detect defects without exposing the environment. That is because exploit code usually targets a specific platform and is not possible to succeed on others. A misbehaving font file might then be an indicator for an attack attempt.

Converting a font file from one format to another is basically what a proxy would do (an application gateway is doing this with protocols). A strict implementation would detect misbehavior and fail the conversion. A less strict implementation would ignore the malicious parts and generate a valid file without remaining dangers.


Website with HTTPS - site exports file, is that transferred using HTTPS? I have a website using HTTPS. I have set it up so that HTTP is redirected to HTTPS.

I also have a feature where the site exports a file for user to download.

Is that file transferred using HTTPS?

Edited to add screenshot of Chrome network console to show what I see.

Web sites can't directly export files to a web browser; the browser must first make a request, and then the server responds to the request by sending some content. That is how (almost) everything on the web works, whether the content being served is web pages (HTML, CSS, etc.) or other content (like a file the server created for you).

This all matters because, for every request, it's the BROWSER that decides whether the request is sent over HTTP or HTTPS. The server has no actual say in this. The server can decide that the only thing it will do for HTTP requests is send a response that amounts to "try again, but over HTTPS" - this is probably what you mean by "set it up so that HTTP is redirected to HTTPS" - but if the request came in over HTTP, the response will go back the same way.

If you want to test, that's pretty easy. Open a web browser's developer tools (for most browsers, you can do this by right-clicking on any page and selecting "Inspect") and go to the Network tab. Go to your site and download the exported file. Look in the logged data in the dev tools (warning: there may be a lot of it) and see whether the request that made the server send the file went over HTTP or HTTPS. Whichever one the browser used, that's what the server used.


What are the most tolerable options for a more general public type not to be victimized by malware? I've talked with a new friend who is fairly bright and who can do some interesting things programming Office applications, but whose technical abilities omit infosec. And he got bitten by nasty malware.
I'm wondering what options might be most productive to offer to him. I'm not sure it's realistic to repel all dedicated assault, but cybercriminals often look for someone who would be an easy kill, and (perhaps showing my ignorance here), I think it could be realistic to make a system that's hardened enough not to be an easy kill.
Possibilities I've thought of include:

Windows 10 with screws turned down (how, if that is possible?).

Mint or another Linux host OS for what can be done under Linux, and a VMware or VirtualBox VM that is used for compatibility and may be restorable if the machine is trashed.

Migrating to a used or new Mac, possibly with a Windows Virtual Machine, but most people using Macs don't complain they are missing things.

Perhaps with one of the technical situation, point my friend to user education saying things like "Don't download software that you hadn't set out to get. The price of Marine Aquarium of $20 up front is dwarfed by the hidden price tags of adware and spyware offering a free aquarium screensaver."

This is not an exhaustive list, although it's what I can think of now. I've had a pretty good track record for not engaging malicious software, and I think it can be learned (and that documentation for online safety would be taken very, very seriously).
What can I suggest to my friend for online safety?

Perhaps with one of the technical situation, point my friend to user education saying things like "Don't download software that you hadn't set out to get. The price of Marine Aquarium of $20 up front is dwarfed by the hidden price tags of adware and spyware offering a free aquarium screensaver."

Start by hardening the mind to have a security focus mentallity, why? Because of social engineering attacks, attacks in which the attacker will fool the person into running the malware. These attacks works because the victim allowed it to happen and no amount of technical  security will stop that. Understand that the human user is a big vulnerability to security.
Example:

A Trojan horse in which the malware will be made to look like something innocent.

An attacker leaving a USB drive out with a note that says top secret.

A message like, "Hey I have found some leaked photos of you download it at link ."

and many more.
Basic stuff like:

Think before you act.

Don't trust everything you see or hear.

Don't click on strange links or ads

Don't download any and everything you see.

Don't plug in strange USB drives

Can be very powerful.
So user education first...


What are likely outcomes of being infected by cryptocurrency miner malwares (like Adylkuzz)? This week, most media spent a lot of time talking about the very famous WannaCry attack. However, another malware infected a lot of computers using the same vulnerability, and was less mediatized : Adylkuzz.

As far as I understand it, that malware uses your computer ressources to mine a cryptocurrency called Monero.

Obviously, it was not as spectacular as thousands of computers being ransomed, yet I read it generated quite a lot of money (something like a good million USD).

Since that malware is less spectacular, I assume people could just have it on their own computers and don't realize immediately they're infected. In such case, what could happen to such computers over a long period of time ?

Is it less mediatized because it is less dangerous than a ransomware for an organization ? Or in the long run would such malware cause serious damages ?

Higher electricity consumption. CPUs and graphic cards clock down when they don't have much to do, which causes them to consume much less power. But a cryptocurreny miner will keep them busy at all times. This will increase your power bill. This is in fact a common problem for many cryptocurrencies: The value of the currency is less than the price for the electricity required to mine it.
Higher risk of overheating. All that electricity gets converted into heat. A badly cooled computer can become unstable when running on full load for extended amounts of time, especially now in the summer.
Higher risk of part failure. Consumer-grade PC hardware is not designed for being under full load at all times. When they are constantly kept busy by a cryptocurrency miner, their life expectancy will be less than usual.
Noise. Cheaper cooling fans can become quite loud when the computer runs on full load. This will usually be the case when you are playing games, and in that case the game will be even louder, so it usually doesn't bother you that much. But it can be quite annoying when you are doing something where you want silence.

But what you should really be worried about when you notice a cryptocurrency miner on your system which you didn't install is what it implies for your overall IT security. When it got onto your system without you noticing, you could have just as well caught a ransomware, spyware or botnet client via the same vulnerability.


Must the different multi-factor "factors" be correlated if possible? We are in the process of securing our internal servers and there is a requirement of using two factor authentication (SSL client&server certificates and username-password).

One doubt that has come to my mind is if, when enforcing multiple factor authentication, the different factors must be relationed to each other when it is possible.

For example, if I know that some client system will have certificate X and username Y, should I reject a petition that comes with certificate X and username Z (which is valid but would be associated with another system that has certificate K)?

UPDATE: Since I see that the current answers talk about end users (browsers and certificate cards), I would like to emphasize that the communication is between several servers; the users are application users.

I have been browsing through Apache's modules1 and I do not see any straightforward way of implementing, so I do not know if my idea is just not part of the standard implementations and a bit too strict, or I am missing something.

1Admittedly, not my speciality.

In some cases of system design, you might be able to get away with blindly accepting tokens, but I doubt it.

Any security control is meant to address risks. If you want to use both a certificate and a separate credential set to authenticate a server, then you do that because it reduces the risks identified.

If you do not correlate the certificate to the credential set, then you reduce the factors to 1.5 instead of 2; any combination will do.

Is this ok? It depends on the risks that you want to reduce. If it does not matter, then it does not matter.

Here's my problem though. If a threat actor has access to the certificate, then the actor can also gain access to the credentials, and vice versa. I'm not sure how adding a factor is a control in the situation, but I also do not know your risk scenarios.


Should I remove bash from my Docker web app container? Suppose I am a dev and want to harden my web application environment. If my application does not make use of binaries like sh, ls, find, echo etc. should I just remove them from my image?

It might improve security but it's a very strange way of doing things.

What you are suggesting is to start with an image with "unnecessary" software installed and remove some of the stuff you don't need (bash, echo,...). This does not only risk breaking things, it also increases container size because the base layer with the unnecessary tools is still shipped.

A better approach is to start with a minimal image. Not alpine, that's still a full os. The more minimal approach is to use a base image that only contains the required language runtime like googles distoless images https://github.com/GoogleCloudPlatform/distroless . For static binaries, you can even start with an empty image.

That way you get an image that is as small as possible and does not provide the "attack surface" of bash.


Where a sysadmin deletes a company's data, why can't they just restore from backups As an example, in the UBS Duronio case, Mr. Duronio executed code that deleted everything in its path, but isn't there a backup server? Why was UBS hit by the loss of data? If the backup is available, even if rm command was executed, there would be a way to retrieve the backup data...

A backup, if there is one, takes time to get restored, if it can be. In other words:

Not every company has good backup practices. Considering that, as noted in the security investigation, UBS had other poor security practices it may not be surprising if they didn't have good backups.
Even if a backup has been made it takes time to restore. During this time the server is not in operation. So if it takes a day to restore, you're down for a day, which can be a devastating loss for the kind of operations UBS does.
Not every backup can be restored. The only way to know for sure is to practice restoration, and this is so time-consuming and expensive that many places never do this.


OpenSSH DOS exploit proof of concept For some research I'm looking for a working DOS exploit for OpenSSH. The OpenSSH version, vulnerable to the exploit is irrelevant. The only requirement that I have is, that the exploit should work for Debian or more general on Linux.

I've searched for exploits for these CVE's (on cvedetails.com), but found only one actual exploit, which didn't work for me.

I'd be very grateful for any hint.

edit: I believe my intentions as well as my background knowledge have been misinterpreted. My research does not target exploit development, nor exploitation. I'm working on various mitigation techniques for a number of issues with OpenSSH and other tools. As of now, I'm trying to test a couple of mitigation techniques for DOS vulnerabilities in OpenSSH, but can't find a working POC.

I'd recommend looking for non-recent versions of OpenSSH in your search. Since it's a relatively well maintained library, if there's any known exploits, they've likely already been patched. However if you look through the CVE list for working DOS methods on older OpenSSH versions, you'll be able to access all those nasty bugs that have already been patched! Both Yum and APT allow you to downgrade packages and as far as I know, neither operating system has any dependencies of the library in terms of versioning (I've never actually tried downgrading OpenSSH, but I'm fairly certain it has no upstream dependencies preventing you from doing so). Once you find a CVE and version for you, just google the "CVE-Number-Here POC" and you'll likely find some code for it.

SIDE NOTE

Please for the love of God run this on an internal network where it cannot be accessed from the Internet. You may not think you're at any risk exposing yourself like that, but you definitely are.


How do people typically perform security audits of firewalls? In my days as a pentester, we used to use tools like Nipper, combined with manual analysis, to perform audits of firewall configurations. However, in my current company we have many different firewalls and network devices, and I was wondering how people typically will audit their firewalls for security.

Note - I am not asking for specific product recommendations, though throwing out vendor names never hurts, what I am really asking for here is how people approach the task of performing audits.

To my thinking, the ideal solution would be some form of unified management for firewalls, which would allow the networking team to do all of their day to day operations, but also support change management controls, security audits, compliance reviews, and more.

I usually look firstly at the network diagrams and how the network is or should be configured. This will give me an idea of where is the perimeter, the internal networks, the functional segments and so on. I then look at what are the devices - brand, model - used to manage the environment, whether they are enterprise class and have functionality to unify the management. This should give me an indication of how much I can see centrally versus how much time I'll need to go through individual systems.

I'll look at the basic management of the firewall - firmware updates and version, user management, syslog and NTP configurations. Then I'll look at the rules.

Ideally rules will be justified/explained with a comment or link to a change control. There will be a valid source, destination with specific protocols for most rules - there will be very few instances of 'any'. Secure protocols will be used where possible, HTTPS, SFTP and justified if not. Redundant rules and objects will be disabled or removed. Application and operations teams will assist in the review to validate their requirements.

Counts on use of rules or tools to identify unused rules/objects are useful.

Once you've completed the review and you have a list of issues, questions, these should be entered into a report or spreadsheet and changes required identified and prioritised. Redundant rules should be disabled temporarily prior to deletion and comments updated. Rules which can be more restrictive should be updated and commented.

Once you've done the above across the estate, it's probably time to start again!


Will setting a BIOS Password Protect the TPM? I have Windows 10 on a Dell Precision Laptop, Bitlocker Drive Encryption set up for my system drive with TPM only and I do not want 20-number long PIN, but I want a password (like I had in TrueCrypt, but it doesn't support GUID partitions so I can't use it).

If I set a BIOS password and my computer is stolen and the thief resets somehow the BIOS password, will this get "red flagged" by the TPM and require the Bitlocker key?

Okay, so, after some more searching I solved my problem:

Bitlocker does allow you to use an actual password (but they call it a PIN) - can't be more than 20 characters, but that's still pretty good.

RUN > gpedit.msc
Select: Administrative Templates > Windows Components > Bitlocker Drive Encryption > Operating System Drives

Double click "Require additional authentication at startup"
Select ENABLE at the top
Under "Configure TPM and Startup PIN" drop-down menu, select "Require Startup PIN with TPM" > Click Okay

Double click "Allow Enhanced PINs for Startup"
Select "Enabled" > Click Okay

Run CMD as an Administrator

Enter: manage-bde -protectors -add c: tp

*Change C to whatever the drive letter your system drive is

Now, enter the password you want, can be letters, numbers, symbols, uppercase, lowercase, etc.  20 characters max.

This worked for me and now I'm happy to be secured behind a 20 character actual password and not just 20 numbers.

This data should really be more available from Windows to make it more user-friendly, so hopefully this helps you.


Replacing images on HTTPS sites with MITMf? I'm using MITMf for replacing images over HTTP, and everything works fine. But how can I replace images on sites like Google or Facebook that uses HTTPS?

My actual command:

sudo python mitmf.py -i wlan0 --spoof --arp --hsts --gateway 192.168.1.254 --target 192.168.1.43 --imgrand --img-dir /home/pi/spof/better/MITMf/img/

For sites like google and facebook several browser have preloaded HSTS (enforce HTTPS) and HPKP (certificate/public key pinning) settings. This means that the browser knows that these sites should be reachable by https only and how the certificate should look like. And this means that stripping SSL and the HSTS header (i.e. your --hsts option) will not work against these sites. It will only work against sites where the browser does not know (yet) that HTTPS is mandatory.

What you would need is to do real SSL man in the middle where you have a HTTPS connection from browser to your man in the middle proxy and from the proxy to the real server. In this case the HTTPS connection to the client is signed by certificates created by the proxy and the relevant proxy CA needs to be explicitly setup as trusted inside the browser/OS.

But from a look at mitmf I don't see that it offers an option for doing real SSL man in the middle, it can only do SSL stripping (i.e. downgrade to plain HTTP) which does not help in case of preloaded HSTS/HPKP. Thus you would need to use other tools like mitmproxy.


Convince the company not to store credit card numbers in our webapp The company I work for needs a system to perform monthly credit card charges to customer accounts. Customers will be able to update their credit card information from an online interface written in PHP (which will be presented through HTTP over SSL). The monthly charges will be run manually through a password-protected admin area of the same interface, which will basically amount to a batch call to Authorize.Net's API.

My coworkers want to store the (encrypted) credit card information in a MySQL database. They plan to encrypt the credit card numbers with PHP's mcrypt extension, presumably using Rijndael/AES or Twofish. The subject of key management was glossed over, but the following two options were mentioned:

storing keys in the database, with a separate key for each credit card entry; or
storing a single encryption key for all credit card entries in a PHP file as a variable (similar to how PHP applications such as WordPress and MediaWiki store database credentials).

How can I convince them not to go this route? We will be using Authorize.net for payment processing, so I mentioned their Customer Information Manager service as an alternative to storing credit card information ourselves. However, I don't know the subject well enough to make a compelling argument (my arguments were "none of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner").

If I am unable to convince them to use a 3rd party service like Customer Information Manager, what should I keep in mind in order to keep customers' credit card information safe? In particular, how should I manage encryption keys? Should there be a separate encryption key for each customer entry? Where can I store the keys so I can decrypt the credit card information before sending the transactions over to Authorize.Net? The two options mentioned above don't seem very sound to me (but again, I don't know the subject well enough to make a compelling argument against either).

Update: I found someone in the company familiar with PCI DSS compliance, so I'm working with him to make sure this gets done right. However, I would still appreciate answers to my questions above (both to improve my knowledge and to help others in a similar situation).

Update 2: Success! Another developer sat down and read the PCI DSS guideline and decided that it's a bad idea to store the information ourselves after all. We will be using Authorize.Net's Customer Information Manager service.

Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high.

Download the PCI-DSS 2.0 standard and be afraid.

In particular, neither of the suggested approaches are PCI-DSS compliant. Keys mustn't be stored unprotected or in the same place as the cardholder data they protect.

If you must implement this in-house, you need to isolate the components that touch card numbers from everything else, so that PCI-DSS only applies to a limited number of systems. Look at tokenisation solutions to help you keep your cardholder data exposure to a minimum. If you don't do this right you can easily drop all of your servers (or even all your corporate desktops!) into PCI scope, at which point compliance becomes difficult-to-impossible.

Authorize.net offer automated recurring billing services. For the love of sanity, use that.


Why is HTTPS seemingly so infrequently used internationally (Asia)? I've recently had the privilege of doing some traveling internationally, and I noticed that (particularly in Asia) HTTPS is very infrequently used, even on government and educational websites where users login and provide sensitive information.  I did some reading on Wikipedia about the export of encryption technologies from the USA being a potential issue, but I was under the impression that utilities like OpenSSL were pretty much free for use everywhere, and that CA's were able to issue certificates to any countries that weren't considered to be "unstable" or "at odds" with either the UN or USA (not sure of specifics on this one).  Knowing how easy it is for an attacker to sniff HTTP traffic on WiFi networks, I was shocked that these institutions weren't protecting their users by implementing HTTPS.  And without identity confirmation, there's not even a guarantee that the users are in the right place, whether on WiFi or not.

So, for anyone with any experience in international web security themes, does anyone know why HTTPS isn't being used?  Is there something else their users are doing to protect themselves that I'm just totally in the dark about?

I would say the US embargo and the cultural differences played a significant role, but there's also an undeniable level of sloppiness or lack of security awareness.

Though 40-bit SSL encryption has been available in Netscape since about 1995, many foreign banks who pioneered online payments might not have considered it safe enough. They often opted to use browser plugins to provide better encryption. The most famous is the Korean SEED system.

There's also a potential cultural thing where Asians like more ways of expressing themselves, so technical enhancements like emoticon, Flash and plug-ins/applets are potentially more acceptable. Due to competition, if one bank is offering a plug-in to secure online transactions, the others will likely follow suit. Since the banks are taking over the responsibilities, the merchants potentially invest less in security.

However, this does not completely explain why non-e-commerce sites do not use HTTPS. It is possible they looked at their banks for best security practice and noticed HTTPS was not being used. Maybe the general cyber-security education are not at the level of the western world yet. Maybe there are fewer high-profile attacks to Asian companies. Maybe the cost of obtaining a certificate is just to high (with local dealer fees and translation) for small/medium businesses. Maybe privacy laws are weak or nonexistent in certain countries and businesses have nothing to lose providing no encryption. Maybe because hosting is more expensive in Asia (you see a lot of HTTPS redirecting to HTTP).

The truth is we may never know, but come the day when most websites are HTTPS, it will be hard to find any site not supporting it anywhere in the world.


XSS injection in the name of a file to be sent I found a reflected XSS in a POST request that sends a file to the web server.
The HTTP POST Request
The HTTP 200 OK Response
When I want to try to insert document.cookie in the payload, the web server detects the dot and breaks the injection because the extension is not good.
HTTP/1.1 200 OK
Date: Mon, 23 Nov 2020 19:35:22 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=7q0ec2d0mtb7sb09sun4224lgu; expires=Mon, 30-Nov-2020 19:35:22 GMT; Max-Age=604800; path=/; secure; HttpOnly
Vary: Accept-Encoding
Content-Length: 78
Connection: close
Content-Type: text/html; charset=UTF-8
{"error":"Les fichiers avec l'extention .cookie)> ne sont pas autoris\u00e9s"}

Is there a way to bypass this?

To avoid using a dot, you could use document["cookie"] which is another way to write document.cookie. However, if (as multithr3at3d pointed out) you want to read the cookie in the response above, you won't be able to, as cookies with the HttpOnly flag set are not readable from javascript.


Prevent logging in by pressing Enter - security by obscurity? An online banking site which I use, has a "feature" which disallows a user from pressing Enter to submit a login form. For example, if you have typed your username in the Username field, pressing Enter will show a message "Please click Login to login".

Most users would follow by using the mouse to point and click. However it is actually possible to just press Tab to move the focus to the button, and press Space to submit the form.

Do you think "preventing form submit by pressing Enter" or "asking user to use the mouse" is a case of security by obscurity? They aren't using on-screen keyboards though which I believe are supposed to circumvent keyloggers.
What sort of attack/threat would this measure be likely to circumvent?

I suspect this decision was not security related at all.  Probably they had issues with users accidently changing focus on the form before they were ready because of their enter key behavior.  Facebook is very bad about this.

This company just wanted to give the user the option to prevent the enter key from doing anything but inserting a cr/lf.


Dropbox ransomware experience How Dropbox handles ransomware issues? Can it effectively restore files encrypted by ransomware? The reason I am asking is because I am looking for a bullet-proof solution against ransomware and wondering about creating up-to-date backup on Dropbox. I am still exploring other options, however, not on corporate level but rather something smaller.

Dropbox supports versioning, and the page about this says:

  If you have a Basic (free) or Plus account, you can restore a previous version of a file within 30 days of the change. If you have a Professional or Business account, you have 120 days.

So create a Dropbox account with enough storage, let it sync all your files, and keep it syncing all the time. If ransonmware strikes, reinstall your OS, install Dropbox and get the backed-up files. You will want to contact Dropbox support to do this, as they can rollback your account to a point in time before the files were encrypted.

If you want to build a solution yourself, you could get a computer and install FreeNAS on it (or buy a preinstalled box), and use it to backup. There's a lot of Windows applications to backup things. So you don't depend on Dropbox and will not have to download hundreds of GBs of data if ransomware got your files.


Is UAC actually worth it? Windows UAC: It's annoying. It seems pointless. Should I just disable it?

Or in other words - is there actually a real risk of something malicious happening if I do?  Is there malware out there that works only if it's disabled?

I appreciate it gives a theoretical security, but is it practical?  As long as most people keep it on, am I ok to turn it off?

UAC is, in my opinion, too highly praised. True, it does protect against the more simplistic admin-requiring malware installation scenarios which were more prevalent before its advent, but it created new such scenarios, which are not much better.

In short, all that UAC changed is the following.

Before it came to be, malware authors could make malware that requires admin rights just hoping that their victims will be using an admin account.

After UAC was built into the newer Windows versions, malware authors switched to a better form of social engineering, disguising malware as legitimate software requiring admin rights. This kicked a few uncapable fools from the mal-market (good riddance), but the ones who remained and adapted their viruses to use this new attack scenario got a good chance to attack users who are not logged in as the administrator.

How? Well, UAC in non-admin mode allows you to enter the admin's password to start an app it's warning against. Moreover, it explicitly requires you to do so to start the app. From the point of view of user-psychology, clicking "Yes" and entering the password in a UAC prompt is way easier than choosing to run the program as an administrator in its standard settings.

Yes, you see, whatever the guys from Microsoft say, from the user-psychology point of view, UAC is a complete disaster. Just look at it: for example, most non-tech-savvy users with Java installed are bound to get the perfectly legitimate jucheck.exe screaming for admin rights to just check for updates every single day. Yikes. And that's just the tip of the iceberg. Many regular users get so used to UAC prompts popping up on their screen that they don't care about what the prompts say about the suspicious programs at all.

In short, if UAC annoys you, I'd recommend to disable it. It's just not worth the bother. Just make sure you're not often logged in with an admin account (like most Linux users do). It's basically the same as using UAC, but less annoying.


What is the most up-to-date secure method for storing .ENV variables? I am improving the security on my php website. I am not using any frameworks or cms. The credentials are currently stored in plain text in the relevant php files. While researching, I came across this question Why use .ENV? What's wrong with storing secrets in a config.php file outside root directory?
The first answer by Schwern makes the argument that .ENV variables are fine and

".ENV is a convenience and, ideally, is not used in production"

I do not have the reputation to comment so can anyone explain what should "ideally" be used in production?

The first answer by Schwern makes the argument that .ENV variables are fine and

".ENV is a convenience and, ideally, is not used in production"

Before that line, you skipped this line:

To clarify, the security and flexibility are gained by putting secrets into environment variables.

If you're not comfortable using .ENV, then just pass the credentials as environment variables. .ENV is just a convenience around environment variables.

The credentials are currently stored in plain text in the relevant php files

From a security POV, storing credentials in a plain text vs. passing them as environment variables is functionally equivalent. You're not making your website more secure by making this change.

The context for that question was storing plain-text secrets in the code repository vs. passing them through .ENV, and which approach was more secure. Unless your situation is similar, that answer is irrelevant


Do bug bounties ensure that software is secure? I've been looking into third-party encryption tools and noticed that this particular provider has a bounty going on. Does this mean that they take security more seriously than other providers? How long can bounties like this last? I'd like to see some examples if there are any similar going on right now or have been in the past.

Do bug bounties ensure that software is secure?

No, they don't ensure that software is secure. But they might lead to more secure software if the bounty means that the vendor is actually committed to better security.

  Does this mean that they take security more seriously than other providers?

Usually vendors who have bug bounty programs invest more resources into keeping the software secure. With single target bug bounties this can (but don't need to) be different. Such cracking contests might be more a marketing thing so that the software can be marketed as "unbreakable even by experts". In these case the bug bounty often does not cover typical real world attacks. See also The Fallacy of Cracking Contests
.

  How long can bounties like this last?

This is fully up to the vendor.

  I'd like to see some examples if there are any similar going on right now or have been in the past.

A search for bug bounty unbreakable cryptography gives you other such programs.


Securing USB flash drive on linux We have a industrial system(running on linux) with a USB port. We have the USB port only for copying certain data. Other than this we don't want the USB drive to contain any other executables or scripts.etc. As end users may copy a worm/virus on to a USB device and attach to the system. What are the ways to avoid this ?
I'm aware that if its mounted with noexec option the user cannot execute the files.
What are the different ways to enhance the security of the USB devices?
Update: The system runs without a GUI like KDE/GNOME.

I'd start with locking down BIOS so that the device can't be used to boot the system.

Then, I would disable automounting for USB devices. At this point, you need to limit user's interaction with the USB drive "subsystem". For example, this copying of data is usually required to dump logs or acquired data, therefore you can boil it down (in most cases) to:

mount the USB device
verify it is valid and has enough space
select the data you want copied among a choice of possible files
  (e.g. datalog.001, 20130402-dump.csv, anything in /var/local/data...)
copy said files
(optionally) re-read and check their MD5/SHA hashes
(optionally) delete/rotate the originals to free space on device
unmount the USB device

The process only allows interaction in the "select data", and that interaction is limited to a multiple checkbox choice. There are utilities (zenity, kdialog, or dialog for curses systems) that allow you to build a "locked down" interface in next to no time: this is an adapted example

#!/bin/bash
n=0
for file in $(ls /tmp); do
    n=$[n+1]
    echo "$file $n off" >> /tmp/output.txt
done
dialog --checklist "Items to copy:" 20 60 20 \
    $(cat /tmp/output.txt) 2>/tmp/output2.txt

for i in $(cat /tmp/output2.txt); do
    cp $i /mnt/usbkey/
done
rm /tmp/output*

Now, the user can only usefully plug a USB key when the system is already booted, and when he does, nothing happens; when he chooses the "Data Dump" function, his choices are limited.

You shouldn't need it, but be aware of possible exploits through shell metacharacters embedded in file names. Always get the file names with ls (or equivalent) and filter them.

Note: as noticed by Gilles, the above example is flawed: dialog there will only support names without spaces. For a more robust implementation, you ought to use something else than a bash script, possibly Python with Urwid or, depending on the existing interface, a CGI or web module.

Update

The best that can be done in bash and with dialog is, unfortunately, to remove the problematic files (those with $, space, single quote, double quotes...). A better, if lacking, script is this. It ignores any file not adhering to its naming convention; it may still be useful to someone (e.g. to copy logs. Unless you're now closing data-九月.log).

#!/bin/bash

DIRTOCOPY="/tmp"

clean() {
        rm -f .tmp.dir .tmp.out .tmp.cpy
}

clean

n=0

ls "$DIRTOCOPY" > .tmp.dir

while read file ; do
    if ( echo "$file" | grep "^[A-Za-z0-9._~^-]*\$" > /dev/null ); then
        n=$[n+1]
        echo "$file $n off" >> .tmp.out
    fi
done < .tmp.dir
rm -f .tmp.dir

dialog --checklist "Items to copy:" 20 60 20 \
    $(cat .tmp.out) 2>.tmp.cpy

cat .tmp.cpy
exit

for file in $( cat .tmp.cpy ); do
    echo cp "$file" /mnt/usbkey/
done

clean

Python

To do better, we have to employ a less fragile costruct. As suggested above, this can be done in Python using the urwid library (apt-get install python-urwid on Ubuntu, I'm told. Otherwise, installation is straightforward). This is little more than a modified tutorial I whipped up - yet it works even with files that either choke dialog or are copied incorrectly:

/tmp/tests/file with spaces.txt
/tmp/tests/file "quoted, but only once.txt
/tmp/tests/file "quoted twice", that's right!.txt
/tmp/tests/ceci n'est pas une |.txt

The only thing is that UTF8 files may have their names mangled: I have a file that's named "Chissà?" in Linux EXT3, and while it remains intact when copied to Linux or NTFS, it became "Chiss????" (yes, four question marks) on a FAT USB key. But I believe this is a limitation of the filesystem, not the script.

#!/usr/bin/python

import urwid
from os import listdir
from os.path import isfile, join
from shutil import copyfile

directory = '/tmp'
destination = '/mnt/usbkey'

choices = [ file for file in listdir(directory) if isfile(join(directory,file)) ]

tocopy = [ ]

def menu(title, choices):
    body = [urwid.Text(title), urwid.Divider()]
    for c in choices:
        box     = urwid.CheckBox(c, False, False, toggle, c)
        body.append(urwid.AttrMap(box, None, focus_map='reversed'))

    ende = urwid.Button('-- COPY --')
    urwid.connect_signal(ende, 'click', item_chosen)
    body.append(urwid.AttrMap(ende, None, focus_map='reversed'))

    return urwid.ListBox(urwid.SimpleFocusListWalker(body))

def toggle(button, state, file):
    if state:
        tocopy.append(file)
    else:
        tocopy.remove(file)

def item_chosen(button):
    response = urwid.Text([u'Proceed with copy?\n'])
    done = urwid.Button(u'Proceed')
    fine = urwid.Button(u'Cancel')
    urwid.connect_signal(done, 'click', copy_files)
    urwid.connect_signal(fine, 'click', exit_program)
    main.original_widget = urwid.Filler(urwid.Pile([response,
        urwid.AttrMap(done, None, focus_map='reversed'),
        urwid.AttrMap(fine, None, focus_map='reversed') ]))

def exit_program(button):
    raise urwid.ExitMainLoop()

def copy_files(button):
    for file in tocopy:
        src = join(directory, file)
        dst = join(destination, file)
        copyfile(src, dst)
    raise urwid.ExitMainLoop()

main = urwid.Padding(menu(u'File to be copied to USB', choices), left=2, right=2)
top = urwid.Overlay(main, urwid.SolidFill(u'\N{MEDIUM SHADE}'),
    align='center', width=('relative', 60),
    valign='middle', height=('relative', 60),
    min_width=20, min_height=9)
urwid.MainLoop(top, palette=[('reversed', 'standout', '')]).run()


HTTP Status Codes - security considerations I am designing an authorization framework and now I am thinking about the error codes which I should return when someone is trying to access a resource and he doesn't have the required permissions. These are my thoughts so far:

case: The user is not authenticated, he is seen as "anonymous" -> Here I think 401 would be the right status code, so the user gets the opportunity to authenticate itself.
case The user is already authenticated. I would return 404 NOT FOUND. RFC2616 states that if we don't want to reveal exactly why the request has been refused, 404 is a good way to go.

I am also thinking to ad another case for the user: ADMIN. If ADMIN is unauthorized he should get customized responses, so he would know exactly what the problem is.
What do you think about this? Does it make sense? How could someone exploit this?

Do you think that it is better to use 404 for everything or would you differentiate between 403 and 404, and why?

Is there any good literature regarding this subject? (I have already searched and found nothing conclusive)

I think RFC 2616 is quite clear:

  10.4.4 403 Forbidden

  The server understood the request, but is refusing to fulfill it.
  Authorization will not help and the request SHOULD NOT be repeated.
  If the request method was not HEAD and the server wishes to make
  public why the request has not been fulfilled, it SHOULD describe the
  reason for the refusal in the entity.  If the server does not wish to
  make this information available to the client, the status code 404
  (Not Found) can be used instead.

So really it's up to you if you would like to add additional information (the "reason for the refusal") if the request was made by an administrator.

But really, isn't your administrator unauthorized to view the requested resource? I think that's the case, and if I'm right, the response should definitely be 401 Unauthorized.

From 10.4.2. 401 Unauthorized:

  [...] If request already included Authorization credentials, then the 401
  response indicates that authorization has been refused for those
  credentials. [...]


Does a lack of verified signatures for Windows Defender indicate malware? I ran "autoruns" from Windows Sysinternals on a Windows 10 machine, and noticed that the Windows Defender services were marked in red colour, and did not have verified signatures.  I checked these services on another machine and found that they were all verified as expected.

Does this mean the Windows Defender on my machine is malware?  If so, how can I remove it and reinstall a clean Windows Defender?  Running the thorough offline-scan did not help.

No, it is normal for legitimate applications to appear as "not verified" in autoruns.exe. In my experience, this is normal behaviour and I have seen other legit applications that didn't appear as digitally signed. I wouldn't worry too much about what autoruns tells me if I were you.

This is why malware analysis makes use of various tools, either for static or dynamic analysis. There needs to be a much more detailed "inspection" of the characteristics and behaviour of the application to reach a verdict.

Here is a screenshot from my machine, to put your mind at ease:

What you CAN do, is to create some sort of 'saved state', to compare your system with at a later time, and possibly detect how a malware gains persistence. Remember, if you eliminate a malware's persistence, then you've 'theoretically' eliminated the malware:

Run autoruns.exe on a "clean" system and let it finish. (If you suspect your system is already infected with malware, then this process won't help you).
Click on File -> Save, and then save the .arn file.
When at some point you suspect that you have been infected by some malware, then run autoruns.exe again and when it finishes, go to File -> Compare and load the .arn file from step 2. If you notice some dodgy Registry entry that you can be certain it is not legitimate, then you can safely delete it.

However, this doesn't mean that you'll always be able to see the auto-start registry entry (e.g. see persistence through RunOnceKey, rootkit driver infection, etc). Nevertheless, it might help sometimes.


Is TCP Sequence Bruteforcing dangerous nowadays? I was reading about TCP sequence prediction which is described as almost impossible on all updated Operating System nowadays.
The total amount of possible sequence numbers is 2^32-1 which, if we try to brute force it, will be guessed after an average of (2^32-1)/2 = 2 147 483 647.5 try.

So now, what is necessary to a good IP spoofing attack

SYN+ACK+at least one PSH packet to perform the attack. 20B + 20B + ~30B = 70B

It takes then approximatly (2^32-1)/2*70 ~= 150TB to perform an IP spoofing attack.

We've seen the biggest DDOS attack, with over 1TB/s few weeks ago (source). So if I understand, this camera botnet is able to perform IP spoofing attack in 150 seconds.

What is the future of TCP sequence Bruteforcing ? With the constant increase of bandwith and computer's power, will this become an important attack vector to deal with ? Should the TCP protocoles be updated to deal with 64 bits sequence ?

What is the future of TCP sequence Bruteforcing?

I'll argue that it is not as dark as it may seem at first.  Guessing a 32bit number is not feasible, even if you send a lot of packets with attempts.  As @armani said, using a DDoS size bandwidth is most likely to make the machine not respond rather than accept the spoofed packet.

Yet, there are other ways.  All of them are based on the fact that you can reduce the search space (32bit) to a more amenable amount.

Years ago Michal Zalewski performed a research where he made time series of the pseudo random number generators.  The time series allowed to guess the next number based on a couple of previous ones.  Knowing some packets allowed to make a much better guess against systems where the PRNG was somehow predictable.  And guess what, most systems have a rather predictable PRNG.
A year later Zalewski checked if the PRNGs did improve after he reported the issues.  And the improvement was not so great.
Even attempts to to protect from ISN guessing backfired in the past.  CVE 2016-5696 happened because an RFC (RFC 5961) did not define things properly and implementations (actually the one single implementation in the Linux TCP stack) became more vulnerable.  They became vulnerable because they provided sequence numbers through ACK challenge packets that could be used in determining the PRNG sequence (in techniques similar as point 1.).  Once the number of allowed ACK challenge packets was reached, you not only could try guessing as normal, but had several packets to base your PRNG analysis.

We (OS developers and security analysts) keep making mistakes with ISN.  And, although popular and updated systems are unlikely to be vulnerable (Linux is fixed those CVEs), not all systems are updated.  Moreover, as seen in Zalewski's research, router OSes do not fare much better on PRNG predictability.  And router OSes are often left not updated.

There is still future for sequence guessing, not necessarily plain brute-forcing.  But the guessing, still involves some brute-forcing.  You can guess a couple of ranges a PRNG can come up with, and from there you need to send several packets with different sequence numbers each based on the ranges (using all numbers in the guessed range in the best case).

It is becoming harder and harder to make viable spoofing attacks on TCP sequence numbers.  But is isn't impossible.

References

Strange Attractors and TCP/IP Sequence Number Analysis - Zalewski
Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later
TCP “off-path” Attack (CVE-2016-5696)
RFC 5961