Can I use 777 file permissions inside server virtualisation (that only I have access to) without worry?

Under the premise that the system is so well-secured that there is only one person which can connect to it via network, then file permissions do not really matter anymore. The operating system can only enforce them against local users anyway. When an attacker can not log into the system or influence some public service running on the machine to do their biddings, they won't be able to access files, even when they are world-readable.

But this premise is illusory.

When you run a webserver on the box or some other service which can be accessed by other people, this services becomes an attack surface. An unknown vulnerability in the webserver (or in a buggy web application running on the webserver) could allow an attacker to take full control of the webservers process. The attacker can then access any file the webserver can access. That's why you usually run a webserver under its own user and use file permissions to make sure that this user can only read and write the files it has to for operating that webserver. When the worst case happens and an attacker indeed takes over the webserver, any damage is contained to the files and directories directly relate to it. But when file permissions allow the webserver to read, write and execute any file on the machine, an attacker can literally replace the whole operating system and lock you out.

When you use virtualization, the host-system can access anything which happens in your virtual machine anyway. File permissions won't be enforced, because the attack would bypasses the operating system which runs in the VM and directly access the virtual hard drive file in the filesystem of the host machine.


AIUI (I am not a cryptographer)

We measure the security of cryptography by asking "given the best known attack how much computing power would it take to break this". This is clearly an imperfect measure, there may be a better attack that the mathematicians haven't figured out yet but sadly it's the best we have in most cases.

DH works in a "finite group". Such a group consists of a finite set of possible values along with an operator that works on two values from the set and returns another item from the set. The operator must also satisfy a series of axioms that I won't get into here. The number of elements in the set is known as the "order" of the group.

Confusingly there are two ways to write groups. Some groups are written "like addition" with the operator represented by "+" and the identity element represented by "0". Others are written "like multiplication" with the operator represented by a multiplication operator (".","*","×" or nothing at all) and the identity element represented by "1".

We can apply the operator repeatedly. If we are thinking of the group by analogy to addition then repeated application of the operator is analogous to multiplication. If we are thinking of the group by analogy to multiplication then repeated application of the operator is analagous to exponentiation. From here on I will refer to this repeated application of the group operator as discrete exponentiation. Thanks to associativity, discrete exponentiation can be computed in time proportional to the log of the exponent.

DH relies on discrete exponentiation being computationally infeasible to reverse. Specifically for "A = ga" it should be infeasible to find "a" given "A" and "g". The problem of reversing discrete exponentiation is known as the discrete log problem.

The difference between traditional DH and ECDH is what group is used. Traditional DH uses the nonzero integers modulo p under multiplication. ECDH uses an elliptic curve.

The difficulty of solving the discrete log problem depends heavily on the particular group chosen.

Afaict for elliptic curve the best known algorithms have a complexity of roughly √n where n is the order of the group. So for 128 bits of security we need a group with roughly 2256 entries and our keys will be roughly 256 bits in length.

For traditional (modulo p) it is possible to use the general number field sieve to solve the discrete log problem. This algorithm has a much lower complexity for a given group size. So a much larger key is needed to push it into the realm of computationally infeasible.


Is it dangerous to share a USB flashdrive?

Using something like BadUSB can turn any USB device into a keyboard, RubberDucky makes this even easier.

Using these techniques you can run commands and install mallware on a computer without the user ever pressing a button or opening a file. So yes, using a untrusted USB (storage) device can be dangerous.


For a cipher school challenge I need help breaking this cipher

If I where you I would look at Cryptanalysis, in particular letter frequency. The idea of which, certain letters in English occur more regularly than others (e.g. vowels).


Are there already any Win10 remote exploits?

This question could have been answered with a quick Google search. You can go to CVE Details and find out information about vendors, products, versions, and so on. Most CVEs will post information relevant to a vulnerability, e.g.: "Exploit available." As for "more exotic ways", I think you need to understand exploits, threats, and threat actors in general. Many organizations are compromised via phishing/social engineering primarily, then applications (Office, Excel, IE, etc) are "client side" attacked. (Browser based, file based, etc).

Exploits have been dwindling for some time now, so finding them is increasingly difficult, and threat actors aren't going to burn "0 day" exploits when they can continue using traditional methods that work time and time again. For what it is worth, metasploit's team does a decent job of adding exploits when there are proof of concepts in the wild/discussed. But you need to also understand that there is a huge market for exploits. What this means is that some researchers can hoard their exploits, sell them to heavy hitter buys (govs/mil), or sell them to some exploit clearinghouse. So if you think someone will be making it rain 0 days some time soon, I don't see it happening.


To answer your first question: I think the big risk with your set-up would be that you cannot prevent access to your initramfs. This would allow an attacker to gain knowledge on your set-up, which then allows for a full MITM kind of attack, accessing your software (with the private key built-in). From that moment possibilities are endless as you could reverse engineer that package you want to send to your device, gaining access to that ssh keys you do want to keep at highest security. Or maybe modifying some code so you think all is alright, but actually isn't.

Removing some connectors ain't going to help you to a determined attacker which might just re-solder those connectors. And a very determined attacker with time and money might just do a full dump of the flash memories and start working that way.

The fact is, physical security opens a wide range of possibilities to attack a device, which can almost never be prevented from happening (unless booby-trapped or so).

Another risk I see is that your set-up is relative complex, so things could break. For instance, when a simple SSH tunnel cannot be opened because of a firewall rule. Or, what about if the dropbear software you want to use has a critical externally exploitable vulnerability. How would you fix that?

Question 2: Without giving more details on what you actually want to achieve with these headless devices, it is hard to give some advise on what might be a better solution in your case. It sounds like you have absolutely no trust in the places or people you install that device. What makes you still want to do it in the first place if there is no trust at all?


How to use GPG to pass along encrypted content and double encrypt

If you want to encrypt something twice, you can just call gpg twice:

<  name_of_file gpg --encrypt -r lance@email.com | gpg --encrypt -r friend@email.com > double-encrypted.gpg.gpg

Please note that the approach of encrypting a file for someone that they need to give you back doesn't make much (any?) sense. They receive an encrypted file, just to send you a (half-)decrypted copy (of something you already have), and in the end you need to send them the plaintext file anyway.

If what you want to do is to ensure that they need to contact you before decrypting it, you could give them a symmetrically encrypted file rather than one encrypted with your gpg key:

<  name_of_file gpg --cipher-algo aes --symmetric | gpg --encrypt -r friend@email.com > double-encrypted.gpg.gpg

This way you conceal the secret password (randomly generated, etc.) until when they need to decrypt it, and there's no need to send you back the file you already had.

I am skipping the signing part since you don't specify that you actually need signing, and you probably don't need it. I agree with Steffen Ullrich that it would be preferable that you stated you actual goal, rather than the way you wanted to solve it. Specifically, please note that this double-encryption doesn't preclude them from keeping a copy of the plaintext file and use it later on without your knowledge.


How long can X.509 certificate chains be?

Theoretically, X.509 chains are unlimited in length. The Basic Constraints extension can apply a per-chain limit; this is used mostly for CA that agree to issue a sub-CA certificate but want to constraint that sub-CA to issue only end-entity certificates.

Implementations may have limitations. In fact, with some carefully crafted certificates, one can make a path-building application explore n! potential paths of depth n, and since factorials go up pretty fast, this can lead to huge denial-of-service attacks. Correspondingly, implementations tend to impose a relatively low maximum length (I know I used '8' for my own implementations).

In broad conceptual terms, trusts dilutes pretty fast upon delegation. When a CA issues a certificate to a sub-CA, it not only asserts that the sub-CA public key is owned by that sub-CA, but it also empowers it to perform that kind of verification on behalf of the parent CA. When a CA issues a certificate for an end-entity, it checks its identity; when it issues a certificate to a sub-CA, it also needs to make sure that the sub-CA won't be gullible. With a third level, the CA must ensure that the sub-CA is not gullible and won't issue a certificate to a gullible sub-sub-CA.

So the reflex would be to try to keep chains short rather than long.

Be wary of the "single point of failure" expression. It normally applies to operational continuity. Here, we are talking about security: a single rogue CA compromises security, regardless of how many other paths you create. This goes somehow in reverse with the SPOF rule: you avoid SPOF by adding redundancy, but in the case of certification, any involved CA is by nature able to compromise things -- the more CA you add in the mix, the more vulnerable you get.


Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32

The answer to your question is included in your question. To cite:

  This issue can by avoided by disabling block ciphers of 64 bit length (like DES/3DES) in all the SSL/TLS servers.

Thus remove the following ciphers which you have explicitly added to your configuration:

"DES-CBC3-SHA",
"ECDHE-RSA-DES-CBC3-SHA",

Note that you should remove all use of these ciphers because for some unknown reason you have added these ciphers twice. Additionally you should explicitly deny any 3DES ciphers which might or might be not included in your HIGH setting (depending on the version of OpenSSL) by adding an explicit !3DES to the cipher set.

Apart from that I recommend to follow known good ciphers sets like the ones recommended by Mozilla.


How ethical is it to publish an (anonymous) password list from real sources

Lists of known-compromised secrets are very valuable to people who are trying to make systems more secure, especially for things like passwords or password-equivalent credentials. Consider Troy Hunt's excellent "Pwned Passwords" page, which is built using a massive corpus of compromised passwords (and you can download it, if you want to, and also download software to set up a password-check service that doesn't send any info at all to a third party).

In addition to helping users test their own secrets, systems like this are valuable for those who want to establish secure authentication systems, because such systems should reject credentials known to have been used elsewhere (and especially if they are known to have been exposed publicly). The latest NIST guidelines actually specifically suggest checking candidate secrets against ones known to be compromised, so having such lists of compromised secrets is essential to following the guidelines!


opening infected files on Linux and Raspberry Pi

Not necessarily. First of all you need to identify the platform the malware is made for. If it's made to target linux, your argument is totally invalid. Secondly, there are two types of analysis that you can perform - dynamic and static. Dynamic involves running the code in a secure environment and understanding its behavior. Static analysis is mostly code examination in assembly for most executables, unless java or .Net. So, you need to identify the malware, set up a linux and a windows environment in vm's with the proper tools (diasassemblers, hex editors etc.) and find out more info the hard way. You can also set up Cuckoo, it's a very good sandbox which does automated dynamic analysis, both on windows and linux. Takes time to set up, saves lots of time in the aftermath!


Is there a USB exploit to bypass Windows password login?

There is a category of programmable usb sticks-devices running on atmel or similar microprocessors that act like hid's. Shortly, an HID is plug-n-play. no security checks, no questions asked! He could have probably programmed it in a way that would execute such system commands, it would give him access to an account. It's not that hard. Windows loads all the passwords in memory. And since hid's run at a high-priviledge service, its not hard to give your code the rights to do these tasks.

Check these: rubber ducky, HIDIOT and even Arduino. Since their microcontrollers are capable and there are libraries, why should the developers' code be limited to legitimate usege? ;)

EDIT: Since it was asked, I found some examples of code that work with devices like this:

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Attacking-Windows-At-The-Logon-Screen,---Gaining-Access-To-CMD-With-System-Privileges.

So yes, hid devices like these can actually execute code.

I also found another type of usb attack: https://room362.com/post/2016/snagging-creds-from-locked-machines/


Is upgrading key-stretching algorithms and/or repetitions a thing?

Upgrading passwords hashes is a thing. Indeed, as per password hashing theory, the iteration count in a good password hashing function (e.g. bcrypt) is a trade-off: you make the function as slow as you can tolerate in your current context. When you buy new, faster hardware, you can increase the iteration count, and thus you should. The iteration count allows to counter the effects of Moore's Law, but this works only as long as the count is indeed regularly increased.

The generic method is to wait for the user to come back, and re-hash the password with the new parameters (or even new function) at that point where your server indeed obtains the password and can work on it. People who do that often couple it with an expiry policy (accounts which have not been accessed in two years are closed or at least "frozen").

If we want to do more, i.e. upgrading password hashes in an offline fashion (without waiting for the user to show up), then we have to put our hands in the crypto. One can devise some nesting hashing mechanisms as described in this answer, but that's crypto design so one should be extra careful and basically refrain from it. Generically, you "hash the hash" to (temporarily) strengthen a hash value until the user comes back.

For the ongoing Password Hashing Competition, the call for candidates listed as desirable feature:

  Ability to transform an existing hash to a different cost setting without knowledge of the password.

Such a feature requires a specific internal structure. Some PHC candidates offer it, e.g. mine.


What is the most "safest" architecture to run in QEMU?

Exploit counting is not helpful here, because the numbers are skewed by non-targetted attacks. If a bad guy doesn't care what machines she gets control of, then she will target Windows on x86, because there's a billion more of those out there than BeOS on PDP-11.

Since you are primarily defending against targeted attacks, your focus should be on hardening the specific instance.

Indeed, there's a case to be made that you should go for x86 on your guest as well. It's probably the most popular port (citation needed), which probably means the most eyeballs are on it looking for bugs.


What to do if you think you discovered a zero day vulnerability? (white hat style)

There is An ISO dedicated to this subject https://www.iso.org/standard/45170.html

It is generally accepted to work with the vendor affected and give them time to resolve the issue within a reasonable time frame.  Google project zero takes the stance of 90 days to fix from initial disclosure to the vendor and full disclosure from that point.


Will RSA parameters be sent in a Server Key Exchange Message in TLS 1.1?

As TLS 1.2 puts it:

  The ServerKeyExchange message is sent by the server only when the
      server Certificate message (if sent) does not contain enough data
      to allow the client to exchange a premaster secret.

Therefore a ServerKeyExchange message containing a RSA public key would be used when the server's public key is not fit for key exchange (e.g. it is in a certificate which is marked as signature only) but client and server wish to use RSA for key exchange nonetheless.

Sending a RSA key like this is a feature which has fallen out of use, but it was used in TLS 1.0 with the RSA_EXPORT cipher suites. At that time, there were rather stringent regulations in the USA, limiting the size of cryptographic keys that were used for encryption in systems which were exported outside of the USA (these regulations were lifted in 2000); in particular, RSA encryption was limited to 512 bits (and 40 bits for symmetric encryption). The RSA_EXPORT cipher suites complied with these export regulations. When the server has a RSA public key, the client and the server agree to use one of the RSA_EXPORT suites, and the server's public key is larger than 512 bits, then the server must send a ServerKeyExchange message with a RSA key of at most 512 bits, and use its permanent RSA key (the one from its certificate) to sign the ServerKeyExchange message.

Dynamic RSA key generation is a bit cumbersome and expensive; a given SSL server can reuse such a key with several clients, but it is still heavier than DHE. The main use case was to support feeble clients who can do RSA only; however, even if RSA public key operations are very fast, ECDHE (Diffie-Hellman with elliptic curves) is competitive and much easier for the server. TLS 1.1 clients are allowed to advertise support for the RSA_EXPORT suites, but only for backward compatibility with SSL 3.0 and TLS 1.0 (section A.5 of TLS 1.1):

  TLS 1.1 implementations MUST NOT negotiate
     these cipher suites in TLS 1.1 mode.  However, for backward
     compatibility they may be offered in the ClientHello for use with TLS
  1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
     server did not choose one of these cipher suites during the
     handshake.  These ciphersuites are listed below for informational
     purposes and to reserve the numbers.

The ServerRSAParams structure in TLS 1.1 is thus a survivance from TLS 1.0 which somehow evaded the wrath of the RFC 4346 editors, but was finally removed when RFC 5246 was produced.


How does the HMACSHA1 algorithm really work?

You're confusing things. HMAC-SHA1 is a "Hash-based message authentication code" that uses SHA1 as hash. PBKDF2 is a key-derivation function. HMACs can be a primitive in the context of such a function but they aren't equivalent.

You CAN use a HMAC for creating salted hashes but you can as easily simply add the salt to the value directly before hashing and achieve the same thing. HMACs are more commonly used to validate the authenticity of messages.

For the .net question, I suggest you ask in stackoverflow but you might have a look at the HMACSHA1 class that is in the  System.Security.Cryptography namespace.


Wireshark: could "Follow TCP Stream" yield an empty window? or is it a bug?

Sure, it could be a bug.  Alternatively, if no packets containing data (all packets are empty) are included in the TCP stream, you'll also get an empty window.


Web site vulnerability discovery by scanner

Difficult to say without knowing how the vulnerability scanner was configured.

I can tell you from experience there are 3 ways that I know of it could have been found:

1.) A web application vulnerability scanner will crawl all URL's found. Is it possible there is a link to this service or page some where else on the site or disclosed through an error page/message?

2.) A web application vulnerability scanner will search for known/common and even unknown/uncommon dirs by directory fuzzing.

3.) The web application vulnerability scanner was provided a list of physical files that resided in the web dir. It then attempted to scan each file without authentication. If proper authentication mechanisms aren't in place, it could have accessed the file in question.


Why do public key certificate "Trust anchor"? Does this introduce a single point of failure?

I can think of many reasons.
The first one, is economical. Effectively, getting a certification is costly, and the higher you are on the chain, the more expensive it gets. Using, what you propose might theoritically be interesting, but it will cost twice as much to companies (don't forget, CA are economical entities that sell their services, they won't do it for free).
Some studies have pushed your solution further and have proposed even P2P certification, here is one paper that talks about it. However, the problem with distributed certification (in opposition to centralized) is the difficulty to control and establish normes and rules.

Finally, if we look at the solution you propose i can see some inherent problems in it. At least, in the way you present it there is no hierarchy CA-3 is certifiyng CA-1 and vice versa, but clearly one has to be a higher authority and that one can't be certified by a lower authority.


What are the risks that will result out of these ports, if I left
  them open?

As a security good practice, ports should be open only on a need-to-be basis.  You are exposing the services that are listening on those ports you left open to exploits. Why? Because a service means something is processing data and thus you are also exposing the vulnerabilities of the applications using those ports.

For example if you let your FTP port open to every one without any restriction rules (firewall) then a hacker could load lot of porn videos to consume lot of space of your server which thing will lead for example to very slow connection to your FTP service. Also lot of ports open expose you more to Trojan Ports.

This schema summarizes better the answer to your question:

  And is there any way to handle them without closing them?

Yes, you can leave those ports open but under the condition you have to limit what is allowed to listen on them: that is the job for firewalls. For example, on port 21, allow only the IP address of your home office or home to connect to it and no one else.
You can leave them open and setting all the closed ones to stealth.
If you can change a port's number then do it. For example if you can modify the port 21 (FTP) to a higher one (3737 ?), that can lead the hacker to go away because he would start to scan common ports (20, 21 ...) and since port scan takes time, he could be impatient to wait until the scan performs over the 3737 port.
Use free services that could help you such as this free firewall and from time to time CanYouSeeMe.


I wonder if my MacBook Pro with OS X got hacked?

I assume that you are in the /etc/sudoers file. Therefore, things are working as expected in the stock terminal. Also, it would be weird for a rootkit of any ohter hack to remove you from your own sudoers file; rootkits enable extra accesses to the attacker, but don't disable access to the normal users (if only because functionality breakage attracts attention, exactly the opposite of what a rootkit aims at).

So all symptoms so far point at a bug in iTerm2 (especially since you just updated it), not at an attack.

My guess would be that iTerm2 changed the way it allocates its pseudo terminal. In Unix systems (including MacOS X), command-line utilities must run in a special device called a terminal; it is an input-output device which handles characters but also concepts such as a "terminal size" with a given number of columns and lines. This comes from a time when terminals where really tangible hardware, like that one (I spent many coding hours on a VT220). In less ancient systems, we have graphic cards, millions of pixels and colours, and terminal emulators which are applications like iTerm2 which make believe that there is still a terminal connected to the machine. To do its job, a terminal emulator obtains from the kernel a pair of pseudo terminals: these are two devices (i.e. special files), one which will look like a true terminal to the shell and command-line applications, and the other which offers a backwards view of the former. The terminal emulator translates what it reads from and writes to the second pseudo-terminal into graphical concepts like drawing characters on the screen.

Therefore sudo will run in a pseudo-terminal which was allocated and set up by iTerm2. sudo is known to be picky about terminals; see for instance the requiretty option in the man page. "For security reasons" (an all-time favourite excuse), sudo may require the terminal to be somehow "genuine" and linked to a real session from the operating system. To be compatible with these sudo requirements, terminal emulators must jump through a variety of hoops in a complex ritual dance. I find it possible that the iTerm2 update changed some obscure parameter which sudo now declares heretic, explaining the message.

As investigation steps, try to launch these commands in a standard Terminal and in iTerm2:

id
ls -la `tty`
w

First command will tell you who you are (from the point of view of the machine), second command will show the pseudo-terminal device currently in use, with access rights, and third command shows currently open "sessions" (then again with corresponding terminals). Any discrepancy between the two terminals could point at the proximate cause for your issue.


If you can break this authentication system then you can break into my house

A few things:

First, there is already a scheme to turn an unkeyed hash into a keyed hash. It's called HMAC; if you have a four step process (client says "send me a nonce," server sends client a nonce, client computes HMAC on the nonce with password as key and sends it back to the server, server verifies HMAC), that should work (the properties of a MAC require that an attacker without the password can't feasibly create any forged data-MAC pairs, even if he can get the real user to create as many data-MAC pairs as he wants. If the server does not repeat nonces (e.g. if it uses a counter), this should work; you don't need to worry about a random nonce, because HMAC doesn't require it.

Better, especially if you need to send any information afterwards, would be to use a standardized protocol like TLS-SRP. Unlike normal TLS, TLS-SRP doesn't require a certificate; you use a password instead.

No matter what, you should not be designing your own scheme. Designing your own security protocol is something that has a tendency to go badly wrong. Security is hard; minor mistakes can easily totally destroy the security of a scheme. Use a standardized protocol. TLS-SRP might work well; a regular TLS protocol would also work, but it'd be a bit finickier because you need a certificate. Other standardized authentication schemes can work too. But do not just throw data in a hash and assume it'll be secure.


How to detect suspicious tokens collected by a hacker

Sure, but this makes a certain set of assumptions.

The OTP is event-based, not time-based
You have to be tracking previously used tokens
You have to track expected future tokens
The user doesn't have the ability to reset their OTP sequence with the initial seed

In theory with an event-based OTP once you use it anything generated before it is unsuable because the server should only be expecting OTP's generated after the current one. So if an attacker collected unused OTPs they wouldn't work after the user authenticates with the latest OTP.


If third party ads are embedded as iframes they might be used for social and UI redressing attacks, i.e. simulate warnings, buttons, input fields for credit card or similar to trick the user. But with iframes it cannot be used to  steal user data from the original page. If ads are instead embedded as Javascript it gets even worse, since this way the code in the ads has full access to your site and can read and manipulate the page, which includes reading any data entered by the user.

This problem is not only restricted to the checkout page and also not only to ads but is relevant whenever you include third party Javascript libraries into your site and thus affects also social media buttons or similar. If you include third party script into a page  the third party can get full control of this page it cause actions with the identity of the currently logged in user.


The difference between a honeypot and a greynet is in the level of realism and interaction that they present and also the type of network element they present. A honeypot such as Honeyd will typically present a greater level of realism than a greynet since it could really act like a host would. Different ports open, OS faking etc that accommodates a greater interaction with the potential attacker. A greynet will simply be an available range of IPs than should receive no traffic and will offer very little interaction to the attacker. The admin knows there should be no traffic on that IP and thus knows there is either a misconfiguration in the network or a malicious entity at work. In summary

A honeypot is typically:

A single IP on a network representing one host
Can offer a great level of interaction to the attacker

A greynet:

Is a collection of IPs on a network
Can offer limited interaction
with the attacker but not to the extent of a honeypot

If you would like to know more on how greynets fits into the field of network telescopes and network monitoring I suggest you read Section 2.5 of Professor Barry Irwin's work PhD thesis. He presents a small taxonomy of the different types of network telescopes such as darknets, dimnets, greynets, black-holes and sinks.

It is available here: http://www.researchgate.net/publication/265121255_A_framework_for_the_application_of_network_telescope_sensors_in_a_global_IP_network

Please bear in mind that my answer is based on normal interpretation of the terminology. Someone can implement honeypots on each node in their greynet or customise their greynet with additional functionality.


What is an SSL certificate intended to prove, and how does it do it?

Your key theory: basically right, but authentication is usually done by encrypting a cryptographically secure hash of the data rather than the data itself.

A CA's signature on an SSL certificate should indicate that the CA has done a certain amount of diligence to ensure that the credentials on the certificate match the owner. That diligence varies, but the ultimate point is that they're saying that the certificate they signed belongs to the entity named on it.

See http://en.wikipedia.org/wiki/Digital_signature#Definition


I recommend Bruce Schneiers Secrets and Lies, which I read recently.  It's a good introduction, but not the same way SICP is an introduction to programming.  It does a good job with teaching mentality though.


Does the NSA/CIA have the capacity to crack AES?

Major government organizations which have the task to help their countries companies and protect the local economy still recommend to use AES. I doubt that they would provide this recommendation if they would assume that other organizations might be able to crack AES.

  AES has been out almost 20 years, I would find it unbelievable security agencies wouldn't have cracked it by now.

While the age of the algorithms might suggest that somebody must have cracked it in the meantime it might also be an indicator that the authors have created  a very good algorithm.


When logging out of a website is anything else required then destroying the session?

No, you shouldn't be doing this and not just for minimal performance gains. I realize what made you think it'd be a good practice, but let's analyze these two quotes from the PHP manual a bit more:

  session_start() creates a session or resumes the current one based
  on a session identifier passed via a GET or POST request, or passed
  via a cookie.

  session_destroy() destroys all of the data associated with the
  current session. It does not unset any of the global variables
  associated with the session, or unset the session cookie. To use the
  session variables again, session_start() has to be called.

OK, that's clear. You also mention in your post on SO that there's a chance that the user can directly navigate to this URI where you'll be running this code from. You really shouldn't be doing this and you should at the very least check user log-in data and the referrer string before starting the session and delete the session whenever user state changes. But let's say you didn't change your code and we can navigate to the URI in question. Now imagine this scenario:

I have access to one of your legit user's computers, his/her network, can access your web application through same IP, and can collect his/her client-side session data
I make a POST or GET request with no session data to your URI running this code
I manually add these session fragments (session cookie, user-agent string) that I have access to in my modified browser

Voila!

All of this is really easy to do and plenty of people with direct access to targeted user's computer would have the means and reasons to do such a thing, if they only had the knowledge to. And you're slightly lowering that bar.

Let's see what will happen.

session_start() will be called before the session was invalidated on your web server (which happens on session_destroy()), effectively creating a new user session. I can then replace my new session data with the old (stolen) one, and your web application will have (based on my user-end session data) no reasons to suspect I'm not the user the session was created for in the first place. It will resume as if I was the previous user I stole session data from.

So how does this differ to session hijacking when using session handling routines in their intended order?

In a long discussion with @Xander dissecting PHP session handling routines, we've come to the conclusion that it doesn't change much anything in that sense. However, you also gain nothing by doing it so, and might result in breaking functionality of any third-party user session framework, if your PHP application depends on in. Quoting your related SO question "I'm concerned that if a user directly navigates to this page there may be an error destroying the session" does expose another concern, that you're essentially enabling exploiter a look into your user-end session data structure for free, without any user authentication before creating it. Saying "But I'm deleting it immediately!" doesn't really apply in this sense, as session_destroy() "...does not unset any of the global variables associated with the session, or unset the session cookie." Saying it differently:

You just made session hijacking slightly easier, not the other way around!

TL;DR - So in short, you'll have to do it 'the boring, standard way' as that's in what order these two session changing routines were designed to run.


No, the exit relay does not know your VPN IP.

It might be helpful to understand how Tor works. A diagram from the EFF explains it well:

As you can see, the third relay, the exit, can only see the site you are visiting and, if you are not using HTTPS, the traffic to the site itself. The exit does not know your IP. In fact, it does not even know the IP of the first relay (the guard) that you are connecting to. Tor works because no one relay can simultaneously know both who you are, and who you are connecting to. When you use a VPN before Tor, what you are doing is effectively changing your public IP from that of your ISP to that of your VPN. An exit relay whose traffic has been intercepted will not be able to know your VPN IP any more than it would be able to know your public IP were you not using a VPN.

It is important to remember that most of the times Tor has failed people were a result of either operational mistakes or browser exploits. While Tor is very good at hiding the origin of internet traffic, a vulnerability in the browser could be utilized to bypass Tor, revealing your VPN IP or even your real IP. The best way to avoid browser exploits is to keep Tor Browser up to date, and to set the security slider as high is practical. If you want even further guarantees, use Tails.


How smart card with client certificate is used during SSL/TLS session

Precisely, can I remove smart card from card reader once I successfully started a SSL/TLS session?

Yes. I think that is the most likely scenario. The client cert is used to establish the initial connection and negotiate a SESSION KEY. This is the initial session negotiation. After that, you can theoretically RENEGOTIATE any time the server (and sometimes the client, too) feels like it. But that depends on the specific web app. However it would be out of the ordinary, and I don't think it's very likely.

But just try it yourself and/or ask the admins of the web app.


It's not designed to be secure. It's designed to be convenient. A well configured DNS server should not reveal all names it controls, but all it takes is a minor misconfiguration somewhere.

Anyway, the entire IPv4 space is scanned regularly by various actors, including shodan.io. Do not assume any privacy for anything that is visible at a public IPv4 address. There's tools that will map out the entire IPv4 space in hours. Some people scan for their own purposes, benign or not - and others like shodan.io put it online in a searchable form for anyone (willing to pay).

In short; if you rely on your host name to be secret, you are doing something wrong. It should not be a concern.


What is the name for "imperfect" verification options?

Probabilistic or statistical authentication are probably the best fit, the alternative to deterministic authentication. (Though technically, there's a degree of probability involved when password hashes are used, rather than plaintext passwords, let's just ignore that for now.)

Biometric implies a probabilistic system, but the converse is not true, e.g. knowledge-based challenge response, recognition/CAPTCHA or signature/gesture systems.

There a useful PDF paper (thesis) on the topic of biometric probabilistic models here:
http://infoscience.epfl.ch/record/111855/files/EPFL_TH3954.pdf

Other related terms used in this context are: non-deterministic, stochastic, biometric hash, qualitative, intra-personal variability.


Is there a way to overwrite a file being used by a service without service management permissions?

Generally, binaries can be renamed while they are executing, unless the process (or some other process) explicitly prevents this. Simply rename the binary and then drop a malicious one in with the old name. When the computer reboots (or the service restarts), it'll run your version.

Another approach is DLL planting. Find a DLL that the app uses (ideally not a system DLL, and definitely not one that is loaded only as a resource file) that is not being loaded by explicit path, and replace it with a malicious version. You can either use the renaming trick mentioned above, or simply take a DLL that is normally loaded from another location (such as System32) and put your malicious copy in the service's install directory (or working directory, if different that's writable).

Actually weaponizing this is left as an exercise to the reader, of course, but I think it's important to post this answer because a lot of people don't realize that executing a Windows binary does NOT inherently prevent the binary from being renamed.


Protecting SQL username and password information when connecting via R or Python?

If you fear that the server is compromised and the attacker gets access to the scripts you need to store the passwords outside of the scripts where the attacker has no access. If this is possible depends on the kind of attack you expect:

If you expect only a limited attack where the attacker gets only limited access to a few data then you might store the credentials in a file where the script user has access but not the attacker.
If instead you expect a full compromise then you need to store the credentials on a different system. But it will be hard to make the script then make automatically use these remote credentials. It might be possible to automatically feed the credentials from remote into your application but how this is done depends on your specific environment and use case.


Is is safe to skip virus scanning for image files?

Are there any good reasons not to ignore the scanning of .jpg and .png files to reduce the load on the scanner?

One reason is that if you ignore certain files based on their file extension (e.g., ".jpg" or ".png") then attackers can upload malicious files of any type as long they just change the file extension (e.g., replace ".exe" with ".jpg").


I'd recommend looking at something like Burp suite's intruder feature for this. that can easily create a variety of URLs from a base, and includes preset lists.

Another option would be to look at OWASP ZAP which is a similar application.


What encryption is applied on a key generated by `openssl req`?

What encryption is applied by openssl req when a config is specified?

Grepping through the source code it seems to me, that it's either triple DES or nothing. (Regardless of anything that may have been configured in your configuration file.)

$ git log apps/req.c | head -n3
commit f1cece554ddf282f1512b4da04664467746ffd24
Author: Richard Levitte <levitte@openssl.org>
Date:   Tue Jul 7 11:13:20 2015 +0200

$ grep -n -C1 cipher apps/req.c
197-    X509_REQ *req = NULL;
198:    const EVP_CIPHER *cipher = NULL;
199-    const EVP_MD *md_alg = NULL, *digest = NULL;
--
216-#ifndef OPENSSL_NO_DES
217:    cipher = EVP_des_ede3_cbc();
218-#endif
--
590-        if ((p != NULL) && (strcmp(p, "no") == 0))
591:            cipher = NULL;
592-        if (nodes)
593:            cipher = NULL;
594-
--
597-        assert(private);
598:        if (!PEM_write_bio_PrivateKey(out, pkey, cipher,
599-                                      NULL, 0, NULL, passout)) {

  Can the algorithm be controlled?

Nope. See above.

  How does openssl rsa guess the right cipher for decryption? It must obviously be encoded somewhere in the data...

Yes. It's in the file. The file itself is an ASN.1 file. You can use OpenSSL to parse it.

$ openssl asn1parse -in keyviareqnewkeycommand.pem -i | cut -c-90
    0:d=0  hl=4 l=1294 cons: SEQUENCE
    4:d=1  hl=2 l=  64 cons:  SEQUENCE
    6:d=2  hl=2 l=   9 prim:   OBJECT            :PBES2
   17:d=2  hl=2 l=  51 cons:   SEQUENCE
   19:d=3  hl=2 l=  27 cons:    SEQUENCE
   21:d=4  hl=2 l=   9 prim:     OBJECT            :PBKDF2
   32:d=4  hl=2 l=  14 cons:     SEQUENCE
   34:d=5  hl=2 l=   8 prim:      OCTET STRING      [HEX DUMP]:D48091CF79B0E2D2
   44:d=5  hl=2 l=   2 prim:      INTEGER           :0800
   48:d=3  hl=2 l=  20 cons:    SEQUENCE
   50:d=4  hl=2 l=   8 prim:     OBJECT            :des-ede3-cbc
   60:d=4  hl=2 l=   8 prim:     OCTET STRING      [HEX DUMP]:EEF03DDF397E19DB
   70:d=1  hl=4 l=1224 prim:  OCTET STRING      [HEX DUMP]:A8DACADF4BABA008CF155C960FD112C

Now PBKDF2 is the key stretching/key derivation algorithm and des-ede3-cbc is the encryption algorithm.


Any campus email systems automatically testing links?

In theory this should not happen.

But for short periods I can see it happening, in certain not carefully tested systems.

The http standard includes the following actions, HEAD, GET, POST, DELETE and a url can use any of these.

The default GET is what we are talking about here, and GET requests should not actually action anything. Theory being a GET should retrieve the resource, not changing it in the process.

Of course this is not in practice followed, such as these common unsubscribe links.

So in practice urls should not be retrieved by GET without user action except in certain exceptional cases.

Even using the HEAD action may impose security concerns such as unequivocally identifying a valid email address.

Example

Google had a pre-caching service at one point (VPN or Browser or something) that prerequested website urls to improve performance/bandwidth.
This caused certain web-apps to malfunction in similar ways to the Question.

For instance I developed a web-app around 2000 that used GET urls to do actions such as delete record an so forth, not a mistake I would repeat of course.

This pre-caching service looked at the urls and web site and inferred that it should NOT pre-cache certain links using a heuristic with inputs such as is this an authenticated site, is it https, is the url containing the string DELETE or UPDATE etc or identifying the web framework used for the site.

I dont know how accurate the heuristic was, I heard of some issues raised in this system but I dont know the detail.

Because this is a easy mistake to make on any web site (beware web coders) be very careful of implementing this feature.


Why would a website want to know what operating system you are using?

One obvious answer is when the website contains applications that you can download - it can then offer the content appropriate for your operating system. If I go to www.videolan.org with Javascript turned off, the download link goes to the Windows binary, but if I turn Javascript on, it goes to the appropriate binary for the system I'm actually using.


Is it normal that my new VISA debit card has almost the same number as the old one? Is it secure?

Almost the same -> they are different.

And there is some procedure on how those number are generated: the issuer has some code, the bank usually have some code, etc. You can take a look at this site.

If you ask two credit cards from the same issuer, same bank, you'll see that there are lots of numbers in common.

And even some cards have the same number, reissued, when they expire. So, you have received the same number again.


How to make Firefox ignore the X-XSS-Protection response header?

This question is old and was answered in the comments, maybe it is time to close it. The answers to your questions should be:

Quoting Neil McGuigan, "Firefox doesn't have an XSS filter like Chrome and IE do, therefore it already ignores that header" (link). In the meantime also Chromium removed their XSS Auditor (link).

Being there no such thing as XSS protection, you probably refer to automatic URL encoding, which is mandatory and cannot be disabled:

"All unsafe characters must always be encoded within a URL" (RFC
1738)
"The URI producer will transform the local encoding to one that is
suitable for a public interface and then transform the public
interface encoding into the restricted set of URI characters
(reserved, unreserved, and percent-encodings)" (RFC 3986)


Sending session cookie inside the HTTP response body

Setting cookies in the body

You cannot set cookies in the response body (browsers don't look there for cookies), nor can your browser present cookies in the request body (the server won't look there).  Cookies by definition are carried in the HTTP header (see RFC 6265).

Putting secure data in the body

You can certainly send other session data or tokens in the request or response body (e.g. it is common to pass a CSRF token in the body), but if you do so they are not cookies. Whether this is a good idea is a different question.

Most data is OK in the body, after all that is the only part that the user can see and sometimes the user needs to be shown sensitive data.

However, some data is not OK in the body.  Anything that you wish to make unavailable to an XSS attack, for example, must not be in the body, and should only be contained in an Http-only cookie so that it cannot be read from the DOM.

That being said, some data is better off in the body!  For example, anything that you don't want to show up default IIS logs should be placed in the body.  Anything you do not want included in a session riding forged request (a.k.a. CSRF) should be included in the body and not as a cookie.

Setting data in both

It is not necessarily a security problem to set a token in both a cookie and the body.  In fact this is exactly the pattern required by the Double Submit Cookie CSRF mitigation.

On the other hand, if you are just passing the session ID in the body for the heck of it, and it is a duplicate of an HttpOnly cookie, then you have just nullified any benefit of using the HttpOnly flag, since the same value can be read from the DOM.

Also, here's something really fun: If the site sets an HttpOnly cookie from the server side, and the same cookie value is passed via the page body and set via client script, your browser will end up with two cookies with the same name!  This condition should be avoided because there is no HTTP specification that states which cookie should be presented in this case, and browser behavior will vary.


What security exposure (if any) can result from lots of apparently odd referrers in server log

There is a thing called Referer spam, of which your case may be an instance.

Alternatively, the requests may be part of some sort of automated crawling and testing for possible vulnerabilities, and the attacker includes random HTTP referer header values as a way to make the requests look more "genuine" and thus bypass some basic intrusion detection systems. When you have a server online, you soon get lots of very stupid requests from mindless botnets which look for new hosts to infect, and can afford to try random IP addresses blindly with attack attempts which work on only one in a million machines (botnets are patient).

Best thing to do is to ignore them. The real problem with such requests is that they reduce the usefulness of logs, and may make you miss some important clues about more targeted and dangerous attacks.


Is 2FA a false sense of extra security on a mobile phone?

No, it’s not as insecure as 1FA. 2FA is about making life inconvenient for an attacker, not for yourself. With 1FA, anyone anywhere in the world can access your bank account if your username and password leak or can be guessed. 2FA means that the attacker has to have your phone, or another way to access your text messages if your second factor is SMS (which is deprecated). It’s true that you should avoid storing your first and second factors in the same place where possible, but even if you don’t do that, it’s still far more secure than 1FA.


Secure encryption algorithm with decryption key per user

Alice encrypts each file (F1, F2, ...) with a unique, randomly generated AES-256 key.  When Bob pays Alice for access to F1, she encrypts the AES key for file F1 with Bob's public key.  Bob can now decrypt the AES key, recover the key to F1, and view the file.


Do you need to update a router that is set in bridge mode?

You neeed to keep up today any software device, so if your router contains software is a good idea to keep the software update to the latest version in order to get fix issues on it.


Where is the salt on the OpenSSL AES encryption?

Yes, a transformation occurred: endianness...

Look at the bytes 8 to 15: 7ead 14f8 3192 3f2b. That's your salt. It is a known quirk of od: it decodes data by 16-bit units, little-endian, then shows them "numerically", so this incurs an apparent byte swap.

Use od -t x1 to get a nicer output.

Edit: to answer your other question, what OpenSSL does is neither standard nor common practice; it is just "what OpenSSL has always done". It is not well documented.


How To give someone a shell in my local net without security risks?

... give someone a shell in my local net without security risks?

Dont

Instead of attempting to restrict shell access of this user I would recommend a completely different approach.

Purchase a second router
plug the internet of the new router to reg port of your existing router
port-forward port 22 from existing router to new router
port-forward port 22 from new router to server
setup SSH access for this un-trusted user on the server
restrict the server to twitter / developer / your external ip via the new router

this method is much safer / more reliable than a reverse shell
this method allows the developer to use your external connection without having access to anything on your network (as long as he isnt able to exploit the new-router ... and you can monitor his traffic to make sure he isnt attempting to hack it)
this method doesn't require any standing on head while patting belling to lock down a development environment while still allowing developer to do his job.

That being said, if you have existing stuff on the server that you want to protect from this user ... I would do a full clone of the server's hard-drive before letting them have access ... and then wipe it and restore from backup once they are done.

Physical access is root access, and while you are not technically giving this developer physical access ... shell access is pretty close to the same thing.  If a hacker obtains shell access to an unprivileged user ... its common practice to nuke from orbit ... only way to be sure.


What are the security implications if someone got my home WiFi network password?

Giving the WiFi password away effectively gives full access to the local network. From there the guest might access the other computers inside the same network unless they have an additional protection. The guest can also try to brute force the router password, can mount man in the middle attacks with ARP or DHCP spoofing ....

Because of this better routers offer a separate guest WiFi with its own password and with a restricted environment where the user can only access the internet but not the internal network.


John The Ripper 'No password hashes loaded'

Your hash is base64 coded. You must decode this before use john.
You can use the command :

base64 -d <hash>

If you want to be sure of the hash format, you can use :

hash-identifier


Secure way to grant access to WIFI network based on dynamic parameters?

You can use WPA-Enterprise with a RADIUS Server for authentication. If you want to implement these exotic methods you mentioned, look for existing RADIUS policies that fit your needs or write your own.
http://freeradius.org/features/policy.html


Is there a way to access the local DB from external webapp?

It depends...

Assuming the web server has access to the DB in the backend you could look for other vulnerabilities in the web application that allows RCE or even SSRF where you can further utilize the credentials you found.

See this for an example of how debug mode on Django was used to achieve RCE and extend access to other systems.

In case of RCE and SSRF you are executing commands as if you are the web server hence you inherit the connectivity of the web server which implies that you need to be able to communicate with the backend DB or other systems on the LAN not directly exposed to the public internet.

If you have mandate to look for issues on this application, I would certainly not stop there and neither would a good bug bounty hunter.


Difference between Secure Simple Pairing and Secure Connections in Bluetooth?

Most answers to your questions are given in the spec Bluetooth Core, VOL1.PartA.5

Timeline

The following suites exist:

BR/EDR

Prior to version 2.1 => BR/EDR legacy
Version 2.1 => BR/EDR (uses Secure Simple Pairing)
Version 4.2 => BR/EDR (uses Secure Connections)

LE

Version 4.0 and 4.1 => LE legacy (uses Secure Simple Pairing)
Version 4.2 => LE (uses Secure Connections)

Legacy

It all started with the initial security algorithms (BR/EDR legacy) for the following security features:

pairing
bonding
device authentication
message encryption
message integrity

The algorithms used in BR/EDR legacy were not FIPS approved.

Secure Simple Pairing

This was introduced in version 2.1. Secure Simple Pairing uses FIPS-approved algorithms for pairing and message integrity and so in essence it upgraded the security of BR/EDR legacy, which is why we call this new one BR/EDR security.

Version 4.0 ported the exact same security model as BR/EDR to Low Energy (LE), with the following exceptions:

no Numeric Comparison equivalent
Just Works and Passkey Entry do not provide passive eavesdropping protection, because ECDH is not used in LE 4.0.

Secure Connections

In version 4.1, the Secure Connections feature was added to BR/EDR. This was an upgrade to the existing Secure Simple Pairing algorithms for pairing, device authentication, and message integrity. See table for a comparison with the Simple Pairing method for BR/EDR (not LE!):

Version 4.2 then upgraded LE as well. One of the main improvements was the adoption of ECDH for pairing. It also modified the Numeric Comparison association model to be used on Bluetooth LE. LE pairing used in 4.0 and 4.1 is since then referred to as LE Legacy.  LE Secure Connections and BR/EDR Secure Connections are functionally equal.

One last word on the association methods

Numeric Comparison protects against passive and active attacks;
Just works protects against passive attacks IF ECDH is used, and never protects against active attacks;
Passkey entry protects against passive attacks IF ECDH is used, and should protect against an active MITM attack (although there are some doubts about that, e.g. Padovan .
Out Of Band security depends on the OOB method that is used.


How will popular WiFi clients react to an evil twin

In large wireless network setups, numerous access points will broadcast the same SSID and will appear as only one SSID on the client device. For example, some large lecture halls at my university have over 15 access points in them which are broadcasting the same SSID. Even though the BSSID of each device differs, the client still groups by SSID.


How to make SQL injection in PostgreSQL's tsquery?

Looking here which sounds pretty similar to what you're seeing, this isn't straight up SQL injection but rather an injection into the query language used in tsquery.  Also from the examples that may have been in a similar [closed] question, there was some oddness that didn't strike me as being a standard SQL Injection issue.

So not to say that it's not exploitable in some fashion, but that standard SQL Injection techniques are unlikely to produce useful results.


From Detecting TOR Communication in Network Traffic:

  A successful method for detecting Tor traffic is to instead utilize statistical analysis of the communication protocol in order to tell different SSL implementations apart. One of the very few tools that has support for protocol identification via statistical analysis is CapLoader.

Clearly, this is a difficult task and probably not altogether reliable.

There is, however, a public list of Tor Exit Nodes. Which may help! Others have also noted that many exit nodes identify themselves with a Tor related name. More information is available in a previous answer "Detecting Tor proxy by reading request headers".


How do I use a smart phone as an authenticator in the new Web Authentication specification?

According to the (non-normative) introduction:

  Other authenticators MAY operate autonomously from the computing device running the user agent, and be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE) or Near Field Communications (NFC).

So the client (browser) communicates with the authenticator (smartphone) using USB, BLE, or NFC using the Client to Authenticator Protocol (CTAP).

I'm not aware of any smartphone authenticator implementations as of yet, and no current browsers support connecting to an authenticator over BLE or NFC. This indicates bluetooth support was planned for Chrome 68, but I haven't seen any more recent mention of it.

Update: As noted here, Chrome 72 includes BLE support for authenticators that can be enabled by a flag.


Unusual design aspects of AWS HMAC-based authentication, v4

I could not find any suitable HMAC libraries

Err, the standard library has one. So does the cryptography library.

  Question 1: Why does AWS use a complex signing key (produced via HMAC) instead of the shared secret itself?

One good reason I can see for doing it this way is to avoid a leaked signing key compromising the entire AWS account. Deriving a signing key from a combination of the secret key, region, a specific service and other values ensures that different things use different signing keys.

  Question 2: I do not understand the purpose of the 'credential scope' string.

The "credential scope value" (20110909/us-east-1/iam/aws4_request\n) probably helps Amazon to assert that a particular request is targeted at the region and service. I don't see why the date is included so many times but it may have just been an oversight when Amazon is designing the process.


Encrypt user data when they log in with Facebook, Gmail, etc

You are asking to generate secret data from a single, non-secret source. It can't be done under those exact conditions. You need a 'source of secrecy'. You can try to squirrel a key away in a config file, perhaps encrypted with yet another key, or you can move some aspect to a different, secure machine, such as using a Hardware Security Module (HSM) to host your encryption and keys. But you cannot create a re-creatable secret out of a finite set of data and expect an attacker to not be able to replicate your feat.


Does TLS always use the same algorithms for both directions?

The cipher used is the same in both directions and thus the encryption algorithm is the same too. In detail: the client proposes some ciphers it is willing to use and the server picks one of these ciphers and sends it back to the client.


Bypass MAC address internet time filtering?

You can defeat your brother's access restrictions, either by a timing-attack or side-channel attack.

In a timing-attack, you wait for a sufficient time, your brother will remove the MAC filtering for your device.

If you cannot wait for the time-based attack to succeed, you can use a side channel attack and connect to the internet via an alternative channel, such as GSM or a friendly neighbor.

Joke aside, MAC spoofing is a way to overcome MAC filtering. Since MAC-filtering is (usually) only tied to the MAC-address assigned to a network interface controller, you can change your MAC-address to match the one of an unfiltered device. This is a relatively easy process, but can cause harm (Denial of Service), depending on network equipment and configuration.

On wired networks, switches are usually only designed to forward traffic destined MAC-address to one port. If multiple ports have the same MAC-address, the network logs might contain warnings of MAC-flapping and alert the administrator. This blog post demonstrate how the network can become unreliable for devices that share the same MAC-address.

On wireless networks, sharing the same MAC-address usually do not lead to the same problems as on a wired network. The reason for this is that the wireless network is a single network port (a single radio interface) with multiple connected devices. There are no alternative ports for packets to take as long as both devices are connected to the same access point over WiFi.

Sometimes, you also have to clone the IP-address of an unfiltered device (this is also dependent on the network devices that handle MAC-addresses). This can lead to another set of problems:

If your network adapter is set to DHCP, you might be issued the same IP-address as your target device.
You and the target device can get visual warnings about IP-address conflict.
Your and the target device might drop connections that belong to the other.

If possible, try to use statically configure the adapter to use an unused IP-address. If you absolutely have to also spoof the IP-address, wait for the device to disconnect from the network. There is a tool called CPScam that is used to bypass captive portals (which most commonly use MAC-filtering). This tool will monitor the network for active devices, and alert you whenever a device leaves the network. If you impersonate a device that is no longer on the network, it should not cause harm or alarms, at least not until it reconnects.


Are there any sequences other than ../ which will be intepreted as directory traversal in *nix or Windows?

Utilizing Unicode, it's possible to encode \ and / into multi-byte characters. If the string comparison functions are not unicode-aware, there could be a bug which allows these characters through.
Wikipedia has a section on this in relation to an old attack on Windows servers:

When Microsoft added Unicode support to their Web server, a new way of encoding ../ was introduced into their code, causing their attempts at directory traversal prevention to be circumvented.
Multiple percent encodings, such as

%c1%1c
%c0%af

translated into / or \ characters.

Technically this is still using the slash character when it comes to the directory traversal, it's just not the true single-byte character which may confuse some code.
I believe the best advice for avoiding such characters would be to disallow any characters for file system paths except a safe subset of ASCII characters. You can also sidestep other issues of allowed characters in some operating systems and file systems at the same time.


OS fingerprinting protection - why not by default?

OSes respond to invalid packets because that is very helpful in diagnosing network configuration problems. If you send a packet and nobody answers, you have no idea what happened to the packet: did some router eat it? Was its reply misrouted? Is there a connectivity problem? Or did the target receive the packet but not like it? If the target replies, you know why the packet was rejected, and you get a serious chance of being able to fix the problem.

OS fingerprinting is not a security issue. It's helpful for finding vulnerabilities, but only on systems with unpatched security holes. If you have a system with unpatched security holes, patch them: making your system unrecognizable by fingerprinting will only protect you against a small proportion of automated scans that need to optimize for bandwidth.

OS fingerprinting is a small privacy issue. It's not a major one: most people don't care, for good reason.

Furthermore, eliminating one method of fingerprinting isn't enough: you have to eliminate all methods. So your anti-fingerprinting protection is only good until someone tries another fingerprinting method.

The benefit is small and uncertain. The drawback is major. OS fingerprinting protection should default off.


You slightly missed the point of the video. Its main message is not "Javascript is dangerous" it is "Anonymous proxy servers are dangerous!"

The attack in the video you posted is mostly based on getting the target to use a malicious proxy server. Using a proxy server is a conscious choice the user makes, and using a proxy which is not trustworthy is a very bad idea. A proxy server is able to eavesdrop and manipulate anything you read (or post) on the web. That also gives them the ability to inject Javascript code into websites and monitor your activity on them.

When you want to be safe from the attack presented in that video, don't use any proxy servers not operated by someon you trust, that simple.

But let's get on your actual question: "Is Javascript dangerous per-se?"

When the browsers javascript engine works as designed, then Javascript is pretty safe. Conceptually, Javascript is not able to access any other tabs except the one it is embedded in. Persistent javascript which runs after the tab is closed is also impossible.

However, all browsers had bugs in the past which could be exploited to override some of these restrictions under some circumstances.

Regarding whether or not using NoScript is an option: NoScript can protect you from some browser-based exploits, but not all. There are a lot of other exploits which target other sub-systems of the browser. The main motivation to use NoScript is to protect your sanity from websites which abuse Javascript for inversive advertising or other annoyances.


Is jQuery 2.1.1 vulnerable to OS command injection?

It's a false positive.

In both cases, the scanner only searched for "root:", assuming it is part of a passwd file. The line that is found is:

root:function(a){return a===o}

This is obviously not from a passwd file. It is also very unlikely that any server-side vulnerability exists in a request for a jQuery file, generally they are static files that are served as-is.

That the scanner reports "certain" is a bit surprising, as "root:" is way too general of a keyword for such a high confidence rating.

When getting a report such as this, you need to verify the result. In these cases, you should:

search for the keyword the scanner gives you - "root:" in this case - and see if it actually is what the scanner thinks it is.
adapt the payload and see what happens. In the case of the command injection, you could try other commands and see if they are executed, in the case of the file inclusion you should try to include other files.


Individual public keys for embedded devices?

Programming devices with unique keys is pretty common, even for low-end microcontroller. It isn't available for every single device, and it has an impact on the manufacturing costs (every fraction of a second on the assembly line counts), but it's an incremental surcharge, not a whole other price bracket.

However, I don't see the point of programming devices with a unique public key. What's the point? You can burn the same public key in a whole series of devices. The only point of having different public keys would be if the corresponding private keys were on different servers.

The primary reason people put unique keys in devices is to authenticate data coming from the device. This requires a private key in the device, with a server holding all the devices' public keys.

If you want data confidentiality, and you're prepared to have a unique key in each device, you might as well save on computing power and inject a secret key and use symmetric encryption. Under most threat models, if the device's secret key is compromised, the data sent by the device is also compromised anyway, so there's no advantage in using public-key encryption.

For authenticity, on the other hand, don't use symmetric keys if you can possibly avoid it. Here asymmetric cryptography has a major benefit, which is that a breached server is harmless (with respect to data authenticity), since the server only needs to have public keys.

Whatever you do, never use “class keys”: never inject the same secret/private key into a whole class of devices. If you do that, then breaching a single device gives the attacker access to all the devices. If it costs $1000 to breach one device and the expected gain is $1 per device, nobody will do it if breaching that one device only gives access to that device, but it becomes worthwhile if breaching one device gives access to 100000 of them.


UDP amplification: length(response_packet) < length(request_packet)

If the request packet are larger than the response packets, you (as the attacker) would have been better off just sending the packets directly to the target.

It's also worth thinking about where you can find those amounts of bandwidth. If you're doing a direct (as in not reflected) attack you will need as much bandwidth in your end as you want to hit the target. So if you want to hit a target with X Gb/s you need to control devices with a total bandwidth of X Gb/s - and be able to fully utilise those links.
But when reflecting the traffic, you only need X/, that might be a lot easier to acquire, and you only need to be able to make a device send a e.g. NTP packet with a spoofed sender, probably a lot easier to acquire.


The compiler itself is irrelevant; the rand() function is implemented in libc.

The glibc implementation uses a linear congruential generator (LCG) or a linear feedback shift register (LFSR) for its rand(). These can be quite easily cracked given some of the outputs (which it seems you have). The details can be found in the answer to another question already asked here, but the crux is that LCGs and LFSRs are not secure and some simple maths and probability can gain you the right answer pretty quickly.

You'll need to work out which version of glibc was used, but the compiler version should give you a rough idea of the patch state of the system, so you can infer it from that.

You can find more resources on Google, but here's a quick set of links to help:

LCGs on Wikipedia
LFSRs on Wikipedia
Cracking PHP's rand() [PDF] - relevant because it uses the glibc function for rand(), and this is covered in the paper.
Untwister - PRNG seed recovery tool with support for rand()
Snowflake - Another PRNG seed recovery tool


Currently a TLS handshake needs at least 2 round trips for the full handshake or one round trip for resuming a previously established session. This means there is currently always round trip overhead with TLS which can heavily impact the connection setup if you have a large round trip time, as it seems to be in your case.

With the new TLS 1.3 this overhead will be greatly reduced up to a 0-RTT handshake if resuming a session. Currently TLS 1.3 is still not fully standardized yet (will be hopefully this year) and even after it is standardized it will probably take several years before it is supported by the majority of client and servers. But, if you need a 0-RTT protocol now and have full control over client and server, then you might start using TLS 1.3 already in your own environment. Even if it is not fully standardized yet it is probably better than designing your own protocol.

For more details see An overview of TLS 1.3 and Q&A which describes both TLS 1.2 handshakes and TLS 1.3 handshakes.


Web browser security comparison analysis

The trouble is that unfortunately there really isn't really any straightforward, objective, useful numeric measure of how "secure" one browser is compared to another. Or, really, how secure one piece of software is compared to another more generally.

Want to compare gross vulnerabilities reported & fixed during some period of time? Well, as the commenters pointed out there are several reasons you actually might not want to use total vulnerabilities as a representative measure of the practical security of a browser. Which means that comparing that number for one browser to that number for another is even more problematic. (For example, comparing Chrome's number of reported/fixed vulnerabilities to any other browser's.)

Well then, what about the number of vulnerabilities successfully exploited in the wild over some length of time.  Well, that's perhaps a less-bad measure than total vulnerabilities in some ways, but it still has substantial problems that make it quite flawed as a basis for comparison. Browser A may have more exploited vulnerabilities than Browser B, but what if that's because Browser A garnered more attention from the security researchers, criminals, and/or nation-states who created exploits for vulnerabilities than Browser B did?  Which, in turn, could be due to any number of reasons not related a browser's "inherent" security or lack thereof. (A real world example: it's likely true that one reason IE has historically drawn more exploitation attention than Firefox is because it is more heavily used within corporate and governmental sectors, which , of course, is where the greatest number of systems that are most attractive for attackers generally are.)

Or you could look at, say, the number of in-the-wild zero-day exploits (ie. vulnerabilities that became known & exploited before a vendor could issue a patch) that bedeviled a browser over a certain timeframe. But that measure has issues similar to those just discussed.  And do you count exploits that allowed breach of a browser's site-rendering element but don't allow escape from that browser's sandbox?

Or you could look at...

But I think you're getting my point. There really isn't any one number that really captures a browser's susceptibility to compromise well or allows good comparisons on that basis.  Which is essentially what an effort to compare announced vulnerabilities is trying to get at.

So, does that mean we simply can't compare security among browsers at all?  No, I certainly wouldn't go that far. There are points of comparison that, if more abstract than numerical measures, are valuable. For instance, IMHO the architectural & defense-in-depth attributes of some browsers give them some significant advantages in security over others. (Though we mustn't forget that how a browser is configured and used is perhaps an even more important factor than the software's security architecture.). But straight numbers vs. numbers comparisons can be quite misleading.


Weird character sequence in email subject

Ah, the character sequence is legitimately used to encode UTF-8 characters in internet headers, since they can contain only ASCII (rfc1342). Here however, is used to hide from spam filters, as Ghedipunk said in a comment.


If we trust browsers that they satisfy Same Origin Policy without bugs, would we still need CSRF-tokens?

Yes, we will. Due to the fact that there are other requests that don't fall under SOP like form submit, loading scripts..etc

  Assuming server doesn't have CORS enabled: As far as I know we are not allowed to do POST requests cross-origin, then why is there a CSRF token?

Even when CORS is disabled, the browser will complete XHR POST requests, the attacker won't be able to access the response, but the request will be completed and a he will successfully accomplish the CSRF attack.
This, however, will fail in case of PUT , PATCH and DELETE requests since the browser will first issue an OPTIONS request to the request endpoint to verify the request.

  If server has CORS enabled: (assuming both GET and POST, because I don't see the point of CORSing POST but not GET)
  We could GET the page, read the token and POST a correct request.

This would be a vulnerability with the server itself. CORS should not be open to all remote hosts, only the ones you own (trust).


Private ip address revealed by nginx, should I worry?

It is but information leaking. So on its own and at face value, don't worry about it*.

On its own it's not something that could be turned into an attack. It is, however, information that an attacker could use to leverage other vectors.

On the other hand, it's normally not at all difficult to mitigate, so best to pick up a few resources and start trying to omit this information;

(*) some auditors might disagree to this conclusion;


Can I store a pair of keys on iOS secure element?

You can do this by setting kSecAttrTokenID to kSecAttrTokenIDSecureEnclave when generating the key. According to the documentation (which consists of some comments in SecItem.h), the only kinds of keys the secure enclave can store are elliptic curve secp256r1 keys. You can't put RSA keys there, for example.


Secure SSL Session from losing itself into unsecure http

Basic rules for SSL protection for a website

  How would a secure implementations look like and where can one expect problems?

These rules are intended to provide SSL protection, that is protection against an opponent that can intercept and alter packets.

Subcomponents

  You probably into mixed mode in some scenarios

If, in a HTTPS page, you load any script, or CSS resource in plain http, that nullifies the SSL benefit (not just reduce).

As a rule, in a HTTPS page, load every subcomponents (frames, scripts, styles, images) over HTTPS, from trustworthy hosts.

Cookies

A particularly unfortunate mistake is to forget to make all cookies "secure". If you forget to mark all security relevant cookies with this attribute, it nullifies the SSL security. (Obviously a login/session cookie is security sensitive.)

As you want your website to be entirely over HTTPS, mark all cookies "secure".

One problem is that even "secure" cookies can be replaced by cookies HTTP non-secure cookies! What makes it even worse is that the browser will not even tell you if the cookie came from HTTP or HTTPS!

You can assume that a secure cookie cannot be read by an opponent. But you cannot assume that a cookie sent by a browser over HTTPS is the secure cookie you sent previously.

Whole site SSL protection

By providing content over HTTPS not just for some "sensitive" pages, but for the whole site, you will train users to only use your site over HTTPS which is quite good for security.

In order for users to be able to enter an HTTP URL, you will certainly do an HTTP redirect from HTTP to HTTPS, so that the only non-encrypted HTTP traffic is a HTTP redirect (in the usual, no attack, case).

The problem here is that if users get used to type the HTTP URL, and they might fail to check every time that they are properly redirected to the corresponding HTTPS site: an attacker that can intercept and modify packets can alter the HTTP request to redirect to another misleading HTTPS site, or just assume that the user doesn't usually doesn't detect the HTTP/HTTPS difference: this is a good reason to use HSTS.

Other website security principles

The SSL cryptographic protection is an essential part of website security, especially to protect the secrecy of passwords. But it isn't the end of the security requirements that are specific to websites.

Just as a reminder, some other essential security principles:

Safe handling of untrusted data

When taking user input and outputting it in web page, you must apply proper escaping to avoid XSS vulnerabilities. For this, you must understand that different parts of the HTML page have different syntax (normal HTML, attribute value, URL have completely different syntaxes) and thus need different escaping.

As in any other program taking external untrusted input, you must properly validate every input, and store and output it in a way that does not misbehaved if an unusual character is present (see: SQL injection).

Verification of authorisation on the web

You cannot only rely on cookies (or HTTP authentication) to validate that a specific order from a HTTP client is authorised: doing so would expose your website to a CSS attack from another website if the user browse both websites in the same browser.

My view of secure design

The problem with website security is often caused either by not understanding the different specific requirements of these web protocols, or by securing all but one "entry point".

Before you even to design a "secure" website, you should understand all these requirements; then you should apply them in a systematic way. Your design should be simple, regular, understandable, and easy to audit.

The best style is one where you just cannot forget to apply to escape text that is going to be interpreted as HTML/HTML attribute/SQL/SQL "regexp"/shell commands/shell regexp. The best approach, when possible, is to prevent variable data that is not intended to be interpreted as HTML/HTML attribute/SQL/SQL "wildcard expr"/shell commands/shell regexp to appear in such context that it requires escaping: avoiding need to escape is safer because you cannot forget to escape things.

I know that I am drifting off topic here... so I will stop now. I just wanted to it clear that HTTP security doesn't stop at "100 % over SSL".


PGP key on smart card: why do I need a "secret key" on disk?

This is not actually the secret key, but a kind of stub referencing the one on your card. This stub contains pretty much all "metadata" of your private key (including the public key belonging to it), but the actual private key is only stored on your card (and never leaves it).

This is important, as the card only stores the actual key (and performs basic cryptographic operations with those), but not other meta information like creation date, usage flags, user IDs etc.

(Reading up the specifications again, I realized this was wrong. The cards store the key's fingerprint and creation time.)

This key stub helps GnuPG managing the keys, and lets it look for a card / ask for the card if necessary. As the fingerprint of the public key is stored on the card, the private "stub" key can be easily regenerated if the public key is available. GnuPG makes this easy by running the fetch command in the --card-edit menu, which queries the key server network for the public key.


Is it possible to use the Linux "echo" command maliciously?

Yes. You can use echo maliciously. You can use > operator to redirect the output to a file where the output can be a malicious code.

echo 'Malicious_code_here' > shell.php

Lets consider a case where the webserver supports PHP and the www directory is writable. you can try something like:

echo '<?php system($_GET["cmd"]);?>' > shell.php

And you can access the shell by:

http://url_of_the_website/shell.php?cmd=whoami

Using this, you can execute arbitrary commands on the webserver.


HeartBleed - How to detect compromised websites

As an end user, not easily, unless an attacker brags about it or a site owner discovers it, you can't tell what's actually been lost.

For the technically adept, anyone (end user or site operator) running Snort or another IDS/IPS can look for indicators of realtime compromise in Snort rule form, as the attack can go both ways (your client can be attacked, too, if it's vulnerable).  This doesn't tell you if someone else has attacked the website in the past, but it might tell you if someone's attacking you right now.

alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - SSLv3 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 00|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000000; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 01|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000001; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 02|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000002; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.2 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 03|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000003; rev:4;)

Site owners might detect compromises on a site that was recording a full packet sniffer trace, and was actually able to inspect the response sizes of heartbeat requests; other than that, it's very difficult to detect after the fact.

Other possible ways for site owners to detect it would be traffic analysis - having sent too many outbound responses of just over 64KB would be a warning sign, for instance.

Right now, though, there are several Heartbleed vulnerability detectors/checkers that I'll list for the community.

Qualys SSL Labs is more or less the canonical free SSL test site; they added an experimental Heartbleed test hours ago (and set the security grade to F for every site that's found to be vulnerable.

titanous on github appears to still be under active development, and titanous also released Go programming code for Heartbleed detection, had better messages than Filippo as of this morning, and was last updated 32 minutes ago.  It appears to be under the Go license, though I didn't do a full comparison; similar to a BSD 3 clause license.

Filippo.io was one of the first Web sites, and they released their code on github with an MIT license (Go programming language), and was last updated 4 hours ago.

musalbas on github released the Python program "ssltest.py" about 10 hours ago that can do mass/bulk tests in only 178 lines (including a few comments), no license listed.  Musalbas also released lists of the results of scanning the top 100, 1000, 10000, and 1 million Internet sites as of about 7 hours ago.  This is a variant of Stafford's code.

possible.lv is another web site that does Heartbleed vulnerability scans.

Codenomicon Defensics appears to do detect Heartbleed as well.

@Lekensteyn released the pacemaker python client checker, modified a few hours ago, as well as the original Stafford version of ssltest.py.  No specific license is listed.

Metasploit is also gaining Heartbleed tests very rapidly, including both the server check linked here and a client check from @HDMoore and @Lekensteyn.

Per @DrJimBob, the LastPass Heartbleed checker is a very nice setup for a Web checker; in particular, it also checks the SSL cert!  Output looks like this:

Site:   security.stackexchange.com
Server software:    Not reported
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate:    Possibly Unsafe (created 9 months ago at Jul 2 00:00:00 2013 GMT)
Assessment: Wait for the site to update before changing your password


How to dynamically generate the hash value of a file while it gets downloaded from any website?

Agreed with vidarlo, this is impossible.

Ultimately, you'll need to download the file, in order to determine its hash. What you're asking is to determine the hash of a file before downloading it!

What is possible is a script that hashes each file in your downloads directory and then perform some action depending on the hash matching. The script could be scheduled to run every 10 minutes or so.

It's hard to make a recommendation, since we have no idea what it is you're trying to accomplish by blacklisting a specific file.


Can network with two data diodes (incoming and outcoming) still be safe?

There are several use cases for data diodes and it is unclear what your use case exactly is and if data diodes are the solution for your unknown problem. But my guess is that data diodes are not what you actually need and that your current idea of how to use data diodes does not provide the security you envision:

One use case of data diodes is to make sure that data can only leave a system but never enter a system. This is for example used to get logging data out of industry systems but stop any data flow into the industry systems so that they cannot be attacked.
The other use case is to make sure that data can only enter a system but never leave it. This is for example used to feed data collected by a lower security environment into a system which contains very sensitive data and guarantee that no sensitive data can ever leak into the lower security environment, even in case of bugs or vulnerabilities.

Your use case is none of these.  Instead it looks like you want feed some data from outside into some service and get a response back, but still protect the service from being hacked from the outside. This bidirectional communication is not the use case for the unidirectional data diode. And by simply combining two data diodes you essentially allow (mostly unrestricted) bidirectional communication and thus do not protect the service.

What you probably would need instead is an application protocol level gateway, i.e. a system which allows restricted bidirectional communication. If properly enforcing the syntax and the semantics of the communication protocol, such gateway can make sure that the service gets only data which it can handle in a safe way and that only data leave the service which adhere to the defined syntax and semantics of the protocol - which severely limits both how the attacker could compromise the service and how he could make use of a successful compromise.


How hard is it to break an 8 digit pin of AES 256 encrypted external sata enclosure?

It doesn't matter. If these devices make any sense at all (and use the built-in encryption that modern SSDs and hard drives have):

The device's decryption key is stored within a microcontroller that simply will delete the key if you tried wrong PINs too often.

In other words: although it might maybe only take thousandth of a second to try one PIN, after three PINs (or whatever the manufacturer designed the microcontroller for), the device is bricked and there's effectively no way to recover the data.


Extract X509 client certificates from TCPdump files

Since the certificate is transferred in clear within the TLS handshake you can extract it. Tool of choice is probably wireshark which gives you a very good view of all the TLS handshake details so you can easily extract the certificate manually.

See also https://ask.wireshark.org/answer_link/17261/ for a more automated way by using the command line version tshark. While the example there is probably created for server certificates it should work for client certificates too (untested).


What happens if the CA has knowledge of private keys?

I agree with binaryanomaly's answer, except even in the normal operation (where your private key is kept secret) any CA can already impersonate any other user's identity.  The CA merely needs to create a new CSR (for a private key they possess) and then sign it, so now there is a new certificate (that your browser will inherently trust).  Then if they can eavesdrop/alter your network traffic, they could MitM any SSL connection relying on CAs for trust.

Granted, in principle you could detect that the certificate has changed in this scenario (if you actually examine the certificate and look at the modulus or signature).  With the  lost private key model, the CA could use your private key to decrypt your traffic passively, without having to do a MitM attack that replaces your certificate with one that they have the private key for.


Correctly configuring load balancing for TLS session resumption

That's exactly what session tickets are for. While session ids are only some kind of reference which "point" to the session information stored on the server, session tickets contain all what is needed inside the session ticket, including the key material. Nothing is stored on the server side for the session.

Of course it would be a bad idea to have these information in plain text because than an attacker could just take the session ticket to extract the keys and decrypt the traffic. Therefore the session tickets are somehow protected - the details depend on the actual implementation. Usually this means they are encrypted with some server side secret and protected against manipulation with some MAC or HMAC. And as long as all servers share the same implementation and encryption key they can deal with the tickets issued by another server.

Given that session tickets include all key material it is essential that they are properly protected. If the servers are using the same encryption key for the tickets all the time it is sufficient for an attacker to attack one of these servers, get the encryption key and then use this to decrypt all previously sniffed session tickets and thus all previously sniffed traffic. The best way is therefore to regularly rotate the secrets in order to limit exposure of such critical information.

Given that a session ticket can store arbitrary information it can also store an ID for the encryption secret which makes it possible to use a new encryption key but being able to handle tickets protected by the old key for a while. Whenever such an old ticket gets received it can be decrypted if the old key is still known and then a new ticket protected by the new key can be issued.

Note that this mainly describes session tickets up to and including TLS 1.2. With TLS 1.3 the session handling mechanism was reworked. For more information see Botching Forward Secrecy - The sad state of server-side TLS Session Resumption implementations and The Future of Session Resumption - Forward secure PSK key agreement in TLS 1.3.