How detrimental is a NULL pointer dereference vulnerability today?

These days null pointer dereferences can only directly be leveraged as denial-of-service conditions, as the zero page is always protected against being allocated. There are cases where the dereferenced pointer is not null, but does point to deallocated memory (e.g. UAF in a JIT), and these can generally be leveraged to gain LPE or RCE in certain cases - the latter mostly being applicable to JavaScript engine vulnerabilities.

That said, triggering a null deref can often have secondary effects outside the scope of DoS, e.g. producing a stack trace or core dump that leaks sensitive data in a way that an unprivileged user can access it.


Which is the most recommended way to expose a file to a computer in an external network in a secure way?

HTTPS with authentication
While HTTPS relies on the PKI infrastructure, making it potentially vulnerable to rogue CAs, it is perfectly adequate for "confidential but not highly sensitive" material. Using HTTP basic auth sends the password to the server, and when TLS is being used, it is additionally encrypted. This will provide you with a few guarantees which you will need when handling confidential information:

Is the entity requesting access allowed to access this material?
Can an authorized entity be sure the material being sent has not been tampered with on the wire?
Can an active/passive eavesdropper view the material as it is being sent to an authorized entity?

Any good form of authentication solves the first question, and TLS solves the second two. There is no need to use basic auth specifically (as it has its limitations, being rather simple and not ideal for storing sensitive user-created and potentially re-used passwords), so long as any simple authentication system is in place to ensure that only those who are supposed to download can do so.
Client certificates
Depending on how important the confidentiality of this material is, and partially on exactly how little knowledge "zero IT knowledge" is, you can also use encrypted client certificates. These are certificates generated either by you or by the client, and stored in the client's browser. It is not difficult for an end-user to set them up and use them, but it requires slightly more effort than the normal internet user is used to. It requires opening up the settings for your browser and importing the client certificate file, which will open a prompt for creating a new password to encrypt it. When they later access your site over HTTPS, their browser will ask them for the certificate password and, if it is correct, it will use the certificate to authenticate them to your website. This is by far the most secure browser-based authentication method, as the client authenticates itself to the server, and the server authenticates itself to the client.
Securing a TLS connection
If you do end up with using HTTPS, you should follow best security practices for TLS deployment:

Use a strong private key (2048 bits or larger RSA), signed by a reputable CA (e.g. LetsEncrypt).
Disable insecure cipher suites (such as those from SSLv2-3 and non-PFS modes).
Avoid using small or default moduli if using DHE, or just use ECDHE.
Pin the HTTPS state by using HSTS, ideally with HSTS preloading.
Use HPKP to pin the precise public key you use. This is safe as long as you use a backup key.
Use OSCP stapling to check for revoked certificates.
Make a tight CSP policy and other anti-XSS measures to reduce the risk of XSS attacks.
If practical and feasible, require users of the site use an up-to-date browser.
Test your site regularly with Qualys' SSL Test. Seriously. It is an amazing service.

While this is not all an absolute must, it does significantly improve the security of the whole situation closer to that of SSH, while still retaining accessibility for the technologically-handicapped. At an absolute minimum, the first four bullet points and the last bullet point should be followed.


Logging in users automatically on a website

Create a cryptographically secure random token and associate it with the user id in your DB
Perform an HMAC on the token
the cookie value will then be token+HMAC

This way an attacker would have to know your HMAC key in order to brute force the token and that is not possible.

For validating the cookie you first extract the HMAC, validate the authenticity of the token and then you can check your database and extract the user id that is associated to it. After a few failed HMAC validations you can block the user since not even one HMAC validation should fail and it means someone is trying to attack you.

It is important to keep the security of the cookie by:

Set HttpOnly flag to true - so cookie cannot be accessed from javascript
Set the Secure flag to true - so cookie will only be transmitted via https and cannot be sniffed over the network
Set a reasonable expiration time to the cookie so your user's don't stay logged on forever
Set the cookie domain to make sure it is not leaked to any subdomains where you do not intend it to go


Facebook 'Where You're Logged In' IP does not match actual IP

There are quite a few apps that interface with FB. In addition to flat out showing the wrong location for an IP, I suspect FB gets confused and maybe shows your location as the most frequently logged in location rather than most recent or currently active login. I have a calendar app that syncs my FB events to my google calendar on the hour. Logging out of FB, clearing my web cache, and logging back in doesn't fix the location issue.

After "ending all activity" on the FB Security and Login settings, which forced my calendar app and all the others (like Bumble) to disconnect, then logging back in, my location corrected. It also corrected to my actual location, rather than just my ISP's central location.

This is hardly a fix or an answer to the problem, but it's a way to get your location corrected if you're willing to give up the utility of FB interfacing apps.


Are my devices and information vulnerable in a public network? what are some solutions?

Get a VPN, such as Mullvad, to encrypt your connections to public networks.

is my private information (Banking info, private photos, etc) in danger?

If they don't use TLS (HTTPS), then yes. An attacker could view or modify any data.

Could someone spy on me through my webcam?

Not passively. They'd have to manage to get you to execute malicious software on your computer (either by getting you to download and run it, or by tampering with another downloading executable that you'll run), or you stream video from your webcam without using TLS.

I found that youtube was streaming to a SMART TV that was connected to the same network without me even allowing it, it just automatically did it.

That has nothing to do with public Wi-Fi. Check the smart TV's manual, maybe?

If I buy a router and connect it to this public network, would my devices be safe then?

Not if the router has to connect to the public network over Wi-Fi.


There are some architectures which use a "growing up" stack. Generally speaking, this makes porting of operating systems a bit harder; it does not seem to be that much of a gain security-wise. The convention of making stacks grow down comes from the era before the advent of MMU (without MMU, RAM is a block; the stack grows down from the end of the block, the data elements are allocated upwards, and memory is exhausted when heap and stack meet).

In the case of buffer overflows, it so happens, empirically, that most occur "on high addresses": the buffer has size 1000 but the buggy code tries to write into the 1001th, 1002nd... slots. This is related to how most programmer implement a loop: when they want to loop over the 1000 elements of an array, they loop up, with index from 0 to 999, instead of looping from 999 down to 0. For the machine, both are equivalent (in fact, in some old 8-bit computers, looping down was slightly faster); but programmers are humans with human habits, and this includes counting up instead of down, when given the choice.

This matters with stack direction because with a "downward" stack, the juicy slots that the attacker wants to rewrite (in particular the return address) are in range of "high" overflows, which are more common than "low" overflows. However, "low" overflows (also called "underruns": code tries to access slots -1, -2...) are just infrequent, not unheard of. Reversing the stack direction just swaps the roles: now, low overflow become critical.

Also, as @Polynomial explains, low overflows can also be interesting. The function return address is just one among many slots that the attacker would like to overwrite.

In my opinion, the main problem with a buffer overflow is that it occurred: the code does nonsensical things, and is allowed to proceed unabated. It is like a rhinoceros evaded from a zoo and rampaging through the town centre; reversing the stack is like: "let's move the whole town, so that the rhinoceros is more likely to run toward countryside, where it will make less damage". It is hardly a "reasonable" safety mechanism. It would be a much better idea to concentrate on not letting the rhinoceros go loose.


Can users make use of a password manager when banks tell them never to write passwords down?

I am not a laywer, but a properly constructed password manager stores passwords approximately as securely as any modern banking system.

I can't speak to the legality of using a password manager, but I can say that on a philosophical level, anywhere a personally provided password is acceptable as identification, a (properly constructed) password manager password is acceptable.

(Edit: Adding a password to a properly constructed password manager is not equivalent to simply writing them down.)


It looks like you're being targeted by a determined attacker, so you should immediately start by implementing rate-limiting measures. I highly recommend using fail2ban or similar solutions.

Look through your database and logs to find the average number of sign-up attempts from the same IP address, then double that and use it as the limit in fail2ban's configurations.

As for identifying the source of the requests, I'm not aware of any method that can reliably identify whence the request is coming. The attacker is always able to fake any request headers coming from the client (such as HTTP_X_REQUESTED_WITH or HTTP_REFERER), so don't rely on that.


By FIPS, I assume you mean FIPS 140.

FIPS 140 defines four levels of security.

Level 1 is essentially about implementing cryptography and authentication correctly, as in passing some basic functional tests. You must use approved algorithms for cryptography and for random number generation. You can certify a software product at level 1.
Levels 2 and above involve gradually stronger security mechanisms. The hardware must be included in the certification.

Do not confuse FIPS 140-2 (“fips one-forty dash two”), where 2 is the version number of the standard, with FIPS 140-2 level 1 (“fips one-forty dash two level 1”), where 1 is the level of security.

You'll be wanting FIPS 140 level 1 then.

Regarding your question 3: FIPS 140 requires a validated implementation, and you can only validate an implementation of an approved algorithm. AES (with a suitable mode) is an approved algorithm, it's up to you to have the implentation validated. Note that in order for your software to be FIPS compliant, you don't just have to follow the standard and say it is compliant: you need to go through the validation program.

Using a validated crypto library won't help you much, except perhaps for the random number generator. You'll have to select approved algorithms, and pass the comformance tests anyway.

FIPS 140 level 1 isn't much more than what you'd do in a serious product regardless of certification (use reasonable algorithms, run a few tests). It does add two requirements for which a FIPS-compliant library may help a little:

Each algorithm must be tested before use, after each power up. Testing means running one test vector and verifying the result. Your software must refuse to use the algorithm if the corresponding test has failed.
Any key that is stored in your module must be erased after use. There is no strong security validation here, but you may run into difficulties if you're using a language with a garbage collectors that can move objects around.

If you use a FIPS-compliant library, it's possible that your client will be satisfied with that and won't require you to validate your software. You have to take it up with your client.


Stack Overflows - Defeating Canaries, ASLR, DEP, NX

Canary
Stack canaries work by modifying every function's prologue and epilogue regions to place and check a value on the stack respectively. As such, if a stack buffer is overwritten during a memory copy operation, the error is noticed before execution returns from the copy function. When this happens, an exception is raised, which is passed back up the exception handler hierarchy until it finally hits the OS's default exception handler. If you can overwrite an existing exception handler structure in the stack, you can make it point to your own code. This is a Structured Exception Handling (SEH) exploit, and it allows you to completely skip the canary check.

DEP / NX
DEP and NX essentially mark important structures in memory as non-executable, and force hardware-level exceptions if you try to execute those memory regions. This makes normal stack buffer overflows where you set eip to esp+offset and immediately run your shellcode impossible, because the stack is non-executable. Bypassing DEP and NX requires a cool trick called Return-Oriented Programming.

ROP essentially involves finding existing snippets of code from the program (called gadgets) and jumping to them, such that you produce a desired outcome. Since the code is part of legitimate executable memory, DEP and NX don't matter. These gadgets are chained together via the stack, which contains your exploit payload. Each entry in the stack corresponds to the address of the next ROP gadget. Each gadget is in the form of instr1; instr2; instr3; ... instrN; ret, so that the ret will jump to the next address on the stack after executing the instructions, thus chaining the gadgets together. Often additional values have to be placed on the stack in order to successfully complete a chain, due to instructions that would otherwise get in the way.

The trick is to chain these ROPs together in order to call a memory protection function such as VirtualProtect, which is then used to make the stack executable, so your shellcode can run, via an jmp esp or equivalent gadget. Tools like mona.py can be used to generate these ROP gadget chains, or find ROP gadgets in general.

ASLR
There are a few ways to bypass ASLR:

Direct RET overwrite - Often processes with ASLR will still load non-ASLR modules, allowing you to just run your shellcode via a jmp esp.
Partial EIP overwrite - Only overwrite part of EIP, or use a reliable information disclosure in the stack to find what the real EIP should be, then use it to calculate your target. We still need a non-ASLR module for this though.
NOP spray - Create a big block of NOPs to increase chance of jump landing on legit memory. Difficult, but possible even when all modules are ASLR-enabled. Won't work if DEP is switched on though.
Bruteforce - If you can try an exploit with a vulnerability that doesn't make the program crash, you can bruteforce 256 different target addresses until it works.

Recommended reading:

Corelan - Chaining DEP with ROP
Corelan - Bypassing Stack Cookies, SafeSeh, SEHOP, HW DEP and ASLR
ASLR/DEP bypass whitepaper (PDF)


Any chance it's this: https://www.cisecurity.org/services/albert/ ?

It says it's a Suricata based IDS (not clear to me what they add to plain Suricata, maybe this is a subscription to threat signature updates?).


On a single user laptop does it make sense to have a separte password for root and the user?

It's all about your own personal risk tolerance and your threat model. In short, you are worried about someone who is physically in possession of your laptop and has guessed your user password, and you want to keep them from having full admin rights. I'm having a hard time coming up with a scenario where that may actually happen, so I can't help but think that you are overthinking this. Moreover, for most personal computers, the user account is typically more critical than admin access;
https://xkcd.com/1200/
Then again, remembering two passwords isn't much harder than memorizing one, so go for it if you want. Just make sure you have a way to copy your data off the machine without needing admin credentials - you'll want to do that if you ever forget your admin credentials and need to reinstall.
Still, I might suggest an alternate solution:
Use a strong password and don't tell it to anyone


I cannot see anything in the SPF standard which would imply that a SPF record covers all subdomains too. Given that subdomains are sometimes managed by different parties (especially in larger organisations like universities) it would also not make much sense to implicitly cover the subdomains. And the standard says in section 4.4:

  4.4.  Record LookupIn accordance with how the records are published (see Section 3
     above), a DNS query needs to be made for the <domain> name, querying
     for type TXT only.

"<domain> name" is here the domain from the email, not an upper domain.


Can malware provide hidden remote access to a user's desktop?

Yes it's possible.

An obvious example would be a Remote Access Trojan (RAT). Once your computer is infected they can do essentially whatever they're set up to do. This includes monitoring your screen, logging keystrokes, and accessing webcams.

My personal experience with this was being infected with the Blackshades RAT a few years ago. I was monitored for about two days and on the final day the kid on the other end clearly got impatient with me and demanded to know multiple credentials via a chatbox he put in the middle of my screen.

My solution at the time was to remove my usb wireless card to prevent him from sending any further commands, format the computer, and reinstall from scratch.


A substitution cipher (A -> K, B -> C...) should yield rather quickly to frequency analysis, if the plaintext is a natural language text of sufficient length. It helps if they can guess a partial plaintext (the message starts with "Hello", or ends with "glory to arstotzka" oslt.). Leaving the spaces between words intact would be an instant giveaway for shorter words.

You mentioned programmers, so I wonder if you can expect your solvers to create a program to e.g. brute-force a limited keyspace. They'd need to know or find out the algorithm, though. Also, natural language text ciphered with a stream cipher (xor) using a repeating keystream is rather easily solvable since the binary representations of spaces and letters give away parts of the plaintext when looking at ciphertext bytes enciphered with the same keystream byte. Though that may require some background knowledge to get the right insight.

All in all, a good puzzle would depend on accurately guessing the level of the solvers. One possibility would be to build the problem in parts, starting with easier systems and progressing to harder ones. Any book/source on historical ciphers would likely have many examples on what to use.


There are two potential security issues with supporting the LOCAL version of LOAD DATA statements:

The transfer of the file from the client host to the server host is initiated by the MySQL server. In theory, a patched server could be built that would tell the client program to transfer a file of the server's choosing rather than the file named by the client in the LOAD DATA statement. Such a server could access any file on the client host to which the client user has read access.
In a Web environment where the clients are connecting from a Web server, a user could use LOAD DATA LOCAL to read any files that the Web server process has read access to (assuming that a user could run any command against the SQL server). In this environment, the client with respect to the MySQL server actually is the Web server, not the remote program being run by the user who connects to the Web server.

All the sources I found MySQL, Symantec and Green SQL recommend to disable this function. However if you are using in a controlled environment (restricted access only to trusted users) you might accept the risk.


How can I demonstrate that 3 independent root CAs validated my domain?

There is no standard way to do what you envision and I'm not aware of any proposals of relevance. The currently established PKI structure allows only for a single certificate chain (i.e. a single issuer for a certificate) and the TLS protocol like used allows only for a single leaf certificate. In theory one might create a certificate with multiple issuers using certificate extensions and in theory one could extend the validation process in TLS to check for multiple issuers. But again I'm not aware of any serious proposals in this area.
Serving different certificates via multiple HTTPS requests needs also some kind of extensions or hacks, because the server needs to know which of the certificates it needs to send. With new TLS extensions the client could ask for a specific certificate. Without the client might re-use existing extensions like SNI for a different purpose, i.e. give slightly different target host names. Or one could provide different IP addresses in the DNS and each IP address servers a different certificate. Or one could randomly rotate certificates. In all these cases the client has to be aware that it should try to get multiple certificates and how much certificates it should get and how to combine the information. This means some knowledge is needed about the server which is either coded into each certificate (i.e. certificate extension) or which the client got from the external resource in a secure way.
Because there is no standard or even proposed standard to do this you either need to invent your own or try to get the best from the current standards. Since hacking of a root CA is your main concern you might be already protected enough with the existing standard HPKP, i.e. certificate pinning on first use. This way no compromised CA can create a usable certificate in your name which gets accepted by browsers which visited you already, because the attacker would need your private key to misuse the certificate. And if HPKP is not enough you could apply for your public key to be included in the browser as it gets shipped. And this public key pinning is not restricted to a specific CA but only to your key pair, which means the key and thus the HPKP information stay the same if you use the same key in another certificate signed by a different CA. Thus you can easily change CA if one gets distrusted by the browser. Not all browsers currently support HPKP but it gets better. So this is probably the best you could get without trying to establish yet another standard or create a little used browser extension. If HPKP is not an option for you the you might add the reasons for this to your question.


Cryptographic metadata is information needed to encrypt/decrypt the data itself.

For example, when using AES-CTR mode, you need a nonce and counter. This information is not sensitive and can be stored alongside the file, in this case as extra information in the filesystem.

The link you mention has a whole section on cryptographic metadata. They also store:

encrypted master key
data-encryption-key (per file or per-directory)

So just like metadata is information about the data itself (filename, timestamps, permissions, etc...) cryptographic metadata is anything needed to perform cryptographic operations on the data.

As for the "header" part, eCryptfs stores metadata in the same logical file, before the actual data. Eg: if I encrypt the following file:

| this is my plaintext data |

It will be stored as follows on eCryptfs:

| metadata | cipher text of the data |

The advantage of such a method is that the encryption metadata lives in the same place as the file, so moving the raw file (underlying eCryptfs) carries its encryption information.

You can find more information about the implementation details in this paper.


The difficulty of brute-forcing your ciphertext depends on what key size you used when encrypting: Blowfish has an adjustable key size, ranging from 32 bits to 448 bits; this size is independent of the complexity of your password.  At the 32-bit end of things, your ciphertext could be decrypted in a matter of minutes, while at 128 bits or larger, it would take longer than the remaining lifetime of the universe.

What your quote means is that simplified versions of Blowfish have attacks that are faster than brute force.  From a practical standpoint of attacking it, it means that for longer key sizes, an attacker is better off researching attacks than trying to guess the key, because there's a good chance they'll be able to find a practical attack.


Why does Mozilla Firefox encrypt saved passwords?

It's probably to simplify the implementation. Rather than having two cases where the key store could be encrypted or not depending on whether Master Password is set, the code always encrypts.

This reduces the likelihood that a code path that forgets to encrypt when Master Password is enabled goes unnoticed.


Can you whitelist a single CA for a domain?

You can use a Certification Authority Authorization (CAA) Record on your DNS zone.
It specifies the CAs you want to issue your certificates from. It can be more than one. And you can even have a special record with a mail address to report violations.
For example, take a look at those records:
example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issuewild "comodoca.com"
example.com.  CAA 0 iodef "mailto:example@example.com"

In this example, LetsEncrypt can issue certificates for example.com, but not wildcard certificates. Only Comodo can issue wildcard certificates. And if someone else issues certificates for example.com, an email should be sent to example@example.com.
So if someone tries to issue a certificate for example.com at VeriSign, VeriSign would check the CAA record, see they aren't authorized to, and inform example@example.com. And Certificate Transparency requires that CAs log all certificates they issue, so any third party can check the certificates on the log and the corresponding CAA Record on the domain to see if any CA issued a certificate when they should have not.


Is it safe to use a weak password as long as I have two-factor authentication?

Specifically for Google, if you use two-factor authentication it is safe to "weaken" your password "from a 16-character password with a search space on the order of 1030 to an 8-character password with a search space on the order of 1014" as long as you use a good 8-character password (i.e. completely random and not re-used across sites).

The strength of two-factor authentication lies in the assumption that the two factors require different kinds of attack and it is unlikely that a single attacker would perform both kinds of attacks on a single target. To answer your question we need to analyze what attacks are possible on weaker passwords compared to stronger passwords and how likely it is that someone who is able to attack weaker passwords but not longer passwords will attack the second authentication factor.

Now the security delta between "a 16-character password with a search space on the order of 1030" and "an 8-character password with a search space on the order of 1014" isn't as large as you may think - there aren't that many attacks that the weaker password is susceptible to but the stronger one isn't. Re-using passwords is dangerous regardless of the password length. The same is true for MITM, key loggers and most other common attacks on passwords.

The kind of attacks in which the password length is meaningful are dictionary attacks - i.e. attacks in which the attacker does an exhaustive search for your password in a dictionary. Trying all possible passwords in the login screen is obviously not feasible for a search space of 1014, but if an attacker obtains a hash of your password then it may be feasible to check this hash for a search space of 1014 but not for a search space of 1030.

Here is where the fact that you've specified Google in your question is important. Google are serious about password security and do what it takes to keep your hashed passwords secure. This includes protecting the servers on which the hashed passwords reside and using salt, pepper and key stretching to thwart a hacker who has somehow managed to get the hashed passwords.

If an attacker has succeeded in circumventing all the above, i.e. is able to obtain Google's database of salts and hashed passwords and is able to obtain the secret pepper and is able to do an exhaustive search with key stretching on a search space of 1014, then unless you're the director of the CIA that attacker won't be wasting any time on hacking your phone to bypass the second authentication factor - they will be too busy hacking the hundreds of millions of Gmail accounts that don't use two-factor authentication. Such a hacker isn't someone targeting you specifically - it's someone targeting the whole world.

If your data is so valuable that such a powerful hacker would target you specifically then you really shouldn't be putting your data in Gmail in the first place. For that matter you shouldn't be putting it on any computer that is connected to the Internet.


Why does my debit card have a stripe AND a chip?

Details depend on bank, card type and country, so they vary quite a lot, but the generic model is the following:

The magnetic stripe contains, mostly, a computer-readable copy of the information embossed on the card: account number, holder name, expiration date.
The chip contains a secret key which is used to "sign" (not necessarily a true signature; often a MAC) transactions.
The chip knows the PIN code and refuses to work until the PIN code has been presented; it also locks itself if too many wrong PIN codes are presented.

When a payment terminal uses the magnetic strip, it must talk to the bank, establish a secure tunnel with the bank, send the PIN code entered by the user, and verify that the owner's account has enough money on it.

On the other hand, when a payment terminal uses the chip, the PIN code is sent to the chip only, and there is little need to talk to the bank at all. The whole transaction can be conducted offline. Of course, for big amounts, it is still a good idea to talk to the bank to know whether that much money exists on the buyer's account, but small transactions can be done efficiently with no network at all.

Thus, the magnetic stripe and the chip are used in two different ways, and having both does not mean that the security is lowered to the security of the weaker of the two. From the bank point of view, chips are better, because they are more efficient (no need to handle a network call) and harder to clone (statistics show a fraud rate divided by about 10). This is often translated into financial advantages granted to merchants who switch to chip-aware terminals.

There can be variants in all of the above. For instance, some card include in the magnetic stripe an encrypted version of the PIN code -- but it won't be verified in the payment terminal. Instead, the terminal will have to talk to a regional bunkerized server who knows the decryption key and can do the verification. For some other card types, it is pretty clear that the magnetic stripe does not know anything about the PIN code, e.g. the chip-less American Express cards (from a few years ago) where you could change your PIN code by phoning your bank.

In any case, all the security features of a debit or credit card are not meant to protect you. They protect the bank. From the point of view of the bank, you are the enemy (regardless of what they claim in their ads).


Is acquiring the csrftoken alone sufficient for performing any security exploits?

If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete their account (if that doesn't require re-authenticating). Change their email address (if it doesn't require re-authenticating). Upload your own content or access key. Fake-redirect them to the login page, present a clone of the login screen, and try to steal their credentials. Send the exploit payload to other users. Mine BitCoin with their browsers' JS engine (OK, that one is pretty pointless).

Stealing cookies is kiddie-mode XSS. It's easy to do, but also easy to defend against, rarely needed, and sometimes pointless. To technically answer your question, obviously if you have the CSRF token (which is going to be either in a script readable cookie or just in the page's DOM, which you can also read) then you can launch CSRF attacks on the user... but you don't need to because you can make the user's browser do anything that CSRF could do, and much, much more, from script running on the same site.


It doesn't matter how many mobile phones you have, each attempt still has 1 in 10000 chance of succeeding given a 4-digit PIN. What's important is how many attempts you have, which might not be tied only to a specific phone number but also to where the request ia coming from. This is one way to mitigate such attacks. Another is increasing the complexity of the OTP code, which is strongly encouraged in this case because 4 digits is definitely not secure enough if not paired with another for of authentication (username/password). Ideally introduce letters as well.


How is this site grabbing my mobile number?

Extended HTTP headers are propagated by your mobile operator, at their discretion, as described in Detect an MSISDN (mobile number) with the browser.

They won't work when you are on Wi-Fi, or if you are browsing on a secure HTTPS connection. But otherwise, your mobile operator is free to add or not add any of the HTTP x-headers, based on the browser you are using, page you are visiting, your contract (or lack of) with that operator, and any other info they may find relevant. Often, the operators only pass these headers for their own 'mobile portal'.

None of these headers should be trusted by the backend, they all can be easily spoofed.

A long list of such headers, caught in the wild, may be found here: https://mobiforge.com/design-development/useful-x-headers.

You can use a simple service at http://www.mulliner.org/pc.cgi that shows you all information that external web sites receive from your phone.


openssl blowfish key limited to 256 bits?

For OpenSSL's command-line program (openssl enc), the algorithm chosen also picks the key size (which is why they have separate options for aes-128, aes-192 and aes-256). They just don't have this option for Blowfish.

  The enc program only supports a fixed number of algorithms with certain parameters. So if, for example, you want to use RC2 with a 76 bit key or RC4 with an 84 bit key you can't use this program.

openssl enc -bf always uses a 128 bit key:

  Blowfish and RC5 algorithms use a 128 bit key.

The documentation for the Blowfish functions says you can use a variable-length key, so presumably if you wrote your own program compiled against OpenSSL, you could use whatever key size you want:

  BF_set_key() sets up the BF_KEY key using the len bytes long key at data.

If you can choose your algorithm, and you want a longer key for whatever reason, OpenSSL will do AES with up to 256-bit keys: (openssl enc -aes-256).

Given the above, you'd expect OpenSSL to complain when you go over 32 character (32 * 4 = 128), but it seems to silently ignore any data after the first 32 characters:

  blong@ubuntu:~$ openssl enc -bf -iv 0 -P -K 000000000000000000000000000000012345
  salt=0700000000000000
  key=00000000000000000000000000000001
  iv =0000000000000000

I submitted a bug report, because it looks like they're trying to catch this case, but the error is for > 128 characters instead of > 128 bits.


Is this a secure way to handle a JSONP response?

If all you are doing is extracting JSON server side, then what you are doing is "safe so far".

Remember, security is all about the context that the data is then used. After all, data is just 1s and 0s. It is when you output it to HTML you should make sure it is safe and cannot contain scripts, or when you put it into a database that you make sure it is passed as data rather than part of the query.


Security implications of adding all domains to CORS (i.e. Access-Control-Allow-Origin: *)

Access-Control-Allow-Origin has a different meaning than simply preventing CSRF: It prevents that the requesting script can get the result of the request.

The same applies to Access-Control-Allow-Credentials. This header allows that the script get the response of a request with credentials. Note that you can't use the wildcard * for Access-Control-Allow-Origin when sending Access-Control-Allow-Credentials: true. but you could just use the value of the Origin request header.

The implication is: What could a script with the contents of your site do?

If the user is logged in, a script can get all the sites that the user can see, parse it and send the (maybe confidential) data back to it's origin.
If you include some kind of anti-CSRF-token in forms/links, they could get the value of the token and do a request with that valid token.
It can act on the page on behalf of the user.

For XSS it depends what you mean with XSS. If you mean with XSS that an other script acts on bealf of a user, then you already allowed that.

So while adding to a remote site only reveals a few informations to the origin site (like the time to load it), the information leak (esp. for users that are logged in) can be much higher.

As a side note: Use the Origin header if present to block requests.


Should user be allowed to save password in browser?

You cannot prevent the user from writing down his password on a stick-up note, and "hide" it under the keyboard. You cannot prevent the user from giving his password to his wife, friends, and colleagues. You cannot prevent the user from choosing as password the ID tattooed in the ear of his dog (there was even a commercial from a big French bank which promoted exactly that). For that matter, you cannot prevent users from typing their password on an Internet Coffee shop machine, which is already a bad idea, due to the threat of key loggers.

So I tend to say that password security is the responsibility of the user, and if he is intent on doing something stupid, you cannot truly prevent it.

Note that "auto-complete" is something a bit different, because it is about a Web browser filling data automatically regardless of the target page; normally, the "saved password" feature is tied in the browser to a specific page (or site), so it does not exhibit the privacy issues that auto-completed non-password field elements have (and which your auditing company rightly points out). Password saving is supposed to be handled with sufficient care by the browser itself.

Nevertheless, there seems to be some ways to prevent password storage from the page itself, or at least people who share your concern, possibly for administrative reasons which may or may not be rationally substantiated; see, for instance, this question on StackOverflow.


Email sent to people with my name in the from section, but not my email address

The actual attack vector is hard to guess at because there are so many options, but some possibilities are:

A virus could have accessed your contact history or address book.
A packet sniffer watched other emails go by if they were sent over a non-secure connection.
Someone made some lucky guesses based on public information such as social media connections, work associations, common interests, etc.
Any of the above could have happened to the other email accounts which had sent/received messages to/from you.  If the association is found on either end, it would still work.

Now that it happened, you may also be wondering what to do about it.  Here is a good answer I found on just that question, but the news isn't great.


Do we require to eliminate share drive access to PCI users?

It doesn't require you to eliminate them, but if PCI-scoped user systems with PAN data on them can freely save files to them, then the file servers are in PCI scope and have to be subjected to full DSS compliance.

...and if your newly PCI-scoped file servers are also accessible to non-PCI-scoped user systems, then those non-PCI-scoped user systems are in PCI scope and have to be subjected to full DSS compliance.

...and so on, and so forth.


What data you keep and how you keep it is usually down to individual preference and the requirements of the organisation you work for. As such I'm not going to directly answer your question with a tool recommendation, but rather give you some tips that are agnostic to the testing approach and OS you use.

Most critically, do not overthink your process for organising data! A bloated approach will lead to you becoming lazy over time. You may not think so now, but after a year of continuous testing and reporting you'll get slack with it. Keep it simple and easy so that it doesn't feel like a burden.
Make a separate directory for each test. Give it a sensible name. We have assessment numbers, so I use those so that I can easily identify it. Keep all of these test directories under a single parent directory named something like "testdata" - sounds simple but I've seen people putting test data into three separate locations and mixing up results this way.
Keep a log of what you do and when you do it. I have a simple script for this - it just appends a line to a log file in the current directory, with a timestamp, so I can just type ptlog started nmap on box 10.20.30.40 and it'll write [2017-09-04 14:07] started nmap on box 10.20.30.40 to the file. You don't need to use the same method, it's just important to keep timestamped logs.
Don't just log technical stuff. Log the outcomes of conversations you had with the client, particularly if they involve problems with availability or changes to scope. Make sure you say who you spoke to and when. While it's rare that someone will try to dick you over, good logs are fantastic insurance when shit hits the fan.
If you're using Burp, Zaproxy, Maltego, Netsparker, or a similar tool that uses projects or state files, save them early so you don't data if/when the tool crashes. Burp used to be an absolute nightmare for this.
When using tools like nmap, dirb, sslscan, ssl-cipher-suite-enum, etc. that default to just writing content out to stdout, make sure you're either using the appropriate output settings to log the results (e.g. -oN, -oX in nmap) or are piping it out to a file. Name the file after the target. If you realise you did something wrong but still sent some packets, or needed to cancel the scan, do not overwrite the original log file when you re-run the command - rename the old log first.
If you're copying files from a client system, place them into their own folder and don't mix them up with another system's files. This avoids a lot of confusion later down the line when you're trying to work out why the production environment has a database box that is apparently configured to back up to the UAT or development instance, only to realise later that you mixed up the config files. It also makes you look like an idiot. (I can neither confirm nor deny that this is based on a personal experience)
BACK YOUR DATA UP. I cannot stress this enough. If you're doing any kind of long engagement with a client and you lose your entire set of testing data 5 weeks into a 6 week test, you're in serious shit. Chances are you'll need to re-assess a lot of things, which may require change requests that simply cannot be completed in time for the end of the assessment window. That leaves your organisation in a situation where you cannot deliver the assessment which you are contractually obliged to, and it's entirely your fault from a legal standpoint. Your company will probably give you a backup solution and I suggest that you use it frequently.


Intrusion Detection System (IDS / IPS) useful for Linux home users?

Yes, configured and used correctly, an IDS or IPS will increase security for any user.

But also antivirus will increase security for users on any operating system, so your assumption is incorrect there.

The amount it will increase security depends on a huge number of factors, though, so we can't tell you how much it will help you. It will help company networks more, because they have a broader risk profile than you will at home, but you will need to run your own risk assessment.


Is there any use in reporting backscatter and, if so, where can I do it?

First a few thoughts about backscatter: you should differentiate between real DSN (delivery status notifications) and backscatter (where there was no original email from you to reply to). You should not fight against DSN since it's integral part of the email system, and - despite what some people say - useful most of the time.

Stopping fake bounces to emails you've never sent is not hard, and probably BATV is the most logical way to go. You must be aware of the restrictions though: you have to use your specific BATV mail relay for both inbound and outbound mail, since it is imperative that all your outbound get its keyed sender and all your inbound gets verified. If you neglect this you may get your email bounced by Sender Address Verifying (SAV) servers, or the replies to you may get bounced back by your inbound server.

Using DKIM and SPF may also help to prevent the bounces with less efficiency since it require the recipient to check the signature, but in case you're using a central relay you may implement that easily as well (and for a bonus you make it harder your mail to get spoofed).

As for reporting bounces I see no real benefit in that, even less than reporting spam individually. Most bounces contain little to no original headers, so you cannot report on the original spammer, and these mailservers have often not so professional admins with default configurations and in my experience litte room to change. The time you'd spend on reporting would be mostly wasted.


Can the root user be removed from a *nix system to prevent privilege-escalation?

Even if you wanted to, I don't think you can remove the root user. From Wikipedia:

  On Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser, regardless of the name of that account.

and a lot of the kernel code that vulnerabilities exploit does stuff like

// become root
uid = 0;
...
if (uid == 0)
    // do some protected thing

So the superuser isn't really a "user account", it's literally the number 0. If you can find an exploit to set uid = 0 then bam! your process has sudo, regardless of whether or not there's a user account named "root".

EDIT ADDRESSING COMMENTS: several flavours of linux prepend a "!" to the root's password in the /etc/shadow password file (a character that can not be generated with the password hashing function) which makes it impossible to actually log in as root. That stops some types of root-priviledge escalation attacks based on cracking the root password, but the more dangerous kind of privilege-escalations are based on buffer-overflow attacks that over-write a process' uid variable to be uid=0, at which point that process is root.


Is it safe to have a mysql server on a home computer?

I do hope your Windows system is not accessible from the Internet, as in, there is no firewall between your Windows system and the open Internet.

You can configure either or both mysql and Windows Firewall to only allow connections from certain networks or computers. It depends a lot on what other systems use this mysql server, if there are any ... if the only system using the mysql database is your home computer it is installed on, then you can limit connections to loopback (localhost, 127.0.0.1) and you should be so much safer.


How does SSH use both RSA and Diffie-Hellman?

The host key is used to sign the Diffie-Hellman parameters. It is used during the key exchange; RSA is a signature algorithm as well as an encryption algorithm. From what I can tell, the client key (in authorized_keys) is not used in key exchange at all; it's only used after key exchange to sign a particular message and prove the client has the private key (one side of DH parameters being signed is enough to prevent a MITM, because the attacker can't impersonate both client and server; it's easier to make the server always have to have a keypair than make the client always have to have a keypair).
The way SSH uses DH is as an ephemeral algorithm: DH parameters are generated for individual sessions, and are destroyed as soon as they're no longer needed. The only thing the long-lasting keypair is used for is authentication. This gives forward secrecy: stealing the private key doesn't let you decrypt old sessions.

If RSA was used to encrypt the session key, then someone who recorded that session, buys the SSH server years later after it's been decommissioned, and obtains the private key off its hard drive can use that to decrypt the session key, and use that to read the entire communication. If RSA is used to sign DH parameters, then the only way to exploit a stolen private key is in a man-in-the-middle attack, and that can be foiled by the server operator changing the key and telling all his users about the changed keys. With ephemeral key exchange, nothing needed to decrypt a recorded session is stored any longer than it has to be.

This is also a configuration being used increasingly often for TLS sessions (there, where certificates have expiration dates, a private key doesn't even strictly have to be kept secret after its expiration because it shouldn't be possible to use it in a man-in-the-middle attack; it is, because users will ignore expired certificates, but you can see why ephemeral encryption is nice).


Why are security properties non-compositional?

Secure+secure != secure

What "non-compositional" means by definition is that if you have two components/thingies/processes/whatever that each on their own are secure (i.e. satisfy some security property) then, in general, you can not assume that the combination of these two will satisfy that security property; having both these together can make them both insecure.

This general principle applies to many domains of security from app development to theoretical cryptography; many practical exploitable vulnerabilities occur from an unexpected interaction of two parts that each, when viewed in isolation, would be perfectly secure.


You are certainly adding risk though whether that is enough to worry about may be difficult to calculate.

Is it against the terms and conditions of use of the ISP? You both could get cut off. Low to medium risk, relatively low impact.
Will someone in their household do something illegal that you might end up on the hook for - because you cannot prove you were not complicit. Illegal file sharing, child pornography or something else. Medium risk, terrible impact.
You will be relying on their router being secure - it may well be now but will it always be? Medium risk but potentially high impact.
You will be using a wireless connection between houses, will anyone else create a rogue Wi-Fi hotspot that will intercept your connection? An unlikely issue generally but quite high impact.

I would estimate that the risks of all of that are far lower than public Wi-Fi but they are certainly nowhere near zero.

UPDATE: You could help mitigate some of these risks fairly readily. You could have a written and signed agreement for example. You could make sure your neighbours router created a VLAN and you could give them your own Wi-Fi access point so that your traffic was segmented from theirs.


Possible, yes. Though far more likely, as others have noted, is a misconfiguration, causing requests to not be sent to the interpreter and revealing source code.

A common mitigation to this is moving sensitive files, like a configuration file containing database credentials, to outside of document root. MVC frameworks encourage this by using a front controller. That is, the only source code exposed to document root is a tiny index.php file. The rest of the source code is read from outside of document root. This minimizes the impact of the interpreter being misconfigured.


what can a hacker do with stolen cookies?

Session cookies are pieces of information that allow you to maintain state across multiple HTTP requests (which is by design a stateless protocol).

In other words, what allows you to login to gmail, reboot your computer and go back to gmail without having to login is the presence of a session cookie that, on the server side, matches an active session.

So, hackers who can steal your session cookies will be able to impersonate you (within certain limitations) on the websites you are logged in to. For example Gmail, Twitter, Facebook, eBay, etc.

Can they get your passwords? Not directly, although depending on the implementation of the applications they got access to, they may be able to find hints, fragments or the actual password set to that account.


How would replacing Bearer tokens with HMAC work in OAuth 2.0, and how would the client/server validate?

Whatever the flow, the MAC token would be generated the same: a symmetric secret key and an id is sent to the client once. This secret is never sent over the wire again.

The client doesn't validate the token*, the client uses it as it would use a bearer token, except that the secret is not sent over the wire and thus can't be leaked:

  +--------------+                                        +--------------+
  |              |>------Request with authenticator------>|              |
  |              |                                        |   Resource   |
  |    Client    |                                        |    server    |
  |              |<--------Requested resource------------<|              |
  |              |                                        +--------------+
  +--------------+                                                ^
         ^                                                        |
         |                                                        |
         |                                                        |
         |                                                        |
         |                                                 MAC algorithm
   MAC algorithm                                           over key+params
   over key+params

The client constructs the authenticator calculating a MAC using the secret key and some parameters (that includes the token ID, a nonce, a timestamp and some other data), and attaches that to the request.

The resource server (or a third server the RS uses to validate tokens) knows this secret key, so it performs the same calculations as the client did using the same params. If everything matches it proceeds with the request.

The server is also tasked with preventing replay attacks by checking the timestamp and preventing nonce-reuse.

This protects agains many scenarios in which the token could be leaked: TLS misconfiguration/bug, attacker controlled endpoints finding their way into the client's database, etc.

Regarding your 3rd question, yes and no. The OAuth2 MAC spec draft defines a few claims for JWT to encode the information required for the emission and use of MAC tokens using JWT, but OpenID Connect is still using bearer tokens.

The main concern with bearer tokens is that the client's developer has to be very security-aware, and that its security depends exclusively on TLS.

A lot of people misunderstand this last statement and conclude that OAuth2 is inherently insecure and useless and doomed. Even worse, they blindly repeat this kind of conclussions in talks and posts and comments and simply confuse people.

OAuth2 is very good for some use cases and sucks for others. It requires a good understanding of some security principles. It requires some compromises as well. But it's out there, it's working and it solves a very hard problem.

The use of MACs was never standarized, but the draft is pretty good and easily implementable. Today there are several alternatives as well.

(*): I mean the client doesn't perform MAC validation. Of course, audience and other fields should still be validated.


Why does DNS Spoofing not working on HTTP ,HTTPS Sites? [in my case]

Try only with the target ip specified:                                        ettercap -i wlan0 -T -M arp -P dns_spoof /TARGET IP///


How does drive by downloads work, and what does a browser being "secure" actually mean?

How is it still possible that the attacker can execute code in browser and make the user download an infected file without his knowledge?

In Google Chrome, files are downloaded into the Downloads directory without the user being prompted, so long as the file extension is not on a certain blacklist of known unsafe file types.

For potentially dangerous file types, the user must approve the download and/or opening of the file. There have been attempts to thwart this via click-jacking. Modern browsers such as Chrome and Firefox have a built-in delay to prevent this.

Some users can still be fooled though.

  What are the facts when calling a browser secure? all the browsers like mozilla chrome opera call itself secure but none of them are "bulletproof"

The term "bulletproof" is very vague.

In modern browsers, much effort has been applied to fix any vulnerabilities that would allow direct hacking out of the browser's built-in sandbox. It is important you keep your browser up to date to take advantage of these protections. Once you do that, the difference in security of the major browsers gets pretty small.

Even with no 'vulnerabilities' per se, the 'security' of various browsers may not be equal. Also it is highly subjective. There are many complex and edge case features various browser vendors can implement to protect your security.

For example, if a website asks for access to your Microphone and Video, both Firefox and Chrome ask for approval, but Chrome also requires that the website offers HTTPS encryption. Firefox does not have that requirement. (yet) That is not really a security issue in Firefox, nor a bullet-proofing of Chrome, but does make a difference in certain situations, such as public WiFi usage.
Some browsers do not yet support Content Security Policy. However, CSP is only a feature to help developers mitigate their own vulnerabilities.

All of these are very minor differences in the security of a browser.

I have a personal opinion that IE is one of the less secure browsers.

Again, always keep your browser up to date to take advantage of any new security features they have introduced.


implications of incomplete TCP handshake session

Many scanners which are used to detect open ports use incomplete or bad TCP handshakes.  Sometimes they are also used in DDOS attacks, but if that were true you would have 100's to 1000's a second.

There are SYN scans,xmas scans, and more.
They are doing forms of recon on your IP addresses.

I get scanned all the time, like 100+ a day.


How many places should TLS be encrypted/unecrypted for web traffic?

If your data is sensitive (more than regular personal data), you may want to use TLS all the way to the web server and decrypt in as few places as possible (ideally not at all). Especially CDN which you do not control should not be allowed to decrypt the data.

That being said, IMHO for most kinds of data, encrypting up to your firewall should be enough, as your local network should be protected. If it is not (you don't have adequate physicals defenses, like cameras, alarms, locks...), you may want to get some. Also all the equipment and networking (3,2,1) should be preferably in one locked room, where only few highly trusted employees have access, as physical access is often as dangerous as root privileges.

You still need to encrypt client to CDN and CDN to firewall (your building), but if your CDN is reputable, you can let it decrypt the data.


How can I generate a .gpg file for verifying Putty?

The signature file contains the signature made by the software author's OpenPGP key on the application and thus proves authorship (given you also validated the key belongs to whom it should belong to). There is not really any use in creating your own: the signature would prove you signed the application, but this does not help at making sure nobody tampered with the software you downloaded. If you'd be able to create a valid signature in the author's name on your own, the whole process of digital signing would be forfeit.

Instead, look for the original signature, which is provided right next to the software download.


What is the use of cross signing certificates in X.509?

It's about expanding trust, yes. If you trust both CA1 and CA2, and a cert is signed by both, you've got a very high level of trust because two seaparate entities that you trust have verified the cert.

It has the added bonus of increasing the ease of verification of trust, such as situations where you've got clients that trust CA1 or CA2 (but not both). In such a case, you can cross-sign a cert to be trusted by both. This allows more clients to verify trust without having to distribute separate certs for different CAs.

Another bonus is in situations where a CA's private key is leaked. Let's say CA1's key leaks and your cert is signed by CA1 and CA2. In the wake of the leak, CA1 issues a revokation for its public key and you can no longer trust anything issued by CA1. However, since your cert is cross-signed to CA2 as well, any client that trusts CA2 can still maintain a level of trust in your cert.


I would use a Match block in the sshd_config file to only permit direct root login from the machine(s) used for remote management. If those machine are on the same local network, IP spoofing should not be possible (at least from a remote machine). Something like

Match Host my.admin.machine
    PermitRootLogin prohibit-password

That way, root login is normaly denied from any machine other than my.admin.machine, and simple password login is not allowed from there (only key).


Buffer overflows aren't about setting the pointer to point to another arbitrary address.

A buffer overflow happens when an input causes your program to performs a seemingly-correct operation (e.g. "increment(): move the pointer forward 256 bytes") too many times, so that the pointer moves out of the intended data structure / array, and into another object.

A "fat pointer" contains information about the data structure / array size.
 This means increment() can have safety checks in its code, to make sure the pointer is within the appropriate bounds.  You still need safety checks somewhere in your code, but this lets you centralise it.


If their server is exclusively on SSLv3, then probably not yet, but very, very soon.

Apple has disabled features of SSLv3 already.  Mozilla plans to disable SSLv3 on Nov 25.  Google plans to disable it by the end of the year.  Microsoft may have already disabled it in Internet Explorer.

To test it, try disabling SSLv3 in your browser and connect to the site.   Viewing the cert in the browser might be enough, depending on whether or not there are multiple certs or multiple servers involved.

Poodle is a MITM attack, it won't take a site down, it will instead intercept communciations between the client and the server.  You may see nothing in the logs except an SSLv3 connection, as most browsers will use TLS 1.0 or higher.

Edit: Protocol renegotiation to SSLv3 should only occur between the client and the MITM, this wouldn't appear in the server logs.


Use password_hash() with a system-wide salt and a user-specific salt

That's called a "keyed hash" and the key is sometimes called "pepper."

Yes, there is a security advantage.  If the key is not stored in a database but is, perhaps, a constant in a program, then a database leak through SQL injection or similar will not reveal the key and your data will be nearly crack-proof.

Of course, if the OS gets owned, it sort-of doesn't make any difference what you've done.  However, it at least appears that many password leaks are due to SQL injection attacks.

There is an extremely useful essay on password hashing here: https://crackstation.net/hashing-security.htm  It has a section on keyed hashes.  That essay recommends against hard-coding the key, and that's right if you're going to install a program in a number of places.  For a one-off installation, I still think it's OK.  Just be sure that the key is generated using a cryptographically secure random number generator (CSPRNG) in any case.


Security implications of "local admin on host OS" vs "local admin on virtual guest OS"

From the security perspective , the current setup is better , i.e running virtual machines on host , instead of giving developers local admin rights , because it is not just about the virus problems that they are not given local admin access. There are other security implications to that. Installing virus is just one aspect of that.


Server infected with some kind of miner - can I steal the results?

A cryptocurrency miner will usually request bits of work from a server, work on them for a certain period of time (until the block is mined, either by it or by someone else), submit its result and start over with a new piece of work.

The miner itself doesn't hold much data, and that data is irrelevant as the recipient address for the profits of the mined block are encoded in it, so by the time a block is mined there's no way to "go back" and get the funds.

The only option is to see if you can crack whatever server the miner is connected to, and see if that holds a wallet which you can steal - in that case you'd be able to recover funds mined on your hardware and maybe the attacker's other victims, unless the attacker already spent this money or transferred it to another wallet out of your reach.

To be honest, on a CPU miner you probably didn't loose much money - in fact writing this answer cost me more than this miner could've made in a month, so I'd say let it go, nuke the server and move on.


Error in intercepting the request of an Android application

Not all Android apps respect the global/systemwide proxy settings, especially when running Android 7 or higher. It looks like you used a regular proxy but that might not work. You could try transparent proxies but that's considerably more difficult and might require rooting your device. I tried to do that a while ago in order to analyze the traffic of the official Stack Exchange Android app, but failed to do so because it's HTTPS traffic; instead, I choose to run it on an old device running Android 5.1.


Stack smashing protection, reordering variables

If the variables have been reordered so that p comes before a[30] in memory, and your only attack option is to overwrite p by overflowing the buffer in a, you cannot do it.

(At least not sensibly.  You could try for an arithmetic overflow in strcpy() by passing in a 4GB string, but it's virtually certain you'd clobber something important before you wrapped around far enough to overwrite p.)


Is this ransomware encryption or file corruption?

Your Shannon entropy score of 7.9 is very high (the scale goes from 1-8).

While I can't say for sure that this is the result of ransomware encrypting the files, it seems likely when we take into account your previous positive finding that identifies this as CryLocker.

I looked through my go to list of decrypters but didn't find one that specifically mentioned CryLocker. It's possible the identification of CryLocker wasn't quite accurate, and one of those decrypters could still help.


Is it possible to install a hardware key logger in iPhone?

In theory, it is possible. In practice, it would be very difficult and costly to do so. Also, I do not know of a key logger chip for iPhones that can be bought, but feel free to correct me in comments. Of course, an iPhone does not have a physical keyboard, so one would need to intercept the SPI bus and interpret the data.

Moreover, what would the repair shop gain from having key loggers installed in random phones? This gain would need to be more profitable than the cost of buying and installing a key logger chip.


My ASP.NET core application executable detected as Trojan

The Win32/Cloxer.D!cl detection is a machine-learning derived signature:

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AWin32%2FCloxer.D!cl&threatid=2147726003

Because of this, it could be flagging on any number of behavioral indicators including network connections, loaded libraries, or functions calls.

While it's possible that your packager or compiler is infected(a la XCodeGhost), it's much more likely that it's a false-positive.


Snort rule does not work when combining "content" fields

I know that this is an old question, but this has been something I've run into numerous times, so I figure that providing an answer may help others who have run into this.

My Explanation

In my experience, some versions of Snort have issues when switching from using HTTP options that reply on preprocessor parsing and then switching to not using them.  Given the rule you provided, the first content string:

content:"Content-Type: text/html"; http_header;

Utilizes the http preprocessor and the Snort engine sort of gets into the mode of parsing parts of the request/response.  Following up with the content string:

content:"Hello there";

... without specifying where to find it, the Snort engine has difficulty finding it.

Of course, this is my "theory" formed upon experience and trial-and-error troubleshooting.

Possible Solutions

Specify content:"Hello there"; before the other content (move to the left).  If applicable, specify fast_pattern:only;.
Leave the content:"Hello there"; where it is, but try adding the pkt_data; option prior to it.  This would tell Snort to forget about parsing HTTP request/response elements and move the doe_ptr to the beginning of the HTTP request (i.e. the packet) and then search for the content.  Or, if that content is expected in the file data of the response, use the file_data; option instead.  Again, pkt_data; or file_data; require you to put those options before the content options that need to be affected.


Claims based vs Permission based authorization

A claim is somewhat more arbitrary than a permission. A claim is 'blue eyes' whereas 'AddPerson' is a permission. It is an assertion from the identity provider that a given characteristic (or more accurately, an attribute) about the identity is true.

You can determine permission based on claim or characteristic because 'all blue-eyed individuals can do xyz' whereas a permission is explicitly calling out what you can and cannot do. With a permission you cannot (easily) determine a characteristic by, say, 'anyone who can do xyz has blue eyes'.

With that being said, a permission is a claim. It just happens that the identity provider is asserting the identity has the characteristic of having permission to do whatever.

In short: a claim is an arbitrary attribute about the identity, whereas a permission is an asserted right to do something.


SSL/TLS certificates that only certain users can use to talk to my server

Client certificates?
Set your SSL/TLS-server to reject any connection that does not present a valid Client Certificate.
Related questions

2012-05-03: Advantages of client certificates for client authentication?


Are MAC Address Filtering and SSID Hiding still worthwhile?

They're stumbling blocks, but not insurmountable. SSID hiding can provide some protection from people looking for any SSID they can get their hands on, and MAC filtering can keep casual riffraff out. As the only methods of protecting a WLAN they're pretty weak.

For someone who targets your network specifically, encryption (especially unbroken encryption) will provide vastly better security. MAC spoofing is trivial in most adapters these days, and after you've cracked the network to the point you can monitor in-flight packets, you can get a list of valid MAC addresses. SSID is trivial at that point as well. Due to the automated nature of the toolsets available, MAC filtering and SSID hiding aren't really worth the effort any more. In my opinion.


DDR memory technology has to be "refreshed" continuously by the memory controller in order to prevent the data from decaying into an unreliable state. Essentially, each "cell" of memory is a small capacitor which can be charged or not charged (representing 0 or 1). When you power down, the memory is no longer being refreshed, so that charge leaks out. The data gets less and less coherent over time, until it's just garbage.

If you're using DDR3, the maximum time you'll need to wait for data coherence to reduce to the 50% mark at room temperature (~25C) after power-off is about 45 seconds, though in practice it can be as short as 1.5 seconds. Once memory reaches this point, there is statistically no way to know whether its original value was a 0 or a 1 - it is unrecoverable. Keep in mind that the rate of loss of coherence is proportionate to temperature, so if your memory is a fair bit hotter than ~25C (it probably will be) then it'll likely lose coherence much faster. Equally, if you run your memory at below-freezing temperatures (hardcore overclocker, perhaps?) then the rate of coherence loss will be slower.

So, to answer your question more directly, you don't need to do anything but sit there for a minute after you've powered off. Unless your threat model includes someone grabbing your laptop and dumping it into a convenient bucket of liquid nitrogen during the first couple of seconds after power-off, you'll be fine.


Effectively limiting outgoing firewall traffic to frequently-changing IPs

Is it possible to get around such a scenario by restricting the IP addresses to a "range", normally a subnet block (as the external company had a contiguous block and so even though there was a low TTL, the rules would still be ok)? Do you external service providers either have a contiguous block or a known range of IP addresses? In my experience, most do.

From my understanding of the PCI requirements (disc: I'm a little rusty, it's been a while), the afore-mentioned solution would be sufficient because the destination is restricted and your rulebase will still have an explicit deny.

Another potential solution is to have a proxy server, either internally on the LAN or in a quasi-DMZ zone that the DMZ server can talk to the external services through. Policy can be really locked down on the proxy server such that external access from the DMZ server can be restricted to site, protocol, time etc. The proxy server is designed to deal with FQDNs (whereas the firewall typically isn't and can suffer considerabe performance degradation as outlined by @JeffFerland) so you could have a tighter policy as it'd be based on the FQDNs as destinations, not IP ranges.

I guess a lot depends on the QSA who turns up on the day :)

Additionally, I'm sure you know this but all "security best practices" (afaik) strongly insist on preventing outbound calls from the DMZ (period) so that if the box on the DMZ gets popped, the attacker cannot easily load further goodies onto the server or a piece of malware can much more easily call home.


Check validity of SSL cert on public network?

This got me thinking, if I was on a public network somewhere, could they issue their own certificate making it appear trusted, and therefore giving me a green padlock on my bank site for example?

Yes.

  does it appear trusted because of a group policy telling the PC to trust the cert?

Yes. (Or some other mechanism telling the PC to trust the cert. By default it won't be trusted)

  So mobile phones (or devices that aren't joined to AD) would say every HTTPS site is insecure?

Yes.

  If this were to happen on a public network, how would you ensure safety?

If you don't want your company to be able to intercept your traffic, don't use their equipment, and don't install their root certificate on your equipment.

  Would a VPN still protect you, or would they be able to intercept that too?

Depends on the VPN.

  How can a public network install a cert on your computer?

It can't, unless it uses some kind of exploit (similar to the way viruses propagate). That is much less likely to happen now than it was in the past.

  How would a VPN protect against a rogue cert once it's installed?

By not trusting the certificate. Nothing forces a program to trust all installed certificates.


I would like to check a Nokia N8 for possible software that might send any kind of data without my consent.

Do you want to prevent the phone from sending data for billing issues or are you interested in protecting confidential information?

  Is there a specific tool to achieve this?

There are software and hardware tools to analyze the content on the phone from the free Symbian OS SDK to Device Seizure v4.5 which starts at $1,795.00 (US). The more sophisticated and specalized the tool the easier it will be to come to a clear conclusion regarding the software and data usage patterns.

  Are there specific techniques?

For billing issues the easiest technique is to monitor your own data usage and compare your recorded data usage to the ussage you are billed for. If the two are not highly similar then there may be a problem. Ask your carrier or retailer about expected background data transfers.

For confidential data the most secure technique is to not put confidential data on the phone. Beyond that it depends on the size of the data and the length you are willing to go to protect your data.


I am leaving my company. I have been asked to leave my company laptop and a password to access it. What should i log out of

Legal matters depend a lot on jurisdiction (i.e. country, state/province for federal countries, professional branch in some cases...). However, in most of them, there is an official tolerance for using company hardware for limited personal use. E.g. if you have an office phone and use it to call your wife (or husband or whatever) that you will be late this evening, then you are not doing anything wrong. The same applies to accessing personal emails from a company laptop.

Doing so does not entitle the company access to whatever personal data remains on the machine. From the company point of view, personal data on a company machine is a minefield: if they access it, or let it leak to the next hardware owner, then you might be entitled to compensation. Thus, wiping the machine is the only sane advisable option for the company. If they not only intend not to wipe the machine but forbid you from doing so as well, then this means that one or several of the following may hold:

They are digging their own legal tombs.
They intend to read your personal data.
They have so sloppy procedures that they allow employees to keep critical business data on laptops without proper backups.
They don't understand the notion of "wiping".

In all probability, they just want to avoid the case where the former employee leaves the machine locked with an unknown password, and they don't know how to recover from that. This can be a problem in case of a BIOS (OpenFirmware in this case) password.

That being said, an OS X machine is, internally, a Unix system, so most if not all of your data should be in your user account directory. You could create a new user account (with administrative access), destroy the previous one, and ensure that the whole directory is gone for good. Don't forget to empty the trash can.

If that operation would count as "wiping" in the eyes of your inflexible future-ex-management, then you could limit yourself to deleting some specific sub-directories. Command-line access should show everything.


Does Kerberos support vendor specific attributes?

Microsoft has no SDK/API to change the kerberos protocol, and it wouldn't be a small feat to reimplement kerberos on both sides (client and server) as an authentication package.

I think you are missing a key point with your use case, kerberos is an authentication protocol, as such it should only deal with checking that you are who you say you are, network location isn't part of that.
what you require is authorization, this is abstracted away from kerberos as a security measure and it is a bad idea to change that.

what you can do is change the authorization part - on the Domain Controller you can decide which user is allowed to login to which computer (or a OU of devices) using group policy. if this is for your specific application you can always implement it at that level.

another way is to create a site per subnet and allow logon to each user per site. look here.


Guessing the whole PBDKF2 output from 1 half

PBKDF2 is supposed to be secure as a key derivation function, which more or less means that knowing some of the output bytes leaves no usable information for guessing the other output bytes. If you produce 20 bytes with PBKDF2 but the attacker knows 12 of them, he still cannot guess the 8 remaining with better probability than pure luck (i.e. 2-64, since 8 bytes is 64 bits).

Note, though, that the "P" in PBKDF2 means "password", and the main weakness of anything involving passwords is that passwords are, in practice, guessable through dictionary attacks. While having a partial output does not yield immediate information on the other output bytes, it can serve as a fast test for a brutal enumeration of possible passwords.

A "normal" dictionary attack on PBKDF2 assumes a situation where the password was expanded into a symmetric encryption key, used to encrypt a piece of data. The attacker "tries" passwords, each time computing the corresponding key, then trying to decrypt the data, and see if the result "makes sense". If the attacker knows some of the bytes produced by PBKDF2, then he can skip the "decryption makes sense" step, which helps him a bit.


It can be useful for anything where you want the box to be able to connect to itself but not allow other boxes to connect.

A good example would be a web server running Wordpress and MySQL. You don't want anyone on the web to be able to connect to the SQL server but you want to point Wordpress at 127.0.0.1 for SQL.

There may be some obscure side channel risk, for example if you had a vulnerable version of MySQL running. It might be firewalled off from the rest of the world but a local user could use for privilege escalation. But generally I can't see any problem with it because loopback can only be accessed if your already on the box.

Also I have a feeling it might be used for the box to resolve itself and blocking it could cause errors like "sudo: unable to resolve host [hostname]" but I might be wrong about that.


Is code injection possible in any compiled or interpreted languages?

Yes, this is a real thing. But just like with SQLi you can not just exploit any program, but a poorly written one with insufficient input sanitation could be vulnerable.

Lets look at interpreted languages first. For code injection to be possible here you need to have something that takes code in a string and executes it.

In JavaScript you have the eval() function that does that. So if you do eval(untrustedData) you have yourself a vulnerability. For this reason eval() is considered "evil" and you often here the recommendation to not use it at all. There are also more sublte cases that allows execution of code from a string, like new Function() and setInterval().

In PHP you also have an eval() function, deemed so dangerous that the manual includes a warning:

  Caution: The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

So how about compiled languages? They are less vulnerable because they don't have functions that executes arbitrary code, since that code would have to be compiled first. Off course you could write a program that generates source code (from untrusted data), compiles it, and runs it. But that would be a rather odd things to do.

You could argue, as iain does, that exploiting buffer overflows is a form of code injection, since you are injecting machine code into the program. I guess it comes down to semantics if you count that or not.


How to secure backup scripts so I do not have to hardcode passwords?

Have you tried AWS Secrets Manager (or Parameter Store). It's built for exactly this purpose.

Create a separate IAM Role for the backup process, and grant the required EC2 instance that IAM role. Then modify your script to call Secrets Manager to obtain the credentials and and don't store those credentials anyway except in the memory of the running process. (i.e. purge it once the process is one).

In the background, the EC2 instance will have a metadata instance that issues tokens that the script can use to call Secrets Manager. Once it's able to call secrets manager, it can get the actual db credentials to call your DB. Even deeper, the meta-data service issues only temporary tokens for the IAM role, which makes this approach even better.

A more old-skool method, would be to generate the API Keys for the IAM role, and hard-code those credentials onto the ~/.aws/credentials location of your EC2. Then your AWS SDK will use it to call AWS Secrets Manager with the same concept.

Ultimately, the concept is the same, use an API key to call an API that returns the actual credentials used. That API call is logged (cloudtrail) and returns only those credentials necessary to the call.


Question regarding browser windows when integrating with 3rd party payment software

Opening a new window or iframe does not change the protections provided by the Same-Origin Policy.  The origin inherit ice rules for iframes prevents two different domains from accessing each-others data.

There is no security or PCI-DSS requirement that would require a redirect from/to a payment gateway.  This maybe a usability requirement mandated by a specific payment gateway.


No, not really. Or sorta, I guess, but it's not usable.

You can fake it by creating a local token, which will eventually create a session and get to the desktop, but you're crippled because Windows doesn't have an AD ticket. As such, you can't reach anything on the domain, and anything requiring Kerberos or NTLM auth will fail in spectacular ways.

Additionally, you can't get a ticket (safely -- anyway) from AD for a user, and you can't make one, without actually authenticating to AD proper. The issued SAML token has no relationship to the ticket, so AD wouldn't know what to do with it.

One thing you could consider is creating an SSPI package on both the client and DC, which would exchange a SAML token for a Kerberos ticket, by virtue of the fact that AD has the necessary permissions to do anything it wants. The catch though is that everyone needs the package, and everyone needs to understand how to use the package.

On top of all that, opening a browser session in the Credential Provider context is downright scary because they run as SYSTEM.


Is there any mechanism that using multiple keys encrypt and decrypt a shared document?

You can achieve this even using just symmetric encryption.

You generste a random master key. Make a copy of the master key for every user that should have acces. Each user then encrypts his copy of the master key with his own key.

If the user keys are not available, encrypt them with their public pgp key instead.

When working with the document, user decrypts his copy of the master key and uses it to decrypt the document.

If a user that has access to the doc wants to grant access to another user, he just makes another copy of the master key. If you want to revoke users access, you change the master key and redistribute the keys only to users who should have access.


What exploit types do I need to protect against in PHP?

There is a large number of vulnerabilities and attacks that impact the security of your application. You can start with a list of the most common and critical ones and OWASP Top 10 is the most popular resource containing detailed information and excellent cheat sheets for a quick start.

Vulnerabilities come from insecure development practices so here is the OWASP Secure Coding Practices Quick Reference Guide in a checklists format. Implementation of these practices will mitigate most common software vulnerabilities.

Your questions is about input validation which is only a part of the problem you are trying to solve. Securing your web application is not an exact science where a complete list of all possible issues and fixes can be defined and implemented.

But still, input validation is one of the most effective technical controls for application security. It can mitigate numerous vulnerabilities including cross-site scripting, various forms of injection, and some buffer overflows.

Variables used to acquire user-supplied in PHP:

$_GET
$HTTP_GET_VARS
$_POST
$HTTP_POST_VARS
$_COOKIE
$HTTP_COOKIE_VARS
$_REQUEST
$_FILES
$HTTP_POST_FILES
$_SERVER[‘REQUEST_METHOD’]
$_SERVER[‘QUERY_STRING’]
$_SERVER[‘REQUEST_URI’]
$_SERVER[‘HTTP_ACCEPT’]
$_SERVER[‘HTTP_ACCEPT_CHARSET’]
$_SERVER[‘HTTP_ACCEPT_ENCODING’]
$_SERVER[‘HTTP_ACCEPT_LANGUAGE’]
$_SERVER[‘HTTP_CONNECTION’]
$_SERVER[‘HTTP_HOST’]
$_SERVER[‘HTTP_REFERER’]
$_SERVER[‘HTTP_USER_AGENT’]
$_SERVER[‘PHP_SELF’]


Do we still need to encrypt/decrypt data in Application Layer, despite using TLS/SSL?

Yes and No.

Encryption isn't a "have it" or "don't have it" sort of proposition. The concept of encryption only makes sense in context.

As an example that should more obviously demonstrate the failure: Imagine you have a document that needs to be kept safe. You upload it to your Dropbox account. Now, is it encrypted?

Yes, it was encrypted in transit. Dropbox uses HTTPS, so it was encrypted using TLS during upload (and any download). It's then decrypted on the other side after it's been transferred.

Yes, it's is encrypted in storage (as far as we know). Dropbox says they encrypt all data on their servers using keys specific to your account. It's then transparently decrypted for you on demand.

But No, the document is not encrypted in a way that matters to you. Dropbox syncs the files to all your computers, and stores a plain text copy on your machine. So if anyone looks at your computer, they can read the document without having to circumvent any encryption at all.

When encrypting data, you have to figure out what you're trying to protect and whom you're trying to protect it from. You need to understand what you're trying to prevent with your encryption. Once you understand what you're trying to accomplish, it should be immediately obvious whether the encryption you have is doing you any good or not.


I'm really just reiterating what @YourCommonSense said in a comment, but anyway:

There's nothing here to suggest that there is an SQLi vulnerability.  I've built systems like this that operate very similarly: they have a very expressive JSON input that allows the client to have more-fine grained control over their query.  This can be advantageous because it gives the client more control without having to adjust the server for every single use-case.  This definitely doesn't mean that there is an SQLi vulnerability.  As a for instance, in my systems each API endpoint (in this case the dataset might be the equivalent) is explicitly tied to a table and additional server-side-specified conditions that are always added to the query.  Any additional filters passed up by the client are explicitly joined in with the AND operator while the OR operator cannot be used at all.  Further, all client side conditions are explicitly white-listed: the client is only allowed to filter by a pre-defined list of columns and specifying the operator is not allowed: only the search value can be specified (the column itself explicitly determines what operator is used in the actual query).  Finally everything is built into a query that uses prepared queries for the actual execution.  All of this makes it just about impossible to have an SQLi vulnerability, while still allowing the client more fine-grained control over the actual API results.  I mention this not to talk about my system, but because what I built looks almost exactly like what you have, and the results you show are exactly what you would see with my system as well.  In particular:

You seem to have concluded that the WHERE (true) part of that query is the result of your 1=1 injection.  This is most likely not the case.  Making a parser recognize the 1=1 condition and auto translate that to true would be a lot of work and makes no sense - something like 1=1 would only show up due to SQLi, so I can't imagine this would be the desired behavior of any system.  Best guess is that the (true) part is added automatically to the query in all cases to make it easier to build the query (you don't have to keep track of whether or not you already had a condition and therefore whether or not you have to put AND in front of the condition you are adding on) and b) MySQL will ignore it anyway when it builds the query plan, so it will have almost zero impact on performance.
The fact that your comment didn't show up in the final query suggests that the system has parsed your condition and completely rejected it.  Again, your condition is obviously being processed by the system and not just being added straight on the end (hence why your comment is not in the final query), and there would be no reason for a parser to recognize your comment and remove it - those only show up due to SQLi vulnerabilities, so any system smart enough to parse a comment and remove it should (theoretically) be smart enough to recognize the SQLi danger and reject the request all together.
The condition on grp_id is there even though you didn't specify it.  This is likely a sign that this particular API end point (or dataset_id?) automatically adds in conditions that you will not be able to remove.
It does look like you got user() in the select, but it's hard to tell what (if anything) the significance of that fact is.

So I would say that without more details there isn't much to go on, but this doesn't look especially vulnerable from here.


How secure are most FDE implementations?

The FDE scheme varies between vendors, but the general idea is that there is a security chip on the device itself that combines data with the PIN/password in order to form the final encryption key. This means that even if you know the PIN or password, but you move the storage medium to a new device, it won't work. The data is not only locked to a specific PIN, but also to a specific computing device.

Offline attacks are infeasible, because even if you know the PIN, you're still forced to brute-force a key that's stored in the TPM or security chip. For example, on many Intel/AMD motherboards, the TPM uses a 2048-bit key derived from the user's PIN. You must brute-force this 2048-bit key in order to get the key to decrypt the storage medium. If you're lucky, the volume encryption key will only be AES 128-bit encrypted, which means you might be able to brute force you way through the key in about a century or so; Bit Locker also allows for AES 256 to be used instead.

Android, Apple, Linux, etc use similar protection schemes based on hardware chips, which are nearly impossible to tamper with (but not actually impossible) when available. You'd want to check the manual for specifics. On older devices without security chips, it might be possible to hack through FDE, but almost all devices put out in recent history will have some sort of on-board encryption chip.

These should be considered essentially uncrackable to any average attacker (state actors with nearly unlimited resources might find a way to get at the chip's keys, but it's still risky if the chip is tamper-resistant). If the original device is destroyed or disabled, such that the key can't be recovered, the data on the storage medium would be considered irretrievable.


There are a few things you can do that might help.

Add keyword blacklist to your site. If you get Trump and casino spam, drop any post containing the word Trump or casino.

Add a rel="nofollow" to any links provided by a user, including links in comments and links to user "home pages". Search engines are supposed to ignore any link so tagged, making them less valuable to the spammer.

Add a "probationary" period where new users can't post until a moderator has approved their post. Banhammer any account who tries to post spam.

Add a CAPTCHA. Spammers don't seem to waste much time on sites that make spamming hard. Not all CAPTCHs have to be hard-to-decode pictures; some can be simple questions, like "Check this box if you are not a spammer" or "What is the sum of three plus four?"

Don't worry about the extra call to services just yet. You need to get rid of the spammers first if you want people to stick around.


Is it possible to spoof a GPS satellite?

Yes, it's possible — even easy. No, GPS satellites are not designed to be spoof-free.

GPS wasn't designed against satellite spoofing, probably because back then they didn't even dream of someone doing that. Even back in 2008, this wasn't something easy and affordable. From Wired: Researchers Demonstrate How to Spoof GPS Devices:

  Researchers at Virginia Tech and Cornell University spent more than a
  year building equipment that can transmit fake GPS signals capable of
  fooling receivers.

Since then, this has become easier. All you need is a radio signal transmitter and some open-source software. See e.g. GPS Spoofing w/ BladeRF from Crazy Danish Hacker.

Kaspersky's article on Is it possible to guard against GPS attacks? explains how this is not something that could be easily fixed:

  Although the problem has been known for some time, there is a major
  obstacle to developing protection measures — the key equipment is in
  space and will not be replaced right away. GPS satellites emit what
  they emit, and no one can add standard protection tools, such as
  encryption and certificates, to the signals. Security measures so far
  have been more experimental in nature and not for large-scale
  application.