Do SSL/TLS clients warn on weak keys/hashes regarding self-signed certificates? In the last few months/years, SSL/TLS clients such as web browsers normally display warnings on server certificates with low-bit keys and weak hashing algorithms. This is most certainly the case for certificates signed by major CAs. Do the same warnings get displayed for certificates signed by a self-signed CA when the CA certs have been added to the certificate store?

I'm well aware that the behavior depends purely on the client software at hand, but I'm primarily wondering about major web browsers (Firefox, Chrome, IE, etc...)

If the self signed has been added to the certificate store the OS/Browser will treat like any other certificate and display any warnings regardless.


Bluetooth tethering and WiFi hot spot I am using bluetooth tethering through my one android phone to another android phone and i am using free VPN app on my second android phone which is connected by bluetooth tethering to open Facebook because it's blocked.

I am using my company's WiFi network to connect to internet. Can IT department of the company trace that i am using bluetooth tethering on my second android phone through my first android phone and using Facebook?

They can't see that you're using Facebook, but they can see that you have an encrypted connection coming out of your phone. All the Bluetooth tethering is doing is forwarding packets from one phone to the internet, if you're tethering to a cellular network your company won't be able to see what your doing. However if you're tethering to their corporate wifi, they're going to see a VPN connection coming from your device, but the contents will be encrypted.

I'd recommend you simply stay off of Facebook and not try to get around the block. A rogue VPN connection in a corporate network is troublesome, Your IT department won't be able to know what you're doing on the VPN, for all they know you're either browsing Facebook or leaking sensitive information.


Does HTML Purifier (which converts & to &) prevent HTTP parameter pollution? If a REST endpoint (http://example.com) reads the p query parameter and pass it along to another endpoint:

http_get("http://example.com/api2?p=".$_GET['p']);

I will be able to exploit it by appending content after p: http://example.com?p=a%26admin=true, which will cause it to make a request to http://example.com/api2?p=a&admin=true (%26 is decoded to & by the server), which will result in an exploit if the /api2 endpoint reads the admin parameter.

However, if I use HTML Purifier on $_GET['p'], it will convert & into &amp;, which will break the attack unless api2 reads amp;admin (which is not likely in practice).

Does that mean the escape of & into &amp; will effectively prevent the exploit? Why does this page warn us to watch out for &amp;HPP_TEST then?

HTTP parameter pollution is the process of manipulating a URL in order to bypass parameter validation at the server or WAF. It is for example done by adding one parameter again, i.e. making the query string foo=1&bar=2 to foo=1&bar=2&bar=bad-value.

Note that a polluted URL is still a valid URL and that it might even be intended that way, for example by using web form with multiple input fields having the same field name. Because of this any kind of HTTP parameter pollution protection needs to know what kind of URL or parameters are actually expected.

The use case for HTML purifier is a completely different one: sanitize user-provided HTML before it gets included in some server generated HTML. A HTML purifier has has no idea of how the valid URL in the context of the application should look like and thus cannot help to protect against HTTP parameter pollution.

But using it could actually make the problem worse: for example if the query string of the URL has the parameters foo=1&bar=2 converting this to HTML will result in foo=1&amp;bar=2 which will result in getting a parameter amp;bar=2 extracted instead of the expected bar=2.


Effectiveness of Security Images Do security images such as those presented upon logging into banks provide any tangible security benefits, or are they mostly theater?

Per my understanding, if somebody is phishing your users, it's also trivial for them to proxy requests from your users to your authentic website and retrieve the security image with whatever credentials the user provides before receiving the image (e.g., the username). If this is the case, security images seem to provide no additional security, and may actually be harmful if they help convince users that a malicious website is legitimate.

Am I missing something?

Great question!  As it happens, I can present experimental data on this question -- and the data is fascinating.  (I noticed that some of the answers contain speculation from first principles about how much security these security images offer.  However, the data turns out to have some surprises for all of us!)

Experimental methodology.
"Security images" have been evaluated in a user study, conducted with ordinary users who were asked to perform online banking in the lab.  Unbeknownst to them, some of them were 'attacked' in a controlled way, to see whether they would behave securely or not and whether the security images helped or not.

The researchers evaluated two attacks:

MITM attack: The researchers simulated a man-in-the-middle attack that strips off SSL.  The only visible indication of the attack is that lack of a HTTPS indicator (no HTTPS in the address bar, no lock icon, etc.).
Security image attack: The researchers simulated a phishing attack.  In this attack, it looks like the users are interacting with the real bank site, except that the security image is missing.  In its place, the attack places the following text:

  SiteKey Maintanance Notice:
  Bank of America is currently upgrading our award winning SiteKey feature. Please contact customer service if your SiteKey does not reappear within the next 24 hours.

I find this a brilliant attack.  Rather than trying to figure out what security image to show to the user, don't show any security image at all, and just try to persuade the user that it's OK that there is no security image.  Don't try to defeat the security system where it is strongest; just bypass the entire thing by undermining its foundation.

Anyway, the researchers then proceeded to observe how users behaved when they were attacked in these ways (without their knowledge).

Experimental results.
The results?  The attacks were incredibly successful.

Not a single user avoided the MITM attack; every single one who was exposed to the MITM attack fell for it.  (No one noticed that they were under attack.)
97% of those exposed to the security image attack fell for it.  Only 3% (2 out of 60 participants) behaved securely and refused to log in when hit with this attack.

Conclusions.
Let me attempt to draw some lessons from this experiment.

First, security images are ineffective.  They are readily defeated by very simple attack techniques.
Second, when assessing what security mechanisms will be effective, our intuitions are not reliable.  Even expert security professionals can draw the wrong conclusions.  For instance, look at this thread, where some folks have taken the view that security images add some security because they force the attacker to work harder and implement a MITM attack.  From this experiment, we can see that this argument does not hold water.  Indeed, a very simple attack (clone the website and replace the security image with a notice saying the security image feature is currently down for maintenance) is extremely successful in practice.

So, when the security of a system depends upon how users will behave, it is important to conduct rigorous experiments to evaluate how ordinary users will actually behave in real life.  Our intuitions and "from-first-principles" analyses are not a substitute for data.
Third, ordinary users don't behave in the way security folks sometimes wish they would.  Sometimes we talk about a protocol as "the user will do such-and-such, then the server will do thus-and-such, and if the user detects any deviation, the user will know he is under attack".  But that's not how users think.  Users don't have the suspicious mindset that security folks have, and security is not at the forefront of their mind.  If something isn't quite right, a security expert might suspect she is under attack -- but that's usually not the first reaction of an ordinary user.  Ordinary users are so used to the fact that web sites are flaky that their first reaction, upon seeing something odd or unusual, is often to shrug it off and assume that the Internet (or the web site) isn't quite working right at the moment.  So, if your security mechanism relies upon users to become suspicious if certain cues are absent, it's probably on shaky grounds.
Fourth, it's not realistic to expect users to notice the absence of a security indicator, like a SSL lock icon.  I'm sure we've all played "Simon Says" as a kid.  The fun of the game is entirely that -- even when you know to look out for it -- it is easy to overlook the absence of the "Simon Says" cue.  Now think about a SSL icon.  Looking for the SSL icon is not the user's primary task, when performing online banking; instead, users typically just want to pay their bills and get the chore done so they can move on to something more useful.  How much easier it is to fail to notice its absence, in those circumstances!

By the way, you might wonder how the banking industry has responded to these findings.  After all, they emphasize their security images feature (under various marketing names) to users; so how have they reacted to the discovery that the security image feature is all but useless in practice?  Answer: they haven't.  They still use security images.  And if you ask them about their response, a typical response has been something of the form "well, our users really like and appreciate the security images".  This tells you something: it tells you that the security images are largely a form of security theater.  They exist to make users feel good about the process, more than to actually protect against serious attacks.

References. For more details of the experiment I summarized above, read the following research paper:

The Emperor's New Security Indicators.  Stuart E. Schechter, Rachna Dhamija, Andy Ozment, and Ian Fischer.  IEEE Security & Privacy 2007.  (edit: updated link)


How to protect conditional 'if' in Android from reverse enginneering I recently downloaded one apk from a custom apkstore from my country. You can download the app for free but you need to pay to use some functionalities. I cracked the app jumping over all the activation mechanism just changing a boolean 'isActivated' flag which is used in an 'if'. I did this just for curiosity because I don't need this app, but I'm wondering how can you avoid this trick.
It looks almost impossible to me. I have read you can put sensitive code in C using NDK, but you always need to say in java something like (if activation == completed) in some point. The activation mechanism looks pretty complex but I don't changed it at all, so all the thing is in the conditional. I know you can use some obfuscator but that usually just change the name of the variables and make some permutations. If somebody know how to avoid or to protect the 'if' please let me know.
EDITED
Let me add that the apk is a remote control for my country custom digital TV decoders. The idea is that you can use your phone with infrared as a remote control. In this case the functionalities are in the apk, so a mechanism online with some session token seems inneffective to me because I can just ignore the token and call the functions, besides off course is annoying to have a remote control always online.

TL;DR: there seems no definite way to prevent it. The following thoughts may, often as a combination of anti-reverse-engeneer-measures -  slow down an attack to a level that makes attacking to labourous, but do not specifically address (only) the conditional "if" (I am not aware of such) but hardening in general.
Concepts have been proposed such as "Hardened Anti-Reverse Engineering System" (HARES), with the software code only being decrypted by the processor at the last possible moment before execution (A. Greenberg, Wired 2015). This does not specificall address an "if" statement, but one may not be able anymore to find also the "if"-statement. I havn't followed up on HARES, and more recent discussions include hardening for mobile banking apps (M. Rupp on cryptomathic.com) and a more general discussion on softwareengineering.stackexchange.com.


How antivirus companies create virus defnitions for new outbreaks This question quite amazes me. I dont understand how antivirus companies get info about the latest viruses. have they installed some kind of filters to monitor the internet traffic ?
Or they are purely dependent on sites like www.virustotal.com and similar ? If thats the  case, then why some companies create a patch first, and other companies dont even know about that virus ?

Please clarify.

Various methods can be used:

Samples are sent in by customers
Malware detected by heuristic scanners (i.e. stuff that behaves like a virus) is further analysed
Mail blocked as spam can be analysed for malware attachments.
"honeypots", which are public servers or email addresses designed to collect malware
going undercover in malware writers communities


Expanding/Inverse Hash function First off, before I ask my question, let me explain what I am NOT asking. I am NOT asking for a way/method to reverse a hash output; by definition, a hashing function is one-way.

Is there such a thing as an inverse hashing function? I am likely calling it the wrong name. What I mean is a function where, for example, if the input is 100 characters long the output will be 150 characters long. So, a one-way hash where the output is always larger than the input. However, traditional hashes usually make the output smaller than the input (if the input is of a reasonable size).

I am no security expert, so I am open to the possibility that I am mistaken. However, it seems to me that this kind of hash with a longer output would be harder to crack with a rainbow table, etc. Of course, it would be less useful than a traditional hash for things like assigning an image an ID, but for security applications, might it be superior? And of course, the ratio of input size to output size needs not be fixed, making it that much harder to predict the input.

Hashing is an algorithmic manipulation of data. A cryptographic hashing function is one-way function with a fixed output size regardless of the input size.

You seem to be talking about increasing security by using a different type of hash function, so no... no cryptographic hash matches properties that I didn't describe above. For other types of hashing (particular in regards to data structures), see http://en.wikipedia.org/wiki/Hash_function.

Otherwise, the answer is no and variable lengthening of input wouldn't be an improvement as it is impossible to generate more entropy by without adding more input. You can't add more input as one-way hash function must be repeatable to be useful.


Is it possible to come close to complete anonymity for bittorrent traffic? Some ways I can think of is to use a VPN, disable DHT, PEX and local discovery of peers options in the BitTorrent client and to route torrent traffic through the Tor network (people say that it's not a good idea). If I want to use my home network, is it possible to make it almost completely anonymous? What other ways are there to improve anonymity?

If I want to use my home network, is it possible to make it almost completely anonymous?

Unfortunately, you cannot be completely anonymous if you use your own home network. Actions like disabling DHT and Peer Exchange do not improve anonymity, since you still need to send your real IP to the tracker in order to actually interface with the swarm. This is not something you can avoid, because the trackers are required to track your IP and distribute it out to anyone who asks in order to actually maintain the swarm. After all, how else does the torrent program know the IP addresses of other seeders so that they can connect to them and begin the download?

If you use a VPN, you will route your system's traffic through another server. The traffic is typically encrypted so that your ISP is unable to view the contents of the data. When you do this, you simply shift the trust from your ISP to the VPN's ISP. This is intended to make it a bit harder for law enforcement or anti-piracy groups to obtain your original IP. However, many, many VPNs are highly insecure or provide very poor anonymity. Good ones are usually enough to protect against the MPAA as an adversary, but are far from capable of providing "close to complete anonymity".

If you use a seedbox, you will be using a remote server to run the BitTorrent application for you, doing the downloading and seeding on its own without involving your ISP. When you wish to access the downloaded material, you are able to download it directly from the seedbox. This provides anonymity that a VPN does not provide in addition to allowing for faster speeds, since all your downloads are direct downloads, and the remote server is what becomes the BitTorrent peer.


Do I need to decode a base64 representation of a key? I'm creating a JWT authentication system that needs a secret key for the digital signature. I'm using HMAC SHA256.

After reading the accepted answer here, I decided to use a 128-bit key. I would like to store this in my API's configuration as plain-text, so I used PHP to generate a 16-byte key and then base64 encoded it.

I'm not a cryptography expert, and I can't seem to find whether or not I can directly use the string resulting from the base64 encoding, or if I need to decode and use the binary.

Encoding 128 bit random data as base64 results in 170 byte not so random data. Since the method you want to use requires 128 bit random data you cannot use the base64 encoded version but must decode it back to the 128 bit version.


What would happen if a public key server is compromised? What would happen if in someway a public key server, let's say the MIT PGP key server, was compromised and some keys would be edited to an attacker's public key?

Is this even possible?
Would that be detected quickly?
What course of action would be taken?

Maybe I don't completely understand the concept, but I was wondering if this is a real issue.

Anybody can upload anything to the key server network, and there is only minimal verification of syntactical correctness. Do never trust anything on the key servers without further verification!

Whenever you fetch a key from the key server network, you should verify it for validity, for example through comparing the key's fingerprint with the key's proclaimed owner through an already established, authenticated (not necessarily private) channel: by meeting him, through a video or voice call, by sending a letter.

  Is this even possible?

To consider what a malicious key server might be able to do, you have to consider different attack models.

Keyserver hosting false keys should not be a problem, as you need to verify them anyway. Search the key servers for president@whitehouse.gov, I don't believe a single one is Barrack Obama's.
Keyserver modifying keys will send keys with modified or added OpenPGP packets like user IDs or signatures, but your OpenPGP client will realize that and stop importing the malicious key, and tell you so. At least GnuPG is doing so. If the primary key is modified, this would result in a changed fingerprint, and resembles an added key, not a modified one.
Keyservers omitting data is well possible and a problem. A key server could hide a given key you should not see, or even prevent you from fetching a revocation certificate. This can only be prevented by fetching the key from multiple and if possible trusted servers using HKPS to prevent man-in-the-middle-attacks.

  Would that be detected quickly?

In case of omitted information, only if you notice it on your own, for example because data's missing on one server but hosted on another, and reconciliation does not take place for a given time (give servers some minutes up to several hours to fetch up on all updates).

You can realize that there are fake keys, but this is not really a key server problem but a problem with verification. You will realize modified keys because of warnings/error messages in your client application.

If you realize a key server is acting weird, and keeps on doing so, consider reporting to the SKS mailing list, which probably is the place most other key server operators get together. At least it might be removed from the SKS key server pool, which is default for most OpenPGP setups.


What is the actual value of disabling remote root login using ssh? I have read the answers regarding why you should disable remote root login, but there is something nagging me. Assume this:

Scenario 1:

Remote server A.
Remote root login disabled.
Password authentication is disabled.
User A is using rsa authentication to log in.
User A runs /bin/su - to become root and enters the root password.

Scenario 2:

Remote server B.
Remote root login enabled.
Password authentication is disabled.
User B is using rsa authentication to log in as root.

I already know the saying about multiple lines of defense, and yes - I know that bots on the internet are more likely to try breaking in using root compared to most other logins, but does scenario 1 offer any significant advantages over scenario 2 if you assume that an attacker finds a way around the rsa authentication (either by hijacking, exploits or just copying the key file) used in both scenarios?

Lets say that an attacker gets access to server A, and is able to log on as user A. Isn't it right that from that point on, user A can't log in and su to root without potentially sharing the root password with the attacker? Is it difficult to just add a home made command at the end of the users login shell script that will intercept and relay (or store) the root password?

My point isn't that it is safe to let users log in as root remotely, but that forcing the users to log in using another account is almost as unsafe - modulo various bots that are always hammering away on root accounts everywhere.

Am I missing something?

Just off the top of my head:

If user's credentials are compromised, locking out that account in the user directory is much quicker and reliable than editing /root/.ssh/authorized_keys on all systems to remove that user's key.
Linux auditing daemons distinguish between "uid" and "effective uid". Users who ssh in as themselves and then sudo to gain privileges will be seen by the audit daemon as "user bob acting as root" vs just "user root" if they ssh in directly as root. Having an audit trail that goes back to the user performing the actions is important.
You can require a 2-factor authentication token for sudo. While this can also be done on the sshd level, this requires a 3rd-party patch and significantly impacts usability, as this can't be just enabled for a group of users.


Generate CSR from existing certificate Can we generate the CSR (certificate signing request) used for certificate signing from the signed certificate? It should work with the original private key when signed again with different authority.

Using OpenSSL, this is what you would do:

$ openssl req -out codesigning.csr -key private.key -new

Where private.key is the existing private key.

As you can see you do not generate this CSR from your certificate (public key).
Also you do not generate the "same" CSR, just a new one to request a new certificate.

As per your comment, if you do not have access to the existing private key then you can create a new private key and CSR:

$ openssl req -out codesigning.csr -new -newkey rsa:2048 -nodes -keyout private.key

The end results remain the same, you get a CSR and issue a new certificate.


Portable KeePass and TrueCrypt I ran some advice on the nets:

Don't reuse your passwords. Make sure all the passwords you use are different.
Use a password manager. An example is "Keepass".
Set the master password to something very strong, like:
"This is a super secure passphrase because it's crazy long"
Then paste all of your unique passwords into the manager.
Keep the password manager installed on a thumb drive.
Encrypt the thumb drive with something like TrueCrypt or PGP.

I had a few questions like:

Is this sound advice?
Do I need TrueCrypt on every computer I use my drive on? How does that work?
If my KeePass has a long password do I really need to Encrypt my Drive?
If Yes can somebody walk me through encrypting my drive via TrueCrypt?

Yes.
No, TrueCrypt supports portable installation (running it from USB drive without installation).
Yes, KeePass.exe can be modified in order to sniff on your database password or dump your decrypted database. Make sure you have a different passphrase for TrueCrypt volume and KeePass database! Furthermore, enable "Enter master key on secure desktop" option in KeePass as it will stop some keyloggers from getting your database passphrase.
No, it's very simple and I'm sure there are plenty of howto/guides on Internet.


Shellcode getting segmentation fault on vmware I'm learning exploitation, and I downloaded some execve("/bin/sh") shellcode from exploit-db to use it in simple buffer overflow example.
When I execute the program I am getting segmentation fault.
I'm running this on kali linux in vmware.

Here is code:

#include<stdio.h>
#include<string.h>

const char sc[] = \
"\x01\x30\x8f\xe2\x13\xff\x2f\xe1"
"\x03\xa0\x52\x40\xc2\x71\x05\xb4"
"\x69\x46\x0b\x27\x01\xdf\x7f\x40"
"\x2f\x62\x69\x6e\x2f\x73\x68\x41";

void main()
{
         printf("Shellcode Length: %d\n", strlen(sc));
         ((void(*)(void))sc)();
}

Here is how it is compiled:

gcc -z execstack -fno-stack-protector shell.c -o shell

May it be caused by running it on vmware?
Is it possible that there is something wrong with shellcode but I am getting SIGSEGV instead of SIGILL?
Is there something wrong in the way that I execute code in this C program?

You are executing ARM machine code on an x86 machine. Of course it won't work. If it is giving SIGSEGV (which happens when a general protection fault, #GP(0), is raised) instead of SIGILL (which happens when an illegal or unknown instruction is found) despite being compiled for a different architecture, then the first few bytes of the ARM shellcode must have been interpreted as legal x86 machine code. The x86 ISA is extremely complicated, and any random assortment of bytes has a non-negligible chance of being technically valid x86. While it may have been decoded correctly, it does something totally unintended, which just so happens to trigger a general protection fault before anything that can't be interpreted as valid x86 is reached.


Is sha-1 hash always the same? Is it possible to ensure that a string is hashed always the same way no matter which language you use to do it (Java, vb.net... ) and no matter what operative system you are?

Hash functions are deterministic: same input yields the same output. Any implementation of a given hash function, regardless of the language it is implemented in, must act the same.

However, note that hash functions take sequences of bits as input. When we "hash a string", we actually convert a sequence of characters into a sequence of bits, and then hash it. There begins the trouble. Consider the string "café": among all the possible conversions to bits, all of the following are common:

63 61 66 e9                             ISO-8859-1 ("latin-1")
63 61 66 ca a9                          UTF-8
63 61 66 65 cc 81                       UTF-8 (NFD)
ef bb bf 63 61 66 ca a9                 UTF-8 (with BOM)
ef bb bf 63 61 66 65 cc 81              UTF-8 (NFD with BOM)
63 00 61 00 66 00 e9 00                 UTF-16 little-endian
00 63 00 61 00 66 00 e9                 UTF-16 big-endian
ff fe 63 00 61 00 66 00 e9 00           UTF-16 little-endian (with BOM)
fe ff 00 63 00 61 00 66 00 e9           UTF-16 big-endian (with BOM)
63 00 61 00 66 00 65 00 01 03           UTF-16 little-endian (NFD)
00 63 00 61 00 66 00 65 03 01           UTF-16 big-endian (NFD)
ff fe 63 00 61 00 66 00 65 00 01 03     UTF-16 little-endian (NFD with BOM)
fe ff 00 63 00 61 00 66 00 65 03 01     UTF-16 big-endian (NFD with BOM)

and all will yield very different hash values when processed with a given hash function. You have to be very precise about what you do when dealing with cryptographic functions; every bit counts.


Multiple types of tracking In a system where I have reviews of products, to avoid fake reviews I have thought about doing the following:

Limit one review for each account -> To bypass this measure, the user could create multiple accounts.
Limit a browser fingerprint for each product. To bypass this measure, creating a new account will not work for the malicious user. But, then he could change the browser to get a new fingerprint.
Limit an IP for each product's review. My question is about this step. If I limit an IP by each product, I know that companies or schools have the same static IP for a large audience, but the problem is not that. My problem is about the dynamic IPs. If a legitimate user receives a previously registered IP of the another user, then he can't create a new review. So, should I use only the first two steps? What are the real probabilities of two persons, members of this app, wanting to write a review about the same product, receiving the same IP? Is this just paranoid, or could it be a real scenario? Well, the malicious user could get a new IP easily, so this step is just really easy to bypass.
I'm not interested in things like evercookie.
Is there another way of tracking?

Limiting by IP is too strict in my opinion:

As you said there is a problem with dynamic IP.  But this alone could maybe solved if you enforce this limit only within a specific time frame because the IP does not change that often.
But corporations and institutions often use private IP addresses inside and have few internet gateways. This means all users there have the same outgoing IP.
And then you DS-Lite and similar access methods. Here the users get only a private IPv4 address and share the same public IPv4 address because there are not enough public IPv4 addresses for all. Usually they have a unique IPv6 address though. This kind of access affects probably most mobile networks, large parts of Asia but also some ISP in Europe or America.

I think the best way is too limit the reviews per account and then make account creation hard, i.e. use captchas etc. There is also research to detect bogus account so that you can close accounts later and remove the reviews, see for example Aiding the Detection of Fake Accounts in Large Scale Social Online Services from the recent USENIX conference.

Of course everything you do to limit abuse might make it more complex might deter some benign users from using your system. But if there is too much abuse your system is useless for them too. It is probably very hard to get the balance right and if you look at social networks, free web mailers etc they are constantly change their procedures to make it easy for benign users to use the system but hard for spammers to abuse it. Since spammers evolve their techniques too you must probably tune your system regularly. Or you might try to profit from the validations google etc do to their accounts and instead of doing all the account creation and validation by your own let the user sign in with their google or facebook accounts.


What stops a hacker from installing its own CA certificate? Taking a look at this (now rather old) article about the generated rogue DigiNotar certificates, it states the following:

  ...Such is the case with that small company in the Netherlands,
  DigiNotar. Reports from various sites indicate that hackers
  compromised the firm’s servers and generated rogue certificates. With
  a rogue certificate in place, a hacker can make your system think it’s
  using a legitimate, trusted certificate from well-known companies such
  as Google and Yahoo. The hacker can then intercept your Internet
  connection with the site you intended to use and redirect you to a
  fake site, where you are tricked into entering personal information
  such as your user name and password. Your computer still thinks it’s
  connected to a trusted site...

This is what I don't get: Instead of hacking CA's servers, wouldn't it be easier for a hacker to deploy a trojan which installs its own certificate in the 'trusted root certification authorities' store on the users computer (and then use some kind of DNS hack to redirect the users browser to a server from the hacker) and that way basicly accomplishing the same goal?

I mean, it's pretty easy to deploy a certificate in the root 'trusted root certification authorities' via a batch script, and with this in place, the browser won't raise any flags because the hackers rogue certificate is 'trusted'.

Why go through all the trouble of hacking the Certificate Authority? What am I missing here?

Installing a "trusted root" on a victim's computer requires local administrative rights. If the attacker can do that, then he has already won.

Hacking into the CA's server to obtain a fake certificate is a way for the attacker to be able to masquerade as various "trusted" servers and issuers (e.g. to make fake "signed" OS updates), in order to breach into user computers that are not easily reachable otherwise (Trojans work for some users, not for all). It is all a matter of escalation. A CA server is very sensitive because hacking it gives (more or less) automatic entry to millions of other computers.


Security in Windows 7 vs Ubuntu I have two semi-related questions about the security-related reasons I hear for switching to Ubuntu over Windows 7 (or from other Windows OSs to other Linux distributions).

Someone people say that Ubuntu is less of a target for malware, spyware etc. I've heard arguments that many attacks are written specifically for Windows computers because Windows is a more common OS. If this is the case, doesn't this logic essentially adhere to the 'security through obscurity' mentality that is generally frowned upon?
I assume that malware can also be written for Ubuntu, so why do I rarely hear about Ubuntu being more secure? What other security advantages are there to switch to Ubuntu, or another Linux distribution more generally? (I realize that certain distros might have strengths and weaknesses so just specify Ubuntu if the variances are too large.)

If this is the case, doesn't this logic essentially adhere to the
  'security through obscurity' mentality that is generally frowned upon?

Security through obscurity is only frowned upon when used instead of a more fundamentally effective control. Typically it is best to apply multiple layers of security, and it is perfectly acceptable and beneficial to use obscurity as one of those layers.

For example it's fine to name the text file storing your encryption keys something obscure in the hope that if someone compromises your system they won't be able to find it, but don't put that text file in a publicly accessible place just because it's named something obscure.

Using your scenario, it's fine to derive security benefits from running a less common platform - but don't forgo other controls such as a firewall and general security concious behaviour just because you're running Ubuntu.

  What other security advantages are there to switch to Ubuntu, or
  another Linux distribution more generally?

There is nothing that makes Linux fundamentally more secure. Some controls may be implemented or applied differently, but there is nothing that makes Windows outright less secure. Plenty of people can and do run highly secure systems on Windows.

It's possible that on average fewer security issues occur on Linux, but if that's the case then it's probably due to a combination of secondary factors such as:

Linux users in general are likely to be more security concious, not click on popups, open dodgy attachments, etc.
Linux users are less likely to operate in a privileged environment (eg. by default not running as root vs. a lot of people who turn off UAC on Windows)
Arguably it's easier to update vulnerable software using a package manager on Linux

On the other hand, there's several factors which cause me to believe OS choice isn't that significant in terms of security overall:

It's not that common that OS vulnerabilities are primarily responsible for an intrusion. More often the malware gets in via a vulnerability in some other application or by user error, which then might exploit the OS once in.
Arguably Linux users are more valuable targets on average because they're more likely to have access to other systems, servers and production code.
Linux has the majority in the web server market, and there's plenty of both successful and unsuccessful attacks, malware, and vulnerabilities for Linux in this domain


Which algorithm works well for encryption of large datasets? I need to encrypt large dataset files that may be in gigbytes of size. I can perform compression task on the dataset too. Which will be a good algorithm to use that is fast enough as well as secure enough?

Depends on what you're trying to secure it from. I would say that, generally speaking, AES-128 is a good compromise between fast and strong, and there's a lot of hardware support for AES available, which helps to speed it up.

I assume you're not trying to protect it from a state actor or someone with similar resources who want to gain access to your data? If so, you might want to consider longer key sizes and/or chaining other encryption algorithms.


Are there any hardware HSMs that can host/run custom applications using the HSM processor(s) within the hardened security boundary? It seems that the majority of commercially available hardware HSMs are only designed to allow authenticated users to generate, store, and use cryptographic keys with various cryptographic algorithms implemented within the firmware of the HSM.

Reading the datasheets it looks like I can use the provided API to make my (external) application interact with the HSM and use its cryptographic muscles, maybe using keys generated/stored within the HSM. But, it seems that long term storage of the data/objects cryptographically processed by the HSM within the HSM boundary is not available.

Why aren’t there any HSMs that allow for user code and user data to be persistently stored and managed within the physically protected memory space of the HSM?

Does anybody have experience with HSMs and could point me towards a commercially available hardware HSM solution that at the least allows me to store some registers beyond cryptographic keys?

Ideally I would like my application to be stored at rest in the HSM boundary, executed by the same processor that runs the crypto provided by the HSM and to persisytently store a few registers within the HSM's protected area.

The Thales nShield HSM (previously nCipher) allow for generic programming. This is a rather expensive option; it must first be enabled in the HSM (through a "feature file" which is signed by Thales and specific to the serial number of a HSM), and then the extra code can run as long as it is signed with a key known to the HSM for such usage.

With that option, you will get a C compiler with a reduced C library, and some API which give access to the HSM features. The internal OS allows for one process (but multi-threaded) and cryptographic operations are done with transactions; there are also transactions to exchange arbitrary binary blobs with the external world (the host PC). The core CPU is not very powerful (think 60 MHz ARM or PowerPC) but there is some substantial RAM (megabytes, even dozens of megabytes).

Thales/nCipher HSM do not have a lot of permanent storage features (there are a few kilobytes of EEPROM but that's all). Actually, the HSM only stores a master key (which you cannot access), and everything, including the "keys" which are "in the HSM" are off-loaded, with encryption. You can do the same: store your data stored on the host, sent back to your internal module; the data is encrypted with one of the keys (which are virtually "in the HSM"), and your code in the HSM does the decryption.


Does a raspberry pi VPN do anything? Does a raspberry pi vpn do anything besides hide your traffic on your local network? Can your ISP still see what traffic you are sending? Are homebrew openvpn raspberry pi vpn servers a viable source of internet privacy (ex. keeping your ISP from selling your personal information?)

Does a raspberry pi vpn do anything besides hide your traffic on your local network?

When it's on your local network, it can not.

  Can your ISP still see what traffic you are sending? Are homebrew openvpn raspberry pi vpn servers a viable source of internet privacy (ex. keeping your ISP from selling your personal information?)

Only when you put your raspberry on some other network where the internet connection is not provided by your ISP. That way you have an encrypted tunnel to the raspberry. However, the ISP which provides internet connectivity to that network can monitor unencrypted traffic routed through the Raspberry.

In general, the idea behind "VPN for anonymous internet use" is that someone you trust to respect your privacy provides a VPN with an internet gateway which is 1. connected to the internet through a privacy-friendly ISP and 2. is used by so many people that no connection can be reliably matched to a specific user.


Symmetric Keys for a TPM I am currently researching the capabilities of TPM in creating and storing different kinds of cryptographic keys. I know that a TPM can create and store keys for asymmetric algorithms like RSA or elliptic curves. But what about symmetric keys, like those generated as session keys? Can a TPM create and store those as well?

I found sources in the internet claiming both possible answers to be true. One source says that a TPM cannot handle symmetric cryptography and additional technology is necessary here. Meanwhile the documentation of the TPM library by the trusted computing group refers to some symmetric key operations, indicating that a TPM just might be able to handle them like their asymmetric counterpart. What is the truth?

TPMs can seal arbitrary data. When you seal a key, you are not actually storing it inside the TPM. You are sending the raw key to the TPM which encrypts it with an internally protected key (the Storage Root Key, or SRK) and returns the encrypted, or sealed, blob. It is up to you to store this encrypted blob.


XSS: alert() not executed on different OS/computer I've encountered a strange behavior while I was performing a security audit of a web application. Some user controlled inputs were displaying their values, unencoded, into the page that processed the request. After testing a few characters to see if they were encoded/removed, I went for the classic <script>alert(1);</script> in order to provide a sample "attack" vector. The alert was displayed while I tested it on my computer - Debian/CentOS/Windows 8.1 - (on both Chrome and Firefox), but it just wouldn't work on another computer - Windows 7 - neither on Chrome, nor on Firefox or Internet Explorer. The code was still unencoded in the page source, but the alert never popped up. I ran various JavaScript code and it worked (assigning a variable, redirect etc.). I made sure no add-ons were interfering with what I was doing. What could possibly cause this?

I'd be tempted to put a proxy between the server and the client and compare the output of the request byte for byte. That should rule out server differences due to browser headers in the request etc. and will narrow it down to local differences. You could then also capture the output in the proxy and load it into each of the browsers on each machine (as a replay of the response, not just loaded as a file i.e. trap the send/response and replace the response) and see the results - this would rule out network filtering between local reception of the responses and passing to the browser for rendering. You'll then know where in the chain the difference might be.


Is it possible to make an xss with only html tags I'm not aware of all the xss tricks..

While programming in Ruby on Rails, using a sanitize method to allow only certain tags and it makes its best to clear all the other tags and scripts

the remaining tags are

    "small", "dfn", "sup", "sub", "pre", "blockquote", "ins", "ul", "var", "samp", "del",
 "h6", "h5", "h4", "h3", "h2", "h1", "span", "br", "hr", "em", "address", "img", "kbd",
 "tt", "a", "acronym", "abbr", "code", "p", "i", "b", "strong", "dd", "dt", "dl", "ol",
 "li", "div", "big", "cite"

Is it possible to create an XSS attack with a combination of these tags?

Yes. It's trivial.

Might want to save your work before trying that, though - the alert might show repeatedly as you move your mouse across the screen.

Of course, a better attack would involve destroying the div as soon as the JavaScript is called, in order to make it look legitimate.

You should escape all output in order to avoid this.


Automated server security testing best practices? Is there a standard way of automatically testing the basic security of my web server? I've found a couple on-line services, (e.g. http://hackertarget.com/), and they seem ok, but I'd like to start off with the basics. Is there a go-to method for stress-testing a web server's security?

There are a number of scanners out there which aren't free. Like Nexpose or Nessus which can do way more than just scanning a webserver. But they provide this functionality as well of course.

The interesting part is that these scanners can also log into your server and perform configuration reviews to a certain standard. For instance the DISA STIG is a very good baseline to test against and see if you have properly implemented your webserver in a secure way.

Aside from that, you can also test the application itself, with automated scanners like Burp or Appscan.

Another option would be to use ASV. They are normally only used for PCI-DSS compliance, but you can also use them of course even if you needn't be compliant with PCI-DSS. Their baseline scans and reports are a very good baseline assessment to see what the level of security is, as the PCI-DSS requirements are not light at all.


DVWA vulnerability list or guide? Is there a list of vulnerabilities for DVWA, I cannot seem to find a vulnerability list or guide.

By guide I mean an exhaustive list of vulnerabilities to work through.

DVWA separates each vulnerability into its own page.  Each page is accessible on the menu to the left.  Each vulnerability is a textbook example of the flaw,  there should be nothing strange going on so any documentation on that vulnerability is useful.   If you don't understand the very basics of a flaw,  then I'm sure OWASP has a page on it.  You could also try and find an exploit for the specific flaw "in the wild" (like exploit-db.com).


Can opening a blackmail/phishing email on outlook cause issues? I recently ran some programs on my computer that caused some kind of security breach, I reinstalled windows (after formatting) to fix it.

3 days later I got an email with my old windows password blackmailing me, the message seem...automated, didn't even have my name, so I'm sure it was a phishing attempt, I opened it on my iphone just to be safe (hopefull that's accurate?) It was on my outlook.

But later I may have reopen it on my chrome browser on windows 10 on my PC, I don't think I was that stupid...but in case I WAS. Can I get virus/malwares from opening an email on hotmail with my chrome browser?

I have scanned my computer with windows defender and malwarebytes and nothing turn up, so should that means I'm safe?

Thanks

The answer to your question is not entirely straight forward.

When I say "opening" an email I mean clicking the subject and looking at it, nothing else, no loading of images, no clicking of links, nothing. Also I am assuming your email client won't automatically pull in linked content from emails;

Also I am presuming your account is not a local administrator, if it is... change it. You're facing a very high risk of full compromise if you use your computer under the privs of a local administrator since any malware would gain full control over it.

Can opening a phishing email cause issues? Yes it can, especially if your browser is vulnerable, but there could be other routes;
Does opening a phishing email usually trigger malware? Not if you're up to date and have your browser or email client configured securely;
Should you open a phishing email if you spot that on the subject alone? Definitely not;
Is it possible to meaningfully trigger an infection by simply clicking a link on a phishing email or by pulling in remote content automatically? Absolutely yes;

Concerning Chrome, it is not significantly better or worse security wise than firefox or opera, it's all relative to the current configuration, it being fully patched (have I mentioned how critical this is? it is critical).

Mobile email clients are usually safer for the simple reason that most attacks are still targeted at workstations. But this is changing.


How many passwords is good for security? So I'm wondering how many passwords is enough to have my data safe because right now I have 1 hard password for bank & mail (>10 characters + numbers etc.) and 1 medium password for games and 1 for shady sites. I keep all them memorized and not on paper/in a document. Is this enough?

No, it is not enough. Using the same password for both your email and your bank is a bad idea. If your email provider is compromised, that means the attacker will get access to your bank account, and vice versa. You don't want that.

Use one hard password per site. You won't be able to memorise all those, but don't worry. That's what password managers are for.

If you want this explained in a video featuring an animated octupus, the Electronic Frontier Foundation got you covered.


Possible security risk with disk encryption key getting swapped to the hard drive I've recently read about the cold boot method, where it's possible to obtain the key for an encrypted filesystem from DRAM.  This can be done even after the computer is turned off, but it requires special equipment that is very difficult for most people to obtain.  Then it occurred to me that there's a security risk where an attacker could gain the key to an encrypted disk without having access to expensive hardware: if the page containing the key is ever swapped out to the hard drive, the attacker would only need to read the swap space to get the key.  I don't think on-the-fly disk encryption programs encrypt the swap space, since it's conceptually part of RAM, so an attacker would be able to read the unencrypted contents of the swap space and get the key.

I've been thinking of using FileVault to encrypt my Macbook's data in the future, since I'm one of those paranoid types.  I came to this decision after learning that it uses AES encryption, which IMO is the best cipher out there.  But I'm just concerned about this vulnerability.  Do programs like FileVault have a means to protect against the key being swapped out to an unencrypted swap space for an attacker to read?  If so, what is it?

EDIT: Actually, I just realized, that, at least on Mac OS X, the swap space is part of the filesystem, and it's stored in /var/vm as I just recently discovered, so in the case of OS X, FileVault would probably encrypt any pages that are swapped to the hard drive.  This might not be the case with Linux, since swapping is done with a separate swap partition.  I'm not sure how it's done in Windows.

Not every part of the memory can be swapped (or correctly paged) to disk. Proper code dealing with sensitive data like encryption keys will mark the relevant part of the memory so that they will not be paged. This is true for both user-space and kernel-space encryption.

Which means you can find such key in memory but with proper applications you will not find these on disk. And I would think that FileFault on OS X and also dm-crypt and similar stuff on Linux behaves safe in this area.


TSource Engine Query DDoS attack My gaming machine is under DDoS attack and when I used Wireshark I found the following string "TSource Engine Query" in all UDP packets coming from random IP's.

I found using Google that some gaming studios use this function to connect to server. Is that true or it is malware?

Can someone explain what is TSource Engine Query?

How to solve it?

Can someone explain what is TSource Engine Query?

I add to @schroeder answer. This is a common Distributed Reflective Denial of Service (DRDoS) attack. You can read about an analysis done on an number of games that are vulnerable to the attack.

  How to solve it?

Changing IP address is not going to help you as an attacker will easily find your new game server.

Read UDP-Based Amplification Attacks from US-Cert on two mitigations of DRDoS: Source verification and Traffic Shaping. You many need to setup an IPS (e.g. Suricata or Snort) on your game server to achieve this.

Alternatively, you can use DDoS protections services that are mainly paid solutions.


SHA1 Root Certificate Authorities My understanding is that SHA1 is pretty much considered obsolete.

Yet, I just opened the Trusted Root Certificate Authorities on my Windows 10 computer and I see that most Trusted Root Certificate Authorities use SHA1 certificates, most expiring well into the 2030's.

This includes root CAs from Verisign, thawte, GeoTrust, DigiCert... etc.

My understanding is also that any certificate issued by a CA will automatically have the same hash algorithm and bits as the root CA, so doesn't this ultimately mean our computers are set to blindly trust something that uses a now considered obsolete hash?

I understand that whether any certificates issued by these CAs are still in use or not is a completely different thing altogether, but why do we just blindly trust them (the CAs and ultimately their issued certs) to begin with?

Edit

In fact, some root CAs still use MD5...

My understanding is also that any certificate issued by a CA will automatically have the same hash algorithm and bits as the root CA

This is incorrect. A CA certificate can issue certificates with different signature algorithm than its own.

A Root certificate is trusted because of its presence in the browser's root certificate store, rather than by its signature. The root's signature is not used for anything, except perhaps as a convenient way to talk about the certificate during initial validation of the root certificate for inclusion in the browser root store. Root Certificates with weak signature that has been included in the root store for years are more trustworthy than ones that had just been included recently, as there are more time for the CA, browser developer, and the public to notice if something is off with the root certificate shipped in the browser.


If I use SSL, do I need to hash the password before sending it to the server? I am setting up a website to help people with certain niche interests find each other. It is being done purely as a voluntary project, there is no money involved (on either side), nor is there much personal information stored. The only interesting data we store is the postcode, email address and password (hashed) of each user. All that would be gained by having access to these is the ability to change the user's postcode, which seems to me to be of little benefit to anyone.

However, it has been pointed out that many people use the same password everywhere, so if someone could access the data, they would be able to try the same email/password combination on other sites. Whilst this seems like a small, and probably futile task, we want to reassure our users that we are protecting them.

If we run the site over SSL, then when they register or log in, is there any great benefit in hashing their password in Javascript before sending it to the server? On the other hand, are we exposing anything we shouldn't by doing the hashing in Javascript, where it's open for anyone to see, as opposed to on the server, where it's only visible to people with access to the server (in which case we have other security issues)?

P.S. Please note that I'm not a security expert in any way, so please don't assume any prior knowledge. If I've missed some obvious point, please clarify it or ask for more details, rather than downvoting as a bad question. I did search around, but haven't really found anything that answers this question (although I learnt a lot of other things along the way!)

P.P.S. Please note that this question is specifically related to the register and log in process. There are obviously questions of database security, etc, but they are being dealt with separately.

There is generally no reason to encrypt passwords client-side. Let's consider a situation without SSL first, but with password encryption:

Bob is logging in to his account. He goes to the login page, enters his username and password, and logs in. As Eve is monitoring the exchange, she does not see the password, as it is encrypted.

This would only happen, however, if Eve is only monitoring the connection (which is almost never). Here's what would actually happen if Eve could modify the connection:

Bob is logging in to his account. He goes to the login page. However, Eve intercepts this request and removes the encryption code. Bob enters his username and password, and logs in. As Eve is monitoring the exchange, she does see the password, as it is not encrypted. To make Bob not suspect anything, she forwards the request with the encrypted password to the server and returns the session token to Bob.

In this situation, we can see that encryption is useless when the encryption code can be compromised. It would be useful, however, when the application's code can be trusted (e.g. delivered by a CD and signed by the developer) and the data is exchanged over an insecure connection (i.e. without SSL). This isn't the case with a website over HTTP.

What if this was done over SSL? Well, there would still be no point in encryption client-side. The attacker wouldn't be able to see the exchange, and if it was compromised, then the attack shown above could be used. Also, this raises a point of rolling your own crypto: yes, you aren't making the algorithms yourself, but you are using encryption somewhere where it is done elsewhere. Also, people who have JS disabled or have browsers without the crypto API, the whole thing would not work. The point of how JS may be insecure isn't that serious, as unless specific HTTP headers are sent, JS would be able to grab the password anyways.


What should I exchange with the server when I generate my AES 256 key? I'm creating a mobile fast-paced game and currenly I'm working on login/registration/connecting. I'm trying to make it right so it won't mess in the future.

For now, I have read multiple articles of which method should I use to make a 'secure user session' between client and a server.

My goal is to use RSA only to exchange AES key and send packets with AES only

It should look like that:

Store the same public RSA key on all clients

Store one private RSA key on the server

Client sends the 'AES initialization data' to the server encrypted with public RSA. Server decrypts AES data with a private RSA key, stores AES data, encrypts AES data with AES data and sends back to the client.

Client receives AES data encrypted with the same AES data, decrypts and if everyhing is ok, handshake is done, we can securely send messages using AES data.

I'm using Java and I have RSA algorithm done, I checked packets with Wireshark, encrypted and decrypted and it works. The thing I can't finish is AES encryption cause I'm missing some knowledge.

I know that AES uses IV parameter which is used like a 'salt' in SHA.
Basically I know how IV works, I read some, but I have no idea when and how many times should I send it.

Should IV be generated again and again with each packet or I should just generate one with a SecretAESKey, save it and use this pair to encrypt data and decrypt it?

I really learn quick so please don't judge me cause this question may look stupid to you.

Thanks for any help!

Don't do this, ever.

Inventing a secure protocol, even using known-good cryptographic primitives is extremely hard. Implementing a correctly designed protocol is still considered hard, even when using correctly implemented cryptographic primitives. Experienced people who work on crypto at Google/Microsoft/Apple have made bad mistakes with this stuff. They have learned from these mistakes and they all recommend you use the highest level misuse-resistant API you possibly can, instead of what you're doing which is using extremely low level API, badly.

From the questions you ask, you are very far from being qualified to do this kind of work for anything that will ever leave your computer.

It looks like you're trying to invent 90s crypto.

AES does not have an "IV parameter". You're asking about block cipher modes of operation (specifically CBC, which is not used in new protocols), and trying to decide whether to make the deterministic IV bug in TLS 1.0 CBC. Well guess what, the bug was brought up on the mailing list in the last century and has been fixed since then. And then CBC was deprecated in favor of AEAD modes, and now the industry is into misuse-resistant AEAD modes that don't break catastrophically when you repeat a nonce. Working alone without the best cryptographers pointing out the issues with your scheme, you might discover all those famous bugs by yourself, in a thousand years or so.

Since you haven't asked about how to combine encryption and MAC, I suspect you're doing unauthenticated encryption, which is known to be catastrophic. When you discover you need a MAC, you'll combine it badly with the encryption and the padding, like SSL did in the 90s.

Do you understand how secure padding of RSA works and why you need it?

You're trying to do RSA key exchange which has been disallowed in HTTP2 and TLS 1.3, for good reasons. Modern protocols provide forward secrecy.

Do you understand that index calculus is slowly killing RSA and classic DH and that's why people switched to ECC?

To summarise: Don't do this. Ever.

Use libsodium (or tweetnacl) instead. It is secure, fast, has a misuses resistant API, has been vetted by the best people. It is much, much better than TLS, even TLS 1.3 which is not standardized yet.

For educational purposes, I recommend doing cryptopals. You'll learn all you need to know about breaking bad crypto.


Does changing /etc/ssh/moduli impact previously generated keys? My company does a lot of automated file transfers over SSH/sftp with banks, etc.  A recent SSH upgrade on a server dropped support for the old/weak diffie-helman-group1-sha1 key exchange protocol in response to the recent Logjam attack.

Most of the organizations we work with support the diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256 protocols.  However, our /etc/ssh/moduli file contains some numbers weaker than what some servers want, so we get periodic connection failures when our server happens to pick a weaker number from the current file.

So now I am looking at generating a new /etc/ssh/moduli file and removing the weaker numbers to eliminate the possible failure.  What I want to know is if we can replace the existing /etc/ssh/moduli file without impacting our already-generated keys that we have exchanged with others.  I've read some other posts like Consequences of tampered /etc/ssh/moduli, but they aren't really clear on this point.

From what I have read, I think I am fine to do this since /etc/ssh/moduli is used primarily when negotiating an individual SSH connection, but I'd like some other opinions first.

You'll be fine. /etc/ssh/moduli is only used by sshd:

  The /etc/ssh/moduli file contains the system-wide Diffie-Hellman prime moduli for sshd(8).

sshd has nothing to do with client keys that you are using to connect to other machines.


Does blocking keywords prevent code injection inside this interactive Python file? We recently had issues with people messing around inside our system. To prevent code injections within my python code, I implemented the following if block:
#! /usr/bin/python3
#-*- coding:utf-8 -*-
def main():
    print("Your interactive Python shell!")
    text = input('>>> ')
    for keyword in ['eval', 'exec', 'import', 'open', 'os', 'read', 'system', 'write']:
        if keyword in text:
            print("You are not allowed to do this!")
            return;
    else:
        exec(text)
        print('Executed your code!')
if __name__ == "__main__":
    main()

A few (user) people can run this python file with sudo rights inside our Ubuntu system. I know this sounds like a security hole, but I don't see any possibility to escape from this. Is there any possibility to inject inside my code block? Do you have any tips to prevent code injections?

Simple blacklists are about the worst way to patch a vulnerability. They'll create a lot of false positives and any determined attacker will usually find a way around them.
Web Application Firewalls are a good example. The detection rules they employ are way more complicated than your simplistic blacklist, yet they don't catch everything, and every now and then, bypasses come up for things they are supposed to catch.

I don't see any possibility to escape from this.

Or so you think. You just haven't looked long enough.
vars(__builtins__)['ex'+'ec']("print('pwned')")
This sails right through your filter. It calls the exec() function which then goes on to print 'pwned'.
Now you can modify your blacklist to catch this as well, but someone else will come up with another way.

99% of the time I see someone using something like exec or eval, it's completely unnecessary. If you can avoid using exec, do yourself a favor and get rid of this vulnerability waiting to be exploited. If, however, you absolutely need to use exec, then do as user @amon suggested in the comments: Create a new pipe, fork and drop as many privileges in the child as possible, and then execute the code. Use the pipe to communicate between the child and the parent processes.


I want to restrict access to Nextcloud using OpenVPN Is it a good idea to restrict access to my Nextcloud server by using OpenVPN, so every user (this is for small group of people), will get their own VPN account and after that they will be able to access to their account as well.

For the restriction part, I'm not sure how to manage that, probably on firewall side and on server side, using UFW or apache config.

<Location "/">
              Order deny,allow
              deny from all
              allow from 192.168.1.1
</Location>

What is your suggestion for this idea?

Given that Nextcloud is designed to be an internet facing - e.g. "cloud" - solution, adding a VPN seems rather overkill unless you are planning to use it for very sensitive or high-value data.

Note that in using a VPN, you are committing yourself to getting the network design right and to ensuring that all the users have secure computers since you are allowing those devices into your secure network.

In my view, you would be better served spending a little time making sure that access to the Nextcloud server is properly configured. Also make sure that the server is constantly patched and that you are receiving security alerts from it so you know if someone/something is attacking.


How would one scan a large, untrusted file? I've recently started to convince relatives to upload anything they download to Virus Total, to help them be more safe when downloading stuff.

However, I have recently come across an installer for a game that is about 500MB large. Virus Total only supports uploads up to 128MB.

How can I ensure this file is safe to install?

You may not be aware of this, but VirusTotal saves the files that you upload.  Businesses that have a subscription to VirusTotal can download those files you uploaded, it's part of the terms of service.  I wouldn't upload anything potentially sensitive that you don't want the entire world seeing.

While VirusTotal is indeed a useful service, I don't see it being beneficial to scan everything you encounter.  Assuming you're running Windows, any of the big players in the AntiVirus game such as Windows Defender, should be sufficient most of the time.

Is there a reason you're worried about this game installer?  Is it from a legitimate source, or is it something you grabbed off a P2P service?  Things such as games which unpack giant executables aren't as likely to be caught by AntiVirus.   There's a lot more space to hide something malicious that seems innocuous.

For something that size, I would recommend running in a sandbox.  Cuckoo will analyze files and executables dynamically.  Sandboxie doesn't analyze files, but rather provides isolation, so if a program is malicious they won't be able to touch the rest of the computer.


Is it secure to keep malware in filesystem of VMs? We are going to install a sandbox solution that requires Ubuntu Server as the underlying OS (the product is not shipped as a ready to install appliance). For performance reasons the malware samples are stored on file system and not in the DB. The OS will be running on the ESX VM.

My question - is there any potential risk of backing up such a OS that will contain malware samples? I'm thinking of .vmdk level backup that allows granular restores as well.

The medium malware is stored on is irrelevant. Malware is just data, and data can only cause harm if something interprets it. This can mean anything from directly executing a malicious file to opening a malicious image in a vulnerable image viewer. Assuming the malware comes in the form of malicious executables or libraries, when it is stored on a filesystem or a .vmdk container, it cannot any harm. The only way it could do harm is if it were somehow executed, such as by being extracted from the container and run on the host or run on a virtual machine which was vulnerable to a VM escape exploit. If it's saved where it's not going to be executed, it is completely harmless.


Exploit failed [unreachable]: Rex::ConnectionTimeout The connection timed out(remote host ip) I keep getting this  when I start to exploit, trying to exploit my xp machine but this keeps happening, I can not find the fix anywhere, I don't believe I am the only one getting this..
I am a beginner, just putting it out there.

  msf exploit(ms08_067_netapi) > exploit

  [*] Started reverse handler on 192.168.47.129:4444

  [-] Exploit failed [unreachable]: Rex::ConnectionTimeout The
  connection timed out (192.168.47.131:445).

I followed this video
https://www.youtube.com/watch?v=6WMbrcGzNbk

You asked this question and it was downvoted before. There could be a lot of reasons for this happening, your question is too broad, and lacks a lot of relevant information. For example, can you ping that host, is it running a firewall, it is vulnerable to that exploit. What you are experiencing is the host not responding back after it is exploited. This could be because of a firewall on either end (the attacking machine, the exploited machine). I would start with firewalls since the connection is timing out. From there I would move and set a different "LPORT" since metasploit tends to act quirky at times. E.g., set LPORT 2468. If that doesn't work, then jump on the metasploit forum and ask there, you'll likely get an accurate explanation.


CloudFlare - prompted for "attention required" I am getting a CloudFlare - attention required / security check prompt on most of the sites I visit through my Macbook running OS X Yosemite, these sites work perfectly on other devices (such as iPad, iPhone, Android and Windows based laptop) connected via the same network/WiFi.

I have tried many anti-viruses and malware scanners but nothing found so far.

Any clues?

Cloudflare has stored cookies from your macbook, you may have used proxy or violated something earlier and cloudflare stored your cookies, and the cookie is same every time you visit. So everytime you visit webs behind cloudflare it says attention. Try deleting browser and system cookies and try that website again.


WiFi Direct/WPS key question So far, I haven't seen any PoC or real-world attacks against WiFi Direct, but I see the potential because it relies on WiFi Protected Setup (WPS) for establishing the connection.

Tools like Reaver already exist to attack WPS during the connection establishment phase and compromise a traditional infrastructure network set up by a wireless router.

But what if someone used Reaver to attack the WPS setup between two devices using WiFi Direct? (like a WiDi or Miracast screencasting session)

Would they be able to eavesdrop on and slurp the traffic of the session?  Would it yield a WPA2 key or passphrase that could be reused to attack the same workstation, set-top box, or whatever again and again?

As a preamble for other readers, note that the WPS vulnerability was made possible because of the way it was designed by the WiFi Alliance, not as a vulnerability with WPA2 itself. A good write-up on the WPS vulnerability is here. In a nutshell, the goal of it was originally to require 100,000,000 authentication attempts to brute-force the 8-digit pin, but the way it was implemented only used the first 7 parts of the pin, and only authenticated the 8-digit pin in halves (first 4 digits of the pin first, then the last 3 + checksum), effectively reducing the brute-force worst-case attempts to 11,000 (10^4 + 10^3).
So with WiFi Direct (also created by the WiFi Alliance), the goal is to get rid of the access point altogether and incorporate it into the computer. Essentially, the system's wireless NIC is able to act as both an AP and a bridge - a feature available in some third-party wireless NICs already (e.g., Alfa cards and their client software). Like you mentioned, the WPS setup occurs between two devices using WiFi Direct. If configured using the PIN-based WPS, then a non-physical attack with Reaver is possible. The other WPS methods (push-button, NFC) will require physical access to the device acting as an AP.
So let's say you've successfully attacked the PIN and retrieved it. "Would they be able to eavesdrop on and slurp the traffic of the session?" Yes, but it would still be encrypted. WiFi direct requires WPA2 or the "latest WiFi security." WPA2 encrypts every session dynamically using the extensible authentication protocol (EAP). If you've cracked the PIN with Reaver and gained access, your next move would be to disconnect and force a re-connect of the connected client. This will force a new exchange of the EAP keys (seen as EAPOL in Wireshark). I believe you need the first half of the four-way EAP handshake to properly decrypt the traffic, but preferably the first 3 or even all four of the packets. You'll need these EAP keys for every session you attempt to decrypt, and remember, every session between every client has a different EAP exchange. Otherwise, even with a cracked PIN, or some other method you use to gain access to the WPA2-protected network, you will still be unable to view the contents of the traffic.
"Would it yield a WPA2 key or passphrase that could be reused to attack the same workstation, set-top box, or whatever again and again?" Yes, if you've configured one. A successful Reaver crack will yield the WPA passphrase anyway.
How do I prevent this? As many people and sites have already pointed out, don't use PIN-based WPS. Go the inconvenient route, even with WiFi Direct, and use the traditional SSID and complex passphrase.


How is the bcrypt algorithm decrypted? I have a ton of hashed texts and their decrypted or de-hashed forms (I don't know which term is suitable in this case) via bcrypt. The thing I want to learn is how they are decrypted.
For example, the second text after the first colon is the salt and the last one is their plain versions.
$2y$12$./BuBOjyTdqysbY1eR7TC.pXlt7ySJW6PKlrfEw9CjnfD3tMHU2v.:lmnsqF0X:lol1234
$2y$12$./gIYLjuH5FborFLHJqT/e3oZ7DgXCfQyfYhjMURDxhW4zek1MHlG:UGMEYL0I:tomek2929
$2y$12$./mcc9eqh8tjRTWDcqkW0OLY6E./taB9gWc7Oz7NzzTibtgEO17Tu:ZFNgWoa5:Greenydon15

As far as I get, 12 is the number of rounds.

Bcrypt is a hash function, not an encryption function.
It cannot be decrypted, in the sense that you send the hash result into a function and get the decrypted version. You can only bruteforce it: send lots and lots of inputs into it, until you get the desired output, or you give up.
According to Wikipedia, this is a Bcrypt string:
$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
\__/\/ \____________________/\_____________________________/
 Alg Cost      Salt                        Hash

The 12 is not the number of rounds, but the Cost Factor, measured as 2x. In case of 12, there are 4096 rounds (212). The $2y indicates that those hashes are created by a bugged Blowfish version.
The only thing you can do it throw the salt and plain text at Blowfish, using the supplied cost factor, and compare the stored hash with the calculated one.


Setting DHCP lease time to very small time increases security? Yes or No? :O

And why?

Depends on the view point, if you're seeing this from the DHCP server impersonating and poisoning attack vector, you are actually decreasing security and the time it takes for the exploit to succeed. You are also increasing the chances of races to succeed on some race condition scenarios. In conclusion, this question is better asked in some specific explicit scenario or attack vector that you're worried about and not as a general rule.


Is this some kind of Bayesian poisoning? So I've been reading my spam lately, and today I received this:

To: my actual email, but with a name found here: tel2name.com  (only hit on Google)

Subject: one seemingly random excerpt of a web page found here:  (only hit on Google) http://firstcommercialcreditcorp.com/commercial-property-values-increase/

citing "RCA" which in this case, refers to: rca nalytics (dot com)

The body itself is an excerpt from this page: http://www.gutenberg.org/files/11226/11226-h/11226-h.htm, one sentence talking about:  Gadsden Purchase, filibustering, and Washington.

What may be the goal of this ? I don't understand what profit they can gain from sending this, because it does not look like Bayesian poisoning ?

Also, the body is: Content-Transfer-Encoding: base64

Without more information (consider pasting the full email to a pastebin or gist), I can't conclusively tell you what that message is, but from your description, yes, that spam is likely an attempt at poisoning.

When you see lots of gibberish or quotes that are nonsensical or out of context, you are seeing either a hash buster or Bayesian poisoning.

Fuzzy hashing systems like Razor measure various characteristics of messages and roll each measurement up into a small string ("fuzzy hash") that can then be compared to fuzzy hashes of known spam.  Matches are assumed to be in the same spam campaign.

Hash busters try to change enough content to prevent a spam campaign's fuzzy hashes from matching.  This technique can work, but some fuzzy hash algorithms are specifically designed to be robust to it, ignoring large swaths of message bodies and even using hashes composed of heuristics indicative of hash busters.

Bayesian spam detection calculates probabilities of spam versus legitimate mail ("ham") based on observed frequencies of each word in ham and spam (e.g. "v1agra" is very spammy but "Niagara" is very hammy).  These are then combined into a spamminess probability for the entire message, which is deemed to be spam at a certain threshold.

Bayesian poisoning tries to add content that is plausible to appear in ham.  The theory is that the spamminess probability would get lowered by the inclusion of a whole bunch of hammy words.  Luckily, this is not actually the case.  Because Bayes is constantly retrained on uncaught spam, it will learn that these distractions are irrelevant and it will place more emphasis on the remaining content seen only in spam.  In most cases, it will actually learn that Bayesian poisoning is itself a sign of spam.

While Bayesian poisoning can be effective at hash busting, it is counter-productive at poisoning Bayesian filters; one of the best anti-spam tools for fighting both hash busters and Bayesian poisoning is:  Bayesian spam detection.

Learn more about Bayesian poisoning


ARP Poisoning: WPA Personal and Enterprise As mentioned in the title, I've questions regarding an ARP Poisoning on a WPA Personal and WPA Enterprise.

I'm gonna do an example (please let me know if I'm wrong):

I need to send the ARP reply to the Victim (C), updating the record of the gateway (A) with the MAC of my machine (B).
Then I need to send the ARP reply to the Router (host A), updating the record of the victim (C) with the MAC of my machine (B).
After that I would simply allow ip forwarding on machine.

So, we should have:
C->B->A
A->B->C

Because, if that is correct, I believe that in WPA Personal, in order to the decrypt the traffic that you have received from the client (victim) you would need to generate the PTK used by the victim (which in this case I believe is possible, because you could generate the PMK having the PSK. Then sniff ANonce, SNonce, AP_MAC, CLIENT_MAC and generate the PTK).

Again, if what I've said is correct, how would be possible to decrypt the traffic of the WPA Enterprise that has multiple passwords, making therefore not possible to generate the PMK?

Because, if that is correct, I believe that in WPA Personal, in order to the decrypt the traffic that you have received from the client (victim) you would need to generate the PTK used by the victim

If you are doing ARP poisoning in the manner you suggest, the only encryption on the traffic is between your machine and the AP. You don't need the victims PTK at any point.

While your traffic flow illustrates the logical flow of data, the physical flow of data is somewhat different (V = victim, A = attacker, GW = gateway, AP = access point) with the inverse for return traffic:

V -> AP -> A -> AP -> GW

802.11 encryption is only between the client and AP so since you are not intercepting the flow of data from V -> AP, you don't need to decrypt that data. The flow from AP -> A you will be able to decrypt in either WPA-Personal or WPA-Enterprise as this will be using the PTK generated between AP and A during the association process.

  Again, if what I've said is correct, how would be possible to decrypt the traffic of the WPA Enterprise that has multiple passwords, making therefore not possible to generate the PMK?

You weren't entirely correct, but if you were trying to decrypt V -> AP traffic and WPA-Enterprise were used, you would be out of luck unless the EAP method employed was broken and leaked information.

At the point of the 802.1X authentication, the client is not associated to the network and doesn't have any IP information. There is no way ARP poisoning from a wireless client in this scenario will affect the 802.1X traffic.

Edit: I meant to also mention that if the AP is also the GW (i.e. most consumer based wireless gateway devices) then this type of attack may not be possible. As L2/L3 devices they may very well recognize that a packet to the gateway is destined to a L3 interface on the device itself and not for another L2 device and route it itself.


What are the reasons why TLS certificates are not issued or revoked? I'm curious what threshold is used for CAs to issue / deny issuance / revoke TLS certificates.

As far as I understand they are essentially identity guarantees, so if JunkCorp can't prove they are who they say they are, then they won't get a certificate.  Or if JunkCorp's website is hacked, then perhaps their certificate will be revoked.

Are there other aspects that are taken into account? (illegal/malicious activities)

While each CA does have their own policies and procedures they follow regarding when to issue and revoke certificates, there is a common set of Baseline Requirements which all publicly trusted Certificate Authorities are required (by browser vendors) to follow.

The Baseline Requirements specify the following list of conditions under which a CA must revoke a certificate:

  4.9.1.1. Reasons for Revoking a Subscriber Certificate

  The CA SHALL revoke a Certificate within 24 hours if one or more of
  the following occurs:

  The Subscriber requests in writing that the CA revoke the Certificate;
  The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant
  authorization;
  The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key
  Compromise or no longer complies with the requirements of Sections
  6.1.5 and 6.1.6;
  The CA obtains evidence that the Certificate was misused;
  The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of
  Use;
  The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no
  longer legally permitted (e.g. a court or arbitrator has revoked a
  Domain Name Registrant’s right to use the Domain Name, a relevant
  licensing or services agreement between the Domain Name Registrant and
  the Applicant has terminated, or the Domain Name Registrant has failed
  to renew the Domain Name);
  The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified
  Domain Name;
  The CA is made aware of a material change in the information contained in the Certificate;
  The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or
  Certification Practice Statement;
  The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
  The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the
  Certificate;
  The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made
  arrangements to continue maintaining the CRL/OCSP Repository;
  The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
  Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
  The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties
  (e.g. the CA/Browser Forum might determine that a deprecated
  cryptographic/signature algorithm or key size presents an unacceptable
  risk and that such Certificates should be revoked and replaced by CAs
  within a given period of time).

Source: Version 1.4.9 of the CAB Baseline Requirements.

Be aware that these requirements only say when a CA must revoke a certificate. They do not restrict CAs from revoking certificates for reasons not in this list. Individual CAs may have their own policies which specify other conditions under which they may revoke a certificate.

As for when a CA will refuse to issue a certificate, that question is much more complicated to answer. The main reason why a CA would be required to refuse to issue a cert would be when the person or organization requesting the certificate cannot prove they are who they say they are. The details of what sort of identity proofs are required, and other conditions under which a CA must refuse to issue a certificate are, again, specified in the Baseline Requirements.

As far as I am aware, the Baseline Requirements do not require CAs to monitor whether the people or organizations they are issuing certs to are using them for illegal activities. Law enforcement is not within the scope of a CA's responsibilities.


Sky Broadband Shield I was just wondering about the implications of Sky's new revelation of a so-called 'shield'. Is this actually even a security feature or just an advertisement stunt for Captain America? I can find very little information on this (maybe I am looking in the wrong place) but it seems this is just a URL filter that all ISP's employ anyway.

Is Sky just giving users a false sense of security or is this actually a next-gen security product of some kind?

It appears to be the name they're using for their content filtering system. I think they provide enough information to establish that, once you understand that ISPs are trying to get out ahead of legal regulation.

The main indicator to me is the fact that it's on by default, which is exactly what Cameron demanded. If you know what Sky broadband had before (I don't) then you could make a more detailed comparison of what has changed vs. what's in the proposed legislation.

Yes, ultimately it's a URL, domain and IP address filter, but it's broader in scope than the ones ISPs have previously used.

The people who've voted for the Online Safety Bill in its readings to date, probably think it's a next-gen security product. I have some doubts personally.


Is it possible to exploit PHP unserialize without classes? I'm assessing the security of a webportal for a client and I found a vulnerability. The code is basically doing this:

$var = unserialize($_REQUEST['something']);

I have complete control over variable. But there are no classes in the server's code, it doesn't have much controllable __destruct, __wakeup etc. objects.

Can I still do something with this? Like maybe setting a $_SESSION variable? Is it possible? Any RCE or BoF or something?

It depends on your version of PHP.  Using unserialize to find weaknesses in the application is dependent upon the application having vulnerable classes.  If they don't have any classes, then the application is not vulnerable.

However, you may be in luck!  I don't actually use the PHP serialization myself because in the past it has been very buggy, with severe security vulnerabilities from PHP itself.  I'm not personally familiar with the exact details, and it does depend on the PHP version (which obviously you don't know), but there is a high enough risk that for someone performing security auditing, the answer is legitimately "NEVER pass user data into unserialize".  For the wrong versions of PHP, the result can be a serious disaster.

You have to really know what you are doing to take advantage of said vulnerabilities, but what you end up with is a remote code execution vulnerability in the PHP interpreter itself, which gives the attacker a much bigger prize.  Here is a very detailed run-down of the vulnerability in PHP 7.  This obviously isn't directly applicable to you, but it shows that the vulnerability is real and it doesn't depend on the user having defined classes:

https://blog.checkpoint.com/wp-content/uploads/2016/08/Exploiting-PHP-7-unserialize-Report-160829.pdf

Also some very basic information:

https://www.cisecurity.org/advisory/vulnerabilities-in-php-unserialize-function-could-allow-remote-code-execution/


How to implement magic link sign in with oAuth2 We have two web applications. One is developed in Django, let's call it portal (oAuth2 provider). Another is developed in PHP, let's call it client.

We want to display a link for authenticated users on the portal website, so that by clicking the link the user is automatically signed in to the client website. No password asked, the client website should open and the user should be already signed in on the client website.

Is it possible to implement such a magic link using oAuth2 or we have to create our own solution?

Yes you could use OAuth2 for this szenario, however I think  that OAuth2 is a little too much overhead for this particular use case.

What you basically want is a JWT (Json Web Token). After authenticating against the portal, it creates a JWT-token. This token contains some information about the user, maybe his username / mail and his permissions. Also, this token gets signed with the private part of an asymmetric keypair - only the portal knows this private key. When accessing the client-application, you pass the token as an http-header (probably the authorization-header) with the request. Your client-app knows the public part of the asymmetric keypair so it can verify the token. When the token is verified and not expired, the user is authenticated in your client-app. Here you could also check some permissions which are included in the token.

You can read about JWT here: https://jwt.io


RDP - Same login sufficient? I just authorized remote access to my Windows 7 machine (not using NLA, since I run a mainly Linux network). I diabled Remote Assistance.

My user (JoeBlow) is protected with password 123456 and autologon is not enabled.

When I connect from a Linux (Ubuntu) box, with a local user named JoeBlow, using password 0987654 (or anything else, it doesn't matter) through KRDC, it logs me directly in JoeBlow's windows session, without prompting for a password.

Did I miss something on the Windows setup side, or is RDP built in such a way as to allow anyone impersonating a user on a network to hijack the session?

It's not normal behavior for it to just log you in by username.

My best guess is that you have the password saved either in the RDP program or your gnome keyring or something like that.

An easy way to test would be to change the password on the windows machine and see if it starts prompting you for a password again.


can i execute javascript in href when i have text before my input? This is where I took this example from:
<a href="<?php echo $_GET['e'];?>">Back
In this code, I can do http://my_url?e=javascript:alert()
But what can I do if my code is like this:
<a href="e<?php echo $_GET['e'];?>">Back

Yes
If the data you inject is arbitrary and not filtered at all, you could inject "><a href="#
This will end up with the following DOM elements:
Back


`rsync -K`-based exploit In the description of the -K (--keep-dirlinks) flag, the rsync man page gives this warning (my emphasis):

  One note of caution:  if you use --keep-dirlinks, you must trust all the symlinks in the copy!  If it is possible for an untrusted user to create their own symlink to any directory, the user could then (on a subsequent copy) replace the symlink with a real directory and affect the content of whatever directory the symlink references.  For backup copies, you are better off using something like a bind mount instead of a symlink to modify your receiving hierarchy.

I've read the highlighted sentence several times, and I still cannot picture the exploit it refers to.

Could someone give a fleshed out example of the exploit?  (Please include an explaination of how a "bind mount" avoids the problem.)

FWIW, this is my understanding of what the -K option does.

For example, if the initial state is this:

sender:/path/to/sourcedir
└── foo/
    └── file

receiver:/path/to/targetdir
├── bar/
│   └── stuff
└── foo@ -> bar/

Then, after rsync sender:/path/to/sourcedir/ receiver:/path/to/targetdir, the receiver will look like this:

receiver:/path/to/targetdir
├── bar/
│   └── stuff
└── foo/
    └── file

(Note that foo is no longer a symlink.)

After rsync -K sender:/path/to/sourcedir/ receiver:/path/to/targetdir, on the other hand, it will look like this:

receiver:/path/to/targetdir
├── bar/
│   ├── file
│   └── stuff
└── foo@ -> bar/

You are correct on the use of the -K option.  But the exploit is about having different users performing the link creation and running rsync.  Let's first see some rsync -K in action.  Make some test dirs:

[me] $ mkdir a b c b/from b/from/mydir c/to
[me] $ touch a/bar
[me] $ touch b/from/mydir/foo

And run the plain rsync

[me] $ rsync -avK b/from/ c/to
sending incremental file list
./
mydir/
mydir/foo

sent 135 bytes  received 39 bytes  348.00 bytes/sec
total size is 0  speedup is 0.00
[me] $ find c/to/
c/to/
c/to/mydir
c/to/mydir/foo

And let's clean c before a new test:

[me] $ rm -rf c/to
[me] $ mkdir c/to

Now, imagine that I give some other user the rights to write into c/to and b/from.  To make things simple let's say that the following chgrp will allow a bunch of people to write in there:

[me] $ chgrp -R students c/to b/from

And a clever student performs this:

[student] $ ln -s ../../a c/to/student_dir
[student] $ mkdir b/from/student_dir
[student] $ echo 1337 > b/from/student_dir/bar

The next morning I run rsync and:

[me] $ rsync -avK b/from/ c/to/
sending incremental file list
./
student_dir/
student_dir/bar

Ouch! My file inside a that I never gave permission to anyone to modify has changed:

[me] $ cat a/bar
1337

And, since rsync is commonly used for repetitive tasks such as cron jobs there is a good chance that this would even go unnoticed.

In simple words the exploit can be argued to be that: a user that has access to the sender (from) and receiver (to) sides of a recurrent rsync job acquires the privileges of the user running the rsync job.

Don't run rsync -K as root!


Where to store IV and salt when doing clientside encryption with no server I'm making a chrome app that does client side encryption of user messages.
There is no server in my architecture.
The encrypted text messages are saved as files in the user's Google Drive.
I'm using forge javascript library to encrypt the messages.
I want the user's password to be used for encryption and decryption, without saving it anywhere.

Currently I have the salt and IV hardcoded into the javascript code. But that means it's available to anyone who installs the chrome app.
Is it better to generate a random IV and salt for every message, and save it in the user's Google Drive along with the encrypted messages?
Or is it good enough to have it hardcoded as a js global?
Is there a more secure way of doing this?

In every protocol I've seen, the IV and/or salt is not considered secret, and is stored with the ciphertext. It is usually important to use a unique IV/salt for each message, though. (It is often not necessary for them to be unpredictable— just not reused.) However, each mode's requirements might be a little different.