SSL is based on public/private key cryptography. This means that

anything encrypted with a public key can only be decrypted with the associated private key
the private key can be used to sign a something and that signature can be verified with the public key.

A certificate is a public key with information about the owner attached to it. The owner can either be a person or a domain.

When you visit https://stackauth.com, the server will present its certificate to your browser. The browser checks that the name in the certificate matches the name of the website you requested and if the expire dates are valid.

Then the browser checks whether the certificate was signed by a certificate authority that the browser knows as trustworthy. Anyone who creates a faked certificate has the challenge to get it signed by a certification authority that is trusted by the browsers. There may be a chain of signatures from intermediate certificate authorities which needs to eventually lead to a trusted one.

If any of those checks fails, the browser will show you a warning and require confirmation. If all the checks are passed (or overridden by the user), the browser will use the public key from the certificate to encrypt some information that only the server can decrypt. This information is used to setup a secure session in a couple of more steps.

The main issues with this model is that the certification authorities are the weak link. There is a huge number of CA, that are directly or indirectly trusted by the common browsers. All of them can issue faked signatures, and this has allerady happened a number of times in the past (e. g. Verisign, Comodo, Diginotar).


Diffie Hellman parameters still calculating after 24 hours

Maybe it is starving for entropy. Try to see how many bit it has in the pool

cat /proc/sys/kernel/random/entropy_avail

If it has indeed not enough bits it is often enough to smash on your keyboard or start a network operation. If it still cannot gather enough try with haveged


An attacker can get the url endpoints and may post spam data

Do you have some means of telling an attacker from a legitimate user?
(Rate of posting, content of post, etc.). Imagine being the server app, and you see a request coming in. Can you tell whether it is legitimate or not?
If yes, then use them - move that reasoning into your application logic. Better still, add this information to your question so you might get further suggestions and insights.
If not, then unfortunately your answer is "You cannot secure your URL endpoints" (because "secure" implies "distinguish between good and bad guys") and you need to look into things like logins, cookies and/or client certificates.
authenticating an application
You need to add something to the application that an attacker can't easily replicate. This requires making assumptions against what an attacker can and can't do.
No one can defend against an omnipotent attacker. So, you cannot say "I want to defend against anyone". You can only defend against someone that cannot do something that your application can.
So, if the attacker has full access to your application source code and secrets, and therefore can learn to do whatever your application can, again you cannot defend against them.
In Android and iOS, there are "secret areas" that you can interface with, and allow doing something an attacker can't. Basically you establish a secret in the protected area, then ask whoever connects to prove they know the secret. This too is imperfect because you're only authenticating the device, not the application.
If the attacker does not have access to the source code, then you can use a classic challenge/response scheme, where the application contains (either the same for all clients or one assigned to each client) a secret string. All calls are GETs for clarity:
The app has a secret and it is "001:MySecret001".

App --> "application/login?auth=001"  --> server
          <--- "tell me the answer to: 2020-07-21-13:36:35-Qa9XtFtp"

App retrieves its secret, it is "MySecret001", calculates the hash
   of the string "MySecret001,2020-07-21-13:36:35-Qa9XtFtp"
   and sees that it is `57703859adcdb4239e513dd7fe991afe`. So...

App --> "application/login?auth=001&challenge= 2020-07-21-13:36:35Qa9XtFtp&response=57703859adcdb4239e513dd7fe991afe"

The server verifies that the response is indeed the hash of the challenge, and that the challenge timestamp is not too old. Then it retrieves the secret for user 001, and sees it is MySecret001. It does the same calculation the client did. If the two hashes are the same, the client is legitimate.
This, as I said, requires that the attacker cannot crack the app and see what the secret is and how it is manipulated.
The login/password scheme is identical, except that login and password are in the head of the user.
authenticating a request
We still (see above) need that the attacker cannot see the application source code. When this is the case, you can modify (maybe using a filter, which is possible with e.g. jQuery) the request, adding a header or an extra variable:

suppose the request is "cmd=add&text=HelloHello&subj=HelloWorld"
you sort the request dictionary in alphabetic order:

cmd = add
subj = HelloWorld
text = HelloHello

you take the secret, or a random string the server sent the application on the first request (called "nonce") and initialize "hash" to this value
for all elements in request:

hash = MD5(MD5(hash + key) + value)

you add "hash=(whatever)" to your request.

The server receives a request, saves "hash", knows the secret shared with that client, and can therefore repeat the calculation and see whether the hash value matches.
An attacker that does not know the initial "secret" value now cannot send arbitrary commands, because they don't know the appropriate value of the hash for that particular command.


How to supply OpenSSL generated Private & Public Keys to iOS & Android apps?

Not entirely sure what you're asking; if your apps natively support a specific format, use that. Is there a specific app you'd like to ask about?

If you just want a simple format for apps you're writing, the OpenSSH format is nice and simple (and widely used / supported). Also X.509 certificates are a little more complicated, but also widely supported, though that might be a bit beyond the scope of what you're trying to do (X.509 is a full spec for PKI [Public Key Infrastructure] and PMI [Privilege Management Infrastructure]).

OpenPGP also has free implementations (gnupg), and has good library support / a nice key format (when using ascii armoring).

[OT]:
On a semi-offtopic note, generating the private key server-side and then giving it to the client is almost always a bad idea that defeats the purpose of public/private key crypto. Instead you should pre-seed the clients with the servers public key, generate a private key on the client, use the servers public key to verify the connection (if you're already using TLS you've done this part) and then send the server the client's public key. Also, if you're already using TLS I'm not sure why you'd need another layer, then again, I don't know what use case you had in mind.

Examples

To get an example of each key on a Unix/Linux system:

OpenSSH: ssh-keygen -t rsa -b 2048 -f filename

GnuPg: gpg --keyserver pgp.mit.edu --recv-key 0xEC2C9934 && gpg --armor --export 0xEC2C9934 (will download and display my public key)

X.509: openssl genrsa -sha512 -out keyfile.key 2048 will spit out a private key.
You can then generate a certificate signing request using openssl req -new -key keyfile.key -out keyfile.csr and finally a certificate: openssl x509 -req -days 1 -in keyfile.csr -signkey keyfile.key -out keyfile.crt

Final Thoughts

After reading the comments, it seems you're looking for more of a full solution. If I understand what you want, I think the ideal solution would be to use X.509 certificates. You could either create your own CA (Certificate Authority) or purchase a certificate from a trusted third party online (I like RapidSSL). You can then have your apps verify communications from the server, and use ECDH (Eliptic Curve Diffie–Hellman) to negotiate a shared key and facilitate secure communications (You said you wanted small footprint, so I figure ECDH will be faster than normal DH). AES256 for encryption and SHA2 for message digest verification should give you a secure, well supported, and reasonably low overhead connection. Basically just use TLS and make sure you choose good options for the encryption type, key exchange mechanism, and message digest function.


How does this header handling work with CloudFlare?

From what I understood, it's pretty simple:

  X-Forwarded-For

  X-Forwarded-For is a well-established HTTP header used by proxies,
  including Cloudflare, to pass along other IP addresses in the request.
  This is often the same as CF-Connecting-IP, but there may be multiple
  layers of proxies in a request path.

  Two possible outcomes.

  First, if there was no existing "X-Forwarded-For" header in the
  request sent to Cloudflare, then the header would have an identical
  value to the CF-Connecting-IP header, like this:

  "X-Forwarded-For: A.B.C.D"

  where A.B.C.D is the client's IP address, also known as the original
  visitor IP address.

  Second, if there was an "X-Forwarded-For" header present in the
  request sent to Cloudflare, Cloudflare appends the client's IP to its
  value, as the last in the list.

  "X-Forwarded-For: A.B.C.D[,X.X.X.X,Y.Y.Y.Y,]"

  where A.B.C.D is the client's IP address, also known as the original
  visitor IP address. X.X.X.X and Y.Y.Y.Y in this example are IP
  addresses along the route in the header value.

when you don't add the X-Forwarded-For header, CloudFlare will implicitly add it with the visitor's real IP address.

When you manually add with that header to your request another IP, the IP will be correctly spoofed in condition that Forwarding-For option is allowed from your server, and you'll be a trusted forwarder. To block X-Forwarded-For you can use iptables, or other.

In some cases, this header can be relevant to website's security.

  X-Forwarded-For HTTP header should not be used for any Access Control List (ACL) checks because it can be spoofed by attackers. Use the real IP address for this type of restrictions.


Alternative to charging 2 small amounts for credit cards authentication?

If the card has been stolen, it should have been cancelled. Alternatively, it should be on a blacklist and flagged as such if your client is doing any fraud analysis.

The current process for authenticating a user does sounds rather laborious for clients. It should be possible to perform a null value pre-authorisation of the card. This means that for the initial authorisation, the PSP/acquirer will require the PAN, expiry date and CVV2 of the card. After the card has been authorised, future transactions can be performed against this card using the PAN and expiry date only.

The methods for the above to work are dependent on your acquirer or Payment Service Provider. It's worth discussing possibilities with them or reading their API documentation. To reduce fraud rates, you could also [where possible] push users to use Verified By Visa/MasterCard during the authorisation process.


Mallory doesn't want Alice's session id.  Mallory wants Alice to perform actions as herself, but while the website thinks she's Mallory.  Like use her credit card to buy something she thinks she'll get, but which will actually be credited to Mallory.

There are several vectors for this attack. The one you mention, cookie-less sessions with the session id in the URL is one.  Mallory having control of a sub-domain and being able to write cookies for a parent domain is another.


What is the best book on threat modeling that you've read?

The Art of Software Security Assessment gives a nod to UML class diagrams as a design generalization assessment approach.

For one of the most interesting techniques on this (that Cigital adopted for their "threat-modeling" approach) is from a book called "Applying UML and Patterns", where it covers Architectural Risk Analysis.

Rohit Sethi also started a project for OWASP called "Securing the Core JEE Patterns". It's only a short paper, but definitely the coolest thing I've ever seen in the threat-modeling world.


Is Meltdown/Spectre mitigation necessary in virtual machine as well as in hypervisor?

Q: .. do the host as well as the guest need to have Meltdown/Spectre mitigation enabled?

Yes

When these vulnerabilities announced, QEMU posted on "QEMU and the Spectre and Meltdown attacks":

  Right now, there are no public patches to KVM that expose the new CPUID bits and MSRs to the virtual machines, therefore there is no urgent need to update QEMU; remember that updating the host kernel is enough to protect the host from malicious guests. Nevertheless, updates will be posted to the qemu-devel mailing list in the next few days, and a 2.11.1 patch release will be released with the fix.

  Once updates are provided, live migration to an updated version of QEMU will not be enough to protect guest kernel from guest userspace. Because the virtual CPU has to be changed to one with the new CPUID bits, the guest will have to be restarted.

  (05/01/18 — by Paolo Bonzini and Eduardo Habkost: source)

The updates have been available, so, you should proceed with them and enable the mitigation as well on guests.

By QEMU Article "QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM guests":

  What is being addressed here is enabling a guest operating system to enable the same (or similar) mitigations to protect itself from unprivileged guest processes running under the guest operating system.

  Enabling mitigation features for x86 KVM guests:

  For x86 guests there are 2 additional CPU flags associated with Spectre/Meltdown mitigation: spec-ctrl, and ibpb:

  spec-ctrl: exposes Indirect Branch Restricted Speculation (IBRS)
  ibpb: exposes Indirect Branch Prediction Barriers

  Utilizing this functionality requires guest/host kernel updates, as well as microcode updates for Intel and recent AMD processors. The status of these kernel patches upstream is still in flux, but most supported distros have some form of the patches that is sufficient to make use of the functionality. The current status/availability of microcode updates depends on your CPU architecture/model. Please check with your vendor/distro to confirm these prerequisites are available/installed.

  (14/02/18 — by Michael Roth: source)


Do SSL/TLS clients warn on weak keys/hashes regarding self-signed certificates?

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


How to know if an ASP web page is vulnerable to SQL injection?

Sorry, I want to expand a bit on your thought process.  It's not just an ' at the end.  I mean, that's a good, quick of finding a decent percentage of the holes.

Let me give an example of a vulnerability that this approach wouldn't find:

url: http://www.somesite.com/page.asp?name=kevin&status=live

--- code behind the scenes: ---
string table = "history"
if (status == "live") table = "current"
string sqlCmd = "select * from " + table + " where name = '" + name + "'"

... see the problem?  The last parameter in your url specifies the status, and the code is simply using a "is it X or not?" logic to it - it doesn't inject the actual value into the SQL statement, so it's not vulnerable.  But the other parameter is inserted into the SQL statement raw - which makes it vulnerable to injection attack.  So while:

http://www.somesite.com/page.asp?name=kevin&status=live'

... wouldn't have an error, this would:

http://www.somesite.com/page.asp?name=kevin'&status=live

So, realistically, if you're going hunting for SQL injection vulnerabilities, you need to try all the parameters in the URL - even parameters that are optional and sometimes aren't specified.

Final point - if you have access to the source code, it's easier to find this sort of stuff by actually looking at the code.  Basically, if you're building raw SQL statements and then calling EXEC, you've probably got problems.


Why should I use easy-rsa when using OpenVPN?

Because key based authentication is a lot more secure than username/password based authentication because it's nearly impossible to bruteforce. By bruteforce I mean, try all possibilities untill you find the correct one which let's you login. Generally the harder it is to find the right username/password combination, the more secure your system is.

For example:

You use a username like: aH#398x*t$
And you use a password like: %ygo74Xg2&

So both are 10 characters, completely random. You use lower case, upper case, numbers and special characters, so for every character there are 95 possibilities (ASCII). This would make the complexity to bruteforce the username 95^10, to bruteforce both the username and password the complexity would be 95^20. So 95^20 = 3.58*10^39.

If you use standard key based authentication with 2048 bit RSA keys (2^2048 roughly equals 10^616) then this means if you have to bruteforce it, you will have to try all possible RSA keys. This effectively means trying all prime numbers of size 1024 bit. You can roughly estimate how many prime numbers there are with the following formula: n / ln(n)

2^1024 / ln (2^1024) roughly equals 10^310.

So if an attacker wants to attack your system he would need to bruteforce either 10^39 or 10^310 possibilities. Say an attacker is capable of an offline attack, then quite an average videocard is already capable of trying 10 billion possibilities per second. Quite often it is possible to find out what the username is, so he would only need to bruteforce 10^19 passwords.

10^19 / 10^10 = 10^9 seconds = 31 years with an average desktop computer.

So it is feasible for an attacker to crack this in a short amount of time if he has enough computers available.

But 10^310 is nearly impossible to bruteforce because the number is so huge. To get the same security you would need a random password that is about 156 characters long. (10^310 = 95^x)

So this is why almost always keys are adviced for vpn / ssh. It's on a completely different level of security than passwords.

EasyRSA is a tool included with openvpn to make the generation of RSA keys easier for you. But RSA keys generated with OpenSSL or other crypto tools will work perfectly fine with openvpn too.

This stackoverflow answer explains the amount of prime numbers in RSA keys some more:
https://stackoverflow.com/questions/16091581/how-many-prime-numbers-are-there-available-for-rsa-encryption

A more mathematically accurate side note: 10^310 is merely the number of primes in that key space. There are more efficient algorithms than merely bruteforce trying all prime numbers. The currently fastest known method of factoring is GNFS.

exp(((64/9)^(1/3))(log(2^2048))^(1/3)(log(log(2^2048))^(2/3)))

512: 63.9 bit
1024: 86.7 bit
2048: 116.8 bit
4096: 156.5 bit
8192: 208.4 bit
16384: 276.5 bit

So for a 2048 bit prime number, instead of having a 1029 bit (2^1029 = 10^310) complexity, you'd only have to attack 116.8 bits.

10^116.8 = 95^x -> x= 59

So a 59 character random password would have equivalent security to a 2048 bit RSA key with current factorization methods.


Can SIP registrars and VOIP providers eavesdrop?

When you do a call from SIP to a regular phone line, somewhere in the middle it will exist a gateway which translates the phone call from IP network to a PSTN. So it is doable someone in the middle intercept the communication (in the IP network or PSTN), at least, to lawful interception.

Only if two SIP peers call directly is less possible the have a eavesdrop.


Does Tor Hidden Service Protocol provide more threat protection than a standard HTTPS session?

makerofthings7 wrote:

  it seems TOR is better/more secure since it doesn't use DNS, and it doesn't rely on CAs

Just as it's ultimately the user's responsibility to verify a TLS certificate before accepting it, it's the user's responsibility to verify that an onion address is the intended address. By starting with

(a) I know an onion address
(b) I know a regular domain name (f.ex. "google.com")

you are stating, by hypothesis:

(a) I have solved a tricky problem
(b) I have yet to solve a tricky problem

and (a) directly implies more security than (b) because of the stronger hypothesis.

But stating (a) actually means "I know how to solve tricky problems" so you should be able to also solve (b). IOW, if you can reliably obtain an onion address (f.ex. over the phone from someone whose voice you know), you should be able to reliably obtain a TLS certificate fingerprint of the website by the same provider.

But you are probably relying on some Internet resource (website, Usenet message, email...) to learn the onion address:

(1) do you trust the claimed author of the message?
(2) do you trust that the message was really written by this author?

Maybe the message was found on an HTTPS website, and you are back with:

(a) verifying that the owner of the website is the person you trust
(b) the website you see is the real website, IOW that the TLS certificate is valid.

Maybe the message was found in an email, and you have to check the PGP/GPG (or S/MIME) signature. Then you are back with: who owns this PGP/GPG/S/MIME signature? In any case, you need a trust anchor.

No cryptographic protocol or tool alone solves this problem, because it isn't an algorithmic matter, it's a matter of fact checking, facts like "this key really belongs to this person", and in most cases trusting others to do the fact checking, unless you can meet the guy in person and ask him his key fingerprint, which honestly is rarely the case (I tried with my bank and they had no idea what the fingerprint of the key was).


iOS app - hash user password in-app or on-server?

Use SSL to handle the communications over the internet safely, then hash the password it on the server. Otherwise the password hash just becomes the password, as far as the service is concerned, and an attacker that gains access to your database can log in as any of your users as if their passwords were stored in plaintext. SSL is vital in order to prevent your users' credentials from being intercepted on the network.


If the attacker and the valid AP are transmitting packets with significantly different RSSI (e.g., they are in different proximity from the client, or actually transmitting with different power levels, or there is an obstacle between one) then it is possible to fire-up t-shark or wireshark filter out the packets that come from APs with a given MAC address (both valid and malicious) and store the signal strength field. Then do conduct statistical analysis over time (e.g., median or better something more complex) and note whether the measure significantly deviates from normality. This MIGHT be an indication of something wrong e.g. presence of a fake AP, including MITM attack an Evil Twin etc.

With that being said if you try to replicate such an experiment you will immediately notice that the RSSI significantly fluctuates even if the experiment parameters relative location of the devices are unchanged. You will definitely need to apply all your statistical/ML knowledge to distinguish normal from abnormal traffic.


Anatomy of a very creative .txt virus/trojan. How does it work?

The other answers are basically correct, but are missing the key element:

A weird legacy behavior in cmd.exe is that when you give it a file as a command (either via the /c parameter or by just typing the file name into the interactive shell), the first thing it does is call CreateProcess on that file. CreateProcess is the Win32 API to launch a program, and it does not care about the file extension; it only cares whether or not the file is executable code and has Execute permission (which all Windows files have, by default). Only if CreateProcess fails does cmd fall back to ShellExecute, which takes an action based on the file extension and registered handler.

As the other answers noted, your ".txt" file is actually a Windows PE executable binary (basically, a renamed ".exe" file). If you ran it on your machine, there's a pretty good chance your system is now compromised by malware.


Honeypots are used by network admins so that when someone attacks their "honeypot" server behind the firewall, they can get information about the hacker while saving the real hardware/servers from attack. See the Wikipedia article here: https://en.wikipedia.org/wiki/Honeypot_(computing), there's a pretty useful diagram that explains the concept better than I can. As far as a better name for this, it seems like more of a case of forensics than a specific type of attack.

As far as legality, it is legal for you to see who has accessed a webpage you own. Your spy in the sandbox/javascript/image payload approach seems vastly over-complicated when you could just host your own webpage and see who connects to it.

If you're looking to gain more information on the target, you might be interested in browser fingerprinting. The Mozilla wiki has a good article here: https://wiki.mozilla.org/Fingerprinting

Basically the idea behind it is that people using certain browsers and operating systems can be tracked by a very specific "fingerprint" of identifying information. JavaScript in general can be used to gather a significant amount of information on a target, and this can be particularly dangerous when all of that information is combined to form a unique signature.


In a critical environment where you are introducing new devices which will be conforming to new, looser rules, it might be worth having an entirely different network 'air-gapped' - i.e. these new devices being completely separated from your existing infrastructure.  Many of the measures you take, such as a firewall, anti-virus, and group policies, will be the same as for existing computers.  The Internet itself is not scary, and having access to it does not mean immediate infection, but it will increase your potential attack surface.  You said restrictions need to be looser, but that does not mean they have to be lifted completely:

Users probably don't need to install programs (if they do, you could do this manually as an admin, infrequently)
Users probably don't need external mail (you said they do, but I see no reason why they would need e.g. GMail?)
Users shouldn't have admin access to their computer
etc.

It may however be worth getting a professional in to evaluate your systems and use case, where you act as project lead.  The contract for that will likely be considerably cheaper than the potential cost of infiltration.


Allowing a website MIDI access from Chrome

It is mostly safe, unless a new exploit has been found recently.

You're right to worry. There have been exploits using MIDI, like this one in Windows, and this one in Chrome, both of which were particularly nasty. They've both been patched for some time, but you never know when a new attack will be discovered.

Personally I wouldn't allow it unless I really wanted to hear the music-- and given that it's MIDI and not WAV or MP3, it is probably pretty horrible.


If you have control over the environment in which the application runs — basically, if you have access to the account under which the application runs — then you can observe everything it does. Simply run the application under a debugger and put a breakpoint or a trace on calls to CryptGenRandom.

If you don't have control over the execution of the program, then you can't capture the output of this or any other function. The alternative would be to predict the output. You can't predict the output of CryptGenRandom, because it's a crypto-quality random number generator and it isn't implemented so badly as to be completely broken. The whole point of crypto-quality randomness is that it's unpredictable. The only way to predict the value would be to have access to all the sources of entropy of the machine and to know all the times when CryptGenRandom is called so that you can recreate the state of the RNG. In practice, if you can do that, you can run a debugger.


It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password).

If you think of your salt as something that may be shared between passwords, but must not be known to the attacker, then that is not a salt; that's a key. Some people call such keys "pepper" in the case of password hashing. This is a concept quite distinct from salts, and, generally speaking, it adds complexity and increases failure frequency without really improving security. Get the basics right first (i.e. using the right function with proper salts).

The normal method is to store the salt along with the hash value. Preferably, you let the password hashing library generate the salt and handle the encoding of the salt and hash value as a single string. So you make sure that you use PHP 5.5 (or newer), and you use password_hash() (and don't use the manual salt setting; the library does the right thing by default, so just let it do it). Among possible password hashing functions, bcrypt is about the best you can have right now, and that's what password_hash() will use.


Figure out if "correct" encryption algorithm was used

If you have the keys (and other parameters, e.g. IV), you could just decrypt the data. That would tell you that the right algorithm was used.

If you don't have the keys, then it's very unlikely. If you could do so, you'd be performing a distinguishing attack. There are known distinguishers for some common ciphers (e.g. RC4) but not for others (e.g. AES). The existence of these usually implies that the cipher is flawed in some way.


Which attacks are known that exploit the vulnerability known as Spectre?

From the reports I have seen, there are no publicly known attacks (other than the proof of concept demos) using these methods. That being said, there is no real way to know for sure someone didn't find these problems and was very careful about leaving traces in their attacks. I'm sure various government would have kept quiet about these methods and used them to enhance their own cyber capabilities. Moving forward, I am sure there will be lots of people trying to exploit these methods against vulnerable systems.


How severe are the interestingly disclosed AMD flaws?

Quotes from the rather detail-free whitepaper:

Exploiting MASTERKEY requires an attacker to be able to re-flash the BIOS with a specially crafted BIOS update.

Exploitable only if you've got the BIOS manufacturer's signing key (if they use one), have written a custom BIOS for the computer being targeted, and (generally) have physical access to the machine.

Exploitation [of RYZENFALL] requires that an attacker be able to run a program with local-machine elevated administrator privileges. Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed.
Exploitation [of FALLOUT] requires that an attacker be able to run a program with local-machine elevated administrator privileges. Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed.
Prerequisites for Exploitation [of CHIMERA]: A program running with local-machine elevated administrator privileges. Access to the device is provided
by a driver that is digitally signed by the vendor.

So, at a minimum, you already need full control of the computer and a third party's signing key to exploit these vulnerabilities.  Might be useful for a state-level actor trying to install an undetectable keylogger or the like, but the average person isn't at increased risk because of them.


Where do live threat maps get their threat-data from?

... serving accurate information ...

I doubt that these information are accurate. There is some truth in it based on what vendors see from honeypots, from installations at customers and from public available data but the vendors don't really see or know everything.

The main point of such threat maps is to make it clear that there is sufficient danger on the internet in order to either sell more security systems or to justify the money already spend for existing installations. This also means that there is no need that these threat maps are fully accurate. They could even make up some data and nobody will really notice since nobody has the full picture.

In order to protect a specific network it is more relevant to detect what attacks target this network and not what kind of attack activity is currently out there in general. Some vendors have threat maps in their products which are based on the traffic directly seen by these installations and thus reflect the attacks against this specific network.

  If i launched a big DDOS attack will this attack be visible

It depends on which kind of sources the specific vendor uses. A vendor offering world-wide DDoS protection will likely show it since this is the kind of attacks they fight. But again, the purpose of these threat maps is not to provide an absolutely true picture which include all current attacks.


Using the password hash as a reset token

There's a couple of disadvantages with this scheme:

As other responses have pointed out, this leaks the user's password hash.  This is a problem not because the legitimate user gets it or because anyone with access to the email could own the account (this is true of reset tokens as well) but because it allows an attacker who can read the email to perform a dictionary attack on the hash.  It's likely the user will set their new password to something very similar or have reused the same password on multiple sites.  Leaking hashes is undesirable, even if properly salted & hashed.  Consequently, if the email is ever compromised by an attacker, it has value to the attacker.
Also, as pointed out, this makes it hard to regenerate the token or have it expire.  Password reset tokens should not be good indefinitely in case someone gets access to an old copy of email (e.g., a backup) or has pulled it off the wire but does not use it in a timely fashion.  Your "benefit" of no expiration of the token is actually a drawback from a security point of view.  (And marginally useful from a usability point of view.)
In the reset email, the token is often (always?) placed as a query string parameter.  This means the token (and the users password hash) will be stored in their browser history, and likely in any webserver logs.


If you can provide the lines in your log file showing what rule is causing the block it would be helpful.
An option would be to use SecRuleRemoveByID to disable the rule that is causing your block.
Alternatively you can white list IP address using a number of different techniches which are listed here


How to securely share only some information with a middle-man site

This is a really big question, and one that might benefit from being broken down a bit. I'll start with question #0, though.

Is there a standard protocol? Several. It depends on exactly how you want to do this. Consider this extremely simple approach:

Cross-Origin Resource Sharing (CORS): The user logs into MS, and MS sends an authenticated CORS request to a /SharableData endpoint on OurApp (this endpoint, and only this endpoint, will return Access-Control-Allow-Origin: https://middlemansite.com and Access-Control-Allow-Credentials: true). If the user has an active session on OurApp, the sharable data is returned such that MS can read it. If the user's browser has no current session on OurApp, an error indicating this is returned and MS offers a link to OurApp so the user can sign in OurApp. If the user has a session on OurApp but has not allowed data sharing with MS, OurApp can either send back the same error as before (may lead to user confusion but conceals from MS the fact that the user even has an OurApp account), or can return an "unauthorized" error and MS could offer the user a link to their data sharing settings page on OurApp.

Advantage: Easy to scale to multiple middleman sites. Each MS, when on-boarding to OurApp, supplies some basic info about itself (name, icon, whatever) and the origin that the requests will come from. You verify that the details are valid, and allow the user to toggle sharing with that site. No need for secret keys, etc.
Advantage: No need for a server-to-server request flow. The MS server cannot access even the sharable data directly - it can only do so via the user's browser when the user is signed into both sites and browsing MS - and neither server needs to store any server-to-server keys or be configured to allow outbound requests.
Disadvantage: Requires sessions on OurApp to last long enough that the user can complete their browsing on MS without needing to log into OurApp annoyingly often (can be mitigated by having two sessions for OurApp, a short-lived session that is used when actually interacting with OurApp and a long-lived session that only gives access to the user's sharing-allowed data, with at least the latter stored as a token in a cookie).
Disadvantage: Potentially inconvenient back-and-forth between sites when setting up (could be mitigated with a "returnTo" query parameter that enables sending the user back to trusted third-party sites like MS, though beware creating an open redirect by accident).
Disadvantage: Potentially allows cross-user access to shared data, if on a shared browser a user logs out of MS but not out of OurApp, and then another user logs into MS (can be mitigated by having MS supply some kind of identification string - a name, phone number, email address, or whatever - with the CORS request, and rejecting the request if the ID string doesn't match the current session on OurApp). On the other hand, nothing you can really do about this; if a user shares a browser with somebody they don't trust and fails to log out of everything they were logged into (perhaps by using Private/Incognito mode and closing the window), there's not a lot that you can do to protect them).

Other options could include using a shared authentication provider (SSO) that attests the user's identity to each site (complicated when the users already have accounts, though; you need to support linking them) and letting a user on OurApp grant access to MS, or using a "connected app" model (probably via OAuth, which is widely used and supports all the desired functionality) where an authenticated user on MS can request that the user's browser provide an access token from OurApp, and OurApp first makes sure the user is logged into OurApp and then that they want to share the data. There are tradeoffs, of course; the SSO route requires all the sites cooperate on their SSO identity provider and existing account management, and the OAuth route allows a MS to query all the sharable data for all users who have granted access at any time, instead of only when the user is actually browsing the MS and also logged into OurApp (with at least a long-term low-access session).


Why does one need a strong password on Unix?

You seem to have a pretty clear understanding of the risks. As others have stated it highly encouraged to use a strong password, so if you are running a sensitive service, then by all means, please use strong passwords only.

When using a weak password, there are a couple risks that come to mind which you did not mention:

There may be other services besides SSH (e.g. FTP or others) that are still accepting password-based authentication. It's quite possible that one of those services will be accidentally enabled some time in the future, or a sysadmin may temporarily enable password-based authentication on the SSH.
There is an important point you did not mention in regards to malicious applications. In the event of an intrusion to a non-root account, it is extremely important to prevent upgrade to root access. If the root password is weak then you may very well have an open vulnerability there via brute force. Also, supposing there is some other account that has sudo permission, these need strong passwords also.

Do not dismiss the importance of preventing malicious applications from being able to gain root access; and beware of the risk of changes in your configuration. Also there is a strong possibility that you and I do not know the same attack vectors that your adversary does.

You may be able to increase the length of the password to compensate for decreased complexity, thereby making it easier to type. As a touch typist, I have a hard time relating to your problem though.


Certificate not trusted in Root CA Store - does it still enable secure connection?

My understanding is that you have been asked to generate a CSR for this server.

My advice would be to look at the documentation that came with the server / application; they often come with utilities / tools / instructions for generating CSRs.

Barring that, you can always generate a CSR manually. Google "how to generate a csr on ____" where you replace "_____" with the server stack that it is running, for example "how to generate a csr on iis 8" or "... nginx centos", or wtv.

Note that you will need direct access to the server to do this -- RDP (if Windows) or SSH (if linux). You say "but it's not our web server", which would definitely make things more complicated -- the point of a certificate is to prove ownership of the server, which is hard to do if it's not yours.

As for your actual questions, I don't really understand:

  Even though our store does not trust the certificate, does it still enable secure communication?

Probably not. I'm not sure what "our store" means, but the security of TLS comes from the fact that the client (usually a browser) trusts the CA that issued the cert.

You need to generate a CSR and get a certificate from a Certificate Authority that your clients will trust (ie a public CA if this is a public site, or a corporate CA if this is an internal site).

  Is there a way for us to import this certificate to our store to trust it?

Yes. How to do that will depend on what "our store" is.

Google "____ import certificate into trust store", where "_____" is the name of the application or OS that you are trying to import it into. Note that you usually import the root CA cert, not the server's cert.


Buffer overflow Mona modules all show Rebase SafeSEH ASLR True

Using the protected modules WILL ONLY work during that session however when restarting Windows the Address's of the protected DLL's will change. So this explains why I was able to get a reverse shell during this windows session.
If mona output shows DLL modules are protected best to look at the Executable itself.
The solution to this situation is to look for JMP ESP within the EXE itself.


What exactly is 'single' mode in John the Ripper doing?

The paragraph from JtR online documentation that you're adding to your question actually explains it pretty well.

Think of it as a dictionary mode (or WordList Mode), but one that builds the list of all words found in GECOS fields, making this dictionary rather small and uses a complete set of mangling rules JtR supports.

In contrast, the WordList Mode will have a much larger set of dictionary words to run through, but using a reduced set of mangling rules designed to finish very quickly on each dictionary entry. This limits the number of guesses on each candidate word.

So in short, Simple Mode will run a complete set of mangling rules on a short but highly relevant dictionary, where Wordlist Mode will use much longer dictionary, but reduce the mangling ruleset to complete faster.

This relevance (where the word list is compiled from), on top of bigger number of mangling runs per each candidate word, is the most likely candidate for your better results using the Single Mode.


How practical is a laser microphone and how to protect against it?

Laser Microphones like any other eavesdropping equipment has pros and cons.

Pros

Can be invisible if using infra-red (IR) beam
Will not be detected with typical radio frequency (RF) finders
Can be turned on/off at will - avoiding further detections

Cons

The beam (laser or other) needs to be in within line of sight of the target
Is affected by rain / snow (more explanation below)
IR beam can be easily detected using the Front-Facing Camera on an iPhone

Recent History

These devices were all the rage in the 90s - you can see this by seeing the style of websites selling them (here and here are examples)

For a while they fell out of favor with the rise of networking/computer eavesdropping technologies which provided more value per dollar.

Recently though, they have been having a semi-resurgence with anti terror units having use for them. Here is an example of one such company marketing it.

Laser Microphone History

The earliest recording of a "Laser" microphone is by an inventor named Léon Theremin.

He created something named the Buran eavesdropping system which essentially used an low powered infra-red beam to detect vibrations made by sound-waves. He demonstrated this device on a pane of glass.

Operating Principles

Laser microphones work by shining a light on an object that vibrates (think: glass, plastic cup etc.) When someone speaks (or any other noise is introduced) it pushes the air around it causing the object that the laser is shining on to vibrate.

When the object vibrates it causes minute differences in the distance traveled by the light as it reflects back to a receiver. These difference are detected using something called Interferometry.

These signals are then translated back into sound which allow you to hear what is going on.

Mechanics - the moving parts

Here are the pieces involved to make this work:

Laser beam

This is the device that will 'shine a light' on the object in the room (or on the window. Modern versions of these systems can work at distances of 500 meters

Reciever

This is the device that picks up the reflection of the beam (typically placed at about a 90 degree angle to the originating beam)

This processes the light signal and sends it to the next piece of electronics for processing.

Demodulator

This is the device that actually turns it into sound for you. This device can be controlled with software to remove noises such as wind etc. to provide a clearer sample.

A Laser Microphone can be pretty effective if used properly and in ideal conditions

But remember that the information you are looking for may be in a digital device and not in voice spoken format.

Countermeasures

Detecting a Laser microphone is relatively easy in many cases (mentioned earlier in the answer)

Vibrating the windows is not always effective as software can (and has) been written to remove the frequency from the vibrating noises.

However, one can create a device that vibrates the windows with frequencies that used typically in human speech. Such a device could if done correctly render the laser microphone useless.

Known cases of use

Though there isn't any official documentation of its use, there are some places that discuss its use during the cold war (here is an example).

There has also been speculation whether government agencies used such a device during the Snowden investigation.

Usage Limitations

In order for this system to work you need line-of-sight to an object that vibrates.

This object obviously has to be within reasonable distance to the source of the noise.

Rain, Snow or any other weather that interferes with an IR beam would affect the ability to eavesdrop.

One last thing to mention is the need for both the shining laser and the receiver to be stationary the whole time and not move. Usually, this is achieved by using a pair of tripods (like in the image posted in the question)

Some interesting links

http://www.instructables.com/id/Laser-Surveillance-System-for-under-%2420/

http://hackaday.com/2010/09/25/laser-mic-makes-eavesdropping-remarkably-simple/

http://lifehacker.com/5961503/build-a-laser-microphone-to-eavesdrop-on-conversations-across-the-street

http://www.lucidscience.com/pro-laser%20spy%20device-1.aspx

https://web.archive.org/web/20180305115138/http://www.williamson-labs.com/laser-mic.htm


CVEs aggregated by programming language?

OWASP Dependency Check, which was originally written for JEE apps will scan components (e.g., framework-default, contrib, or third-party libraries) for CVE-level vulnerabilities, and more-recently added support for C/C++, Java, .NET, PHP, Python, Node.js, and Ruby components. It also integrates to build environments such as the popular Java ones (e.g., maven) and CI portals including Jenkins.

There is also a web frontend for OWASP Dependency Check called Dependency Track. These are all free, open-source software (FOSS) solutions available from the extensive OWASP security community.

Here also is an extremely unorthodox metasploit-framework search using the Linux grep command, showing that all Java-related CVEs can be searched for using this method:

    $ msfconsole -qx "search cve:CVE; exit" | grep -i java | grep -vi javascript
   auxiliary/server/jsse_skiptls_mitm_proxy                               2015-01-20       normal     Java Secure Socket Extension (JSSE) SKIP-TLS MITM Proxy
   exploit/linux/misc/jenkins_java_deserialize                            2015-11-18       excellent  Jenkins CLI RMI Java Deserialization Vulnerability
   exploit/multi/browser/java_atomicreferencearray                        2012-02-14       excellent  Java AtomicReferenceArray Type Violation Vulnerability
   exploit/multi/browser/java_calendar_deserialize                        2008-12-03       excellent  Sun Java Calendar Deserialization Privilege Escalation
   exploit/multi/browser/java_getsoundbank_bof                            2009-11-04       great      Sun Java JRE getSoundbank file:// URI Buffer Overflow
   exploit/multi/browser/java_jre17_driver_manager                        2013-01-10       excellent  Java Applet Driver Manager Privileged toString() Remote Code Execution
   exploit/multi/browser/java_jre17_exec                                  2012-08-26       excellent  Java 7 Applet Remote Code Execution
   exploit/multi/browser/java_jre17_glassfish_averagerangestatisticimpl   2012-10-16       excellent  Java Applet AverageRangeStatisticImpl Remote Code Execution
   exploit/multi/browser/java_jre17_jaxws                                 2012-10-16       excellent  Java Applet JAX-WS Remote Code Execution
   exploit/multi/browser/java_jre17_jmxbean                               2013-01-10       excellent  Java Applet JMX Remote Code Execution
   exploit/multi/browser/java_jre17_jmxbean_2                             2013-01-19       excellent  Java Applet JMX Remote Code Execution
   exploit/multi/browser/java_jre17_method_handle                         2012-10-16       excellent  Java Applet Method Handle Remote Code Execution
   exploit/multi/browser/java_jre17_provider_skeleton                     2013-06-18       great      Java Applet ProviderSkeleton Insecure Invoke Method
   exploit/multi/browser/java_jre17_reflection_types                      2013-01-10       excellent  Java Applet Reflection Type Confusion Remote Code Execution
   exploit/multi/browser/java_rhino                                       2011-10-18       excellent  Java Applet Rhino Script Engine Remote Code Execution
   exploit/multi/browser/java_rmi_connection_impl                         2010-03-31       excellent  Java RMIConnectionImpl Deserialization Privilege Escalation
   exploit/multi/browser/java_setdifficm_bof                              2009-11-04       great      Sun Java JRE AWT setDiffICM Buffer Overflow
   exploit/multi/browser/java_storeimagearray                             2013-08-12       great      Java storeImageArray() Invalid Array Indexing Vulnerability
   exploit/multi/browser/java_trusted_chain                               2010-03-31       excellent  Java Statement.invoke() Trusted Method Chain Privilege Escalation
   exploit/multi/browser/java_verifier_field_access                       2012-06-06       excellent  Java Applet Field Bytecode Verifier Cache Remote Code Execution
   exploit/multi/browser/mozilla_navigatorjava                            2006-07-25       normal     Mozilla Suite/Firefox Navigator Object Code Execution
   exploit/multi/browser/qtjava_pointer                                   2007-04-23       excellent  Apple QTJava toQTPointer() Arbitrary Memory Access
   exploit/multi/elasticsearch/script_mvel_rce                            2013-12-09       excellent  ElasticSearch Dynamic Script Arbitrary Java Execution
   exploit/multi/http/jboss_deploymentfilerepository                      2010-04-26       excellent  JBoss Java Class DeploymentFileRepository WAR Deployment
   exploit/multi/http/sun_jsws_dav_options                                2010-01-20       great      Sun Java System Web Server WebDAV OPTIONS Buffer Overflow
   exploit/multi/misc/java_jmx_server                                     2013-05-22       excellent  Java JMX Server Insecure Configuration Java Code Execution
   exploit/windows/browser/java_basicservice_impl                         2010-10-12       excellent  Sun Java Web Start BasicServiceImpl Code Execution
   exploit/windows/browser/java_cmm                                       2013-03-01       normal     Java CMM Remote Code Execution
   exploit/windows/browser/java_codebase_trust                            2011-02-15       excellent  Sun Java Applet2ClassLoader Remote Code Execution
   exploit/windows/browser/java_docbase_bof                               2010-10-12       great      Sun Java Runtime New Plugin docbase Buffer Overflow
   exploit/windows/browser/java_mixer_sequencer                           2010-03-30       great      Java MixerSequencer Object GM_Song Structure Handling Vulnerability
   exploit/windows/browser/java_ws_arginject_altjvm                       2010-04-09       excellent  Sun Java Web Start Plugin Command Line Argument Injection
   exploit/windows/browser/java_ws_double_quote                           2012-10-16       excellent  Sun Java Web Start Double Quote Injection
   exploit/windows/browser/java_ws_vmargs                                 2012-02-14       excellent  Sun Java Web Start Plugin Command Line Argument Injection
   exploit/windows/http/hp_nnm_webappmon_ovjavalocale                     2010-08-03       great      HP NNM CGI webappmon.exe OvJavaLocale Buffer Overflow

One could use a different exploitation-framework search engine, such as the one from Core Security, to perform a similar extensive search -- https://www.coresecurity.com/products/core-impact/recent-exploits-and-updates?title=java&field_exploit_type_tid=All&field_vulnerabilty_id_value=CVE&field_operating_system_tid=All -- or even the one from Immunity Security -- http://exploitlist.immunityinc.com/home/exploitpack/CANVAS/browse


How to block an application with iptable which use random port

Why not just whitelist the ports that you want to access instead of trying to blacklist every single one of them? You know that YOU will want to connect to your device, whitelist the services that you will be using and you should be good to go.


Mainly that the data in the unencrypted traffic could be read by that user and that knowledge of the networking setup (i.e. what IP of the file server is) and any login credentials that might be hard-coded into any of the applications and sent unencrypted. If you are able to switch users and someone else were to log in then their network data would be at risk too.


Yes of course, there are other sorts of brute force attacks to crack passwords!
For example, on Hashcat's website you can find the following types of attacks:

Straight *
Combination
Brute-force
Hybrid dict + mask
Hybrid mask + dict


Is a self signed certificate sufficient to prove the integrity of my executable?

It's important that the person receiving the file checks it against your public key. Anyone can create a self-signed certificate, and you can put whatever meta-data you want into it. So, two self-signed certificates can look and behave identically, the only thing that differentiates them is the key pair used to sign it.

In other words, and answering your comment on Jeff's answer, you can't visually distinguish between a legit and a forged certificate, if for instance the OS or browser or whatever pops up a window showing its details. Certificates signed by a trusted authority, OTOH, will be shown together with a name/link that is harder (nigh impossible?) to be forged.

But if your public key is published/sent to your customers, they can verify (or you can later prove) whether or not the file is legit. Since nobody else know your private key, they can't create a certificate (self signed or not) that matches it, even if the meta-data look the same.


Your #3 is what is explicitly described in the CVSS User Guide:

  CVSS is designed to classify and rate individual vulnerabilities. However, it is important to support the needs of the vulnerability analysis community by accommodating situations where multiple vulnerabilities are exploited in the course of a single attack to compromise a host or application. The scoring of multiple vulnerabilities in this manner is termed Vulnerability Chaining. Note that this is not a formal metric, but is included as guidance for analysts when scoring these kinds of attacks.

  When scoring a chain of vulnerabilities, it is the responsibility of the analyst to identify which vulnerabilities are combined to form the chained score. The analyst should list the distinct vulnerabilities and their scores, along with the chained score. For example, this may be communicated within a vulnerability disclosure notice posted on a web page.


Cloudbleed: is it actually important to change ALL passwords?

While Miao is right for the case of passwords, this vulnerability also makes oauth tokens compromised. If a Cloudflare-dependent site uses Oauth, you should make an extra step resetting your oauth dependent sessions across the web.


Proof of data possesion in cloud storage where you cant do calculation to the object stored in the server

Azure blob storage offers per-block MD5 (which can be requested to be dynamically calculated using an http header in the REST api request).

If you want to, you can write a client which validates the content of cloud-stored blocks by iterating over the blocks in each blob, requesting the MD5 for each range and comparing it to local data.

It's a pretty mature API at this point: here's the overview from 2011.

I'd be surprised if AWS didn't offer something similar.


Securely obtain information from a USB Flash Drive /Thumb Drive avoiding viruses

Just boot from a Linux live CD and remove your internal hard drive, if you are that concerned about malware inside the USB. You can turn off your wifi adapter manually as well, if you need that level of security. I think at that point, short of it writing to the BIOS (which only one current piece malware in the wild exploits), it is almost impossible for it to infect your computer. I would suggest that you do not transfer any files off of the USB at any point, as anti-malware utilities are nearly useless against unique/new malware due to signature based detection.

I should really emphasize the point of not transferring the data to anything else you might be concerned about infecting and keeping it isolated while in use, as any file within the drive could theoretically contain some type of malware, and you do not want that at all.


Secure Software: How to ensure caller is authentic?

This is one of the largest problems online competitive games have to face. Unfortunately, there's no simple solution. The most effective way of detecting bots or malicious users is via behavioral analysis.


Proof of Work as password hash a good idea?

I'm not an expert here, just throwing around my thoughts since your idea is neat and I'd like to explore it.
As pointed out by @PwdRsch, the password14 talk [video], [slides and sample code] from 2014 (while not the strongest talk I've ever seen) is on exactly this topic.

I have a few issues with your scheme the way it is. First, to prevent replay attacks you should really have the server generate a nonce for each login and send this to the client (since the nonces don't need to be key-strength, and you don't want to present an easy DoS, get them from /dev/urandom rather than the usual /dev/random)
Second, both the attacker and the honest user need to do O(hash_prefix='0000') work, which will be a far bigger penalty to the honest user on their smart phone than it will be to the attacker on their 12 GPU hashing rig. Giving the advantage to the attacker is bad.
Let's fix these by doing something like this:
Client-side:
h = "0"
d = "0000f"
hashed_pw = pbkdf2( password )
do:
  h = hash (h + username + hashed_pw + nonce)
while (h > d)

send("login", username, h)

Server-side:
listen("login", username, h)
user = database.get(username)
if "0000f" > hash (h + username + user.hashed_pw + nonce)
  send("accepted", true)
  session.user = user

Here the server has to do O(1) work (a single hash iteration), the honest client needs to do O(hash_prefix='0000') work, and the attacker need to do exponential work in the length of the password: O(2password_length-1) * O(hash_prefix='0000').

Having hardened your algorithm a bit (but me spending an hour staring at it by no means implies that it's prod-ready), let's look at what it's accomplishing. I assume your threat model is to protect against online brute-force attacks to keep your users' accounts from getting compromised.
Drive-by / low-hanging fruit
In this attack scenario the attacker is looking to find the users dumb enough to be using a password on the most common passwords lists. Here the exponential speedup from forcing the attacker to guess over the password disappears because they are not guessing an exponential number of passwords. So for any user with a weak password, this scheme isn't really doing anything because a few extra milliseconds of hashing is insignificant to the attacker.
Targeted attacks
Here the attacker is trying to break into a specific account. If they really are guessing passwords at random, then this will slow them down, but given that network lag and fail2ban already make a social engineering / phishing attack better value than an online brute-force, I'm not sure you're adding value here either. Enable 2FA with the Google Authenticator if you're worried about this.

Bottom line: The idea is neat and I've enjoyed thinking about this, but

I'm not sure it's adding much value.
"Don't roll your own". I found a few holes in the scheme, so you'd need to spend a lot of time and effort hardening it before I'd be confident to use it in production.


Yes, E is correct.

A vulnerability is a weakness that could lead to harm (whether it be to confidentiality, integrity, or availability.)

A threat is an agent that could expose the vulnerability.

The question is about an "event", which is the threat.


In general, FTP isn't that safe to use. It is way to easy for hackers to hack into your server, and then they can delete your files, change them, and/or steal them. They could even get information to access your database too! I recommend that you turn off FTP on your server right away.

Instead, try using a program like Winscp. You can use SFTP, which stands for Secure File Transfer Protcol. Then you can transfer your data between you and your server through an encrypted connect.


GnuPG decryption not asking for passphrase

Does it store the secret key somewhere and uses it (I also stored my secret key in the GnuPG key chain, does it uses that)?

GnuPG only uses keys from your key chain, so it must be in there to use it.

  How can I force the system to ask the passphrase every time?

Old versions of GnuPG uses the gpg-agent, which caches the passphrase for a given time. Use the option --no-use-agent or add a line no-use-agent to ~/.gnupg/gpg.conf to prevent using the agent.

For newer versions (v2.1+), disable password caching for the agent by creating ~/.gnupg/gpg-agent.conf and adding the following lines:

default-cache-ttl 1
max-cache-ttl 1

Restart the agent with:

echo RELOADAGENT | gpg-connect-agent


Volatility.exe suggests two profiles for XP memory dump. Which one should I use?

You should try both!

If memory addresses and PID's appear with question marks around them, you should probably switch to the other profile.

The problem is volatility can recognize that it's a certain Windows XP release, but the identifiable properties of these 2 XP Versions overlap, and make them harder to distinguish.

When executing plugins such as connscan or proclist, the results might be a bit obscure when using the wrong profile, because the actual locations in memory of these objects might differ between the XP Versions.

You'll notice pretty fast if you're using the wrong profile.


Will changing the TLS Diffie-Hellman key exchange bit length from 1024 to 2048 cause client/browser compatibility issues?

Modern browsers will be perfectly happy accepting 2048-bit DH moduli. You can verify that your site's TLS configuration is compatible with popular browsers by using SSLTest. Only (very) outdated versions of Java tend to have problems with DH moduli larger than 1024 bits.


Is it unsafe to have hashes of parts of a private string

Extra information can only help the attacker; but that extra help might be negligible.

If we model the hash function as a random oracle, then showing h(P+B) for a given non-empty string B does not yield extra information useful for the attacker (I take "+" to mean here string concatenation, not numerical addition). A "random oracle" is (in rough terms) a function such that you know nothing on its output for any given input without trying it. When you have h(x), you can gain information on x only through brute force, i.e. trying out potential values for x until a match is found. Thus, h(P+B) does not give any extra power to the attacker, compared to h(P), and regardless how B was chosen: the attacker still has to try potential P values and hope to get lucky. The best that the attacker can do to optimize things on his side is to choose a strategy that minimizes the computational cost of each try; since common hash functions have a cost that is proportional to the input size, the attacker will prefer to work with h(P) than h(P+B) anyway.

The trouble with the random oracle model is that usual hash functions are not random oracles. However, in the case of Merkle–Damgård hash functions (a category that includes common hash functions such as MD5, SHA-1, SHA-256 and SHA-512), there is a property called "length extension attack": given h(P), it is possible to compute h(P+B) for B values that can be, to a large extent, chosen at will, and you can do that without knowing P (you need to know the length of P, but not its actual value). The length extension attack is usually accounted for as either an harmless curiosity, or a weakness (in most protocols, it is harmless and can be ignored); but, in our case, it has an interesting consequence. Namely, it allows us to show that revealing h(P+B) does not give extra information to the attacker, precisely because the attacker did not need wait for us: he could already compute h(P+B) for a large class of B values.


What unique risks does MVC model binding bring to a website? What additional vigilance is needed?

Model Binding is quite a nice feature and may add a plus to the overall security if it is properly used.

Here is how it works (the code and the features apply to ASP.NET MVC but may be the same in Ruby):
Suppose you have a form in a web page:

<form action="/SendData">

  Email: <input type="text" name="email" id="email">

  Address:<input type="text" name="address" id="address">

  <input type="submit" value="Submit">

</form>

You write a class like this:

class Contact{
   String Email{get;set;}
   String Address{get;set;}
}

With model binding the function that deals with the user request can be:

public ActionResult SendData(Contact contact){
        //do something with contact.Email and contact.Address
}

As you can see, model binding automatically puts the data it received in the HTML request in an object of the type Contact.

Furthermore, you can define validation functions, by using DataAnnotations.

class Contact{
   [Required(ErrorMessage="Input email please!")]
   [RegularExpression("^some_regex"),ErrorMessage ="Error"]
   String Email{get;set;}
   [Required(ErrorMEssage="Input address please!")]
   String Address{get;set;}
}

and check it like this:

public ActionResult SendData(Contact contact){
    if(ModelState.IsValid)
    {
        //do something with contact.Email and contact.Address
    }
}

As you can see, it easy to add validation and some common mistakes(like badly written SQL Queries may be avoided).

Now to explain the problem that lead to the GitHub hack (mass binding):

What happens if you have properties in your class that do not appear in the form:

<form action="/SendData">

  Email: <input type="text" name="email" id="email">

  <input type="submit" value="Submit">

</form>

If an attacker also sends a variable with the name address, the framework will automatically bind it, without knowing that in the original form there was no such input.

In the GitHub case, the developers probably used an Object that had a property that differentiated between administrators and normal users(isAdmin for example). By sending this parameter in the login form (or another page), together with the user and password, the attacker could have gained access to administrative functionality.

There are several ways to solve this issue( blacklist binding, whitelist binding), but I recommend using Interfaces and Classes that only contain the properties from the form (or have the other attributed marked as read-only ).

Whitelist binding example:

public ActionResult SendData(
[Bind(Include="Email")]Contact contact)
{
    //...
}

Regarding the affected frameworks, probably most of them are affected (Ruby and ASP are), but this is not a vulnerability itself, it's only bad programming. As long as the programmers address this functionality properly, everything should be OK.

I don't think that an automated tool could detect this kind of problems, but a thorough code review should solve it.


Is there any methodology to detect smart deauthentication attack?

Sending De-Auth frames in the manner you have mentioned - randomly or periodically which remain under the threshold value of detector, may be considered an adversarial attack against intrusion detection systems that could be using machine learning or other methods to be detecting intrusions.

Sending the frames randomly could be considered a form of perturbation, there is a lot of research currently in adversarial attacks against IDS in many different fields, most notably malware, email spam, network attacks etc.

I don't have any papers that come to mind for this specific problem however reading about adversarial attacks against IDS may help you as there are plenty of papers that suggest methods of defending against these adversarial attacks.  A good paper that may give you an overview of this area is the following:

Adversarial attacks against intrusion detection systems: Taxonomy, solutions and open issues
https://www.sciencedirect.com/science/article/pii/S0020025513002119

It is quite heavy however even if you grasp the general principles, it may help you.

I have been researching adversarial attacks against NIDS and one of the attack methods is to slow down packets or send them much more randomly to avoid detection.


I think the most straightforward way to do this would be to use container linking. The exact solution depends on whether your containers that you want to access via this VPN are on different VMs / physical servers or not.

If the containers are on the same server
Essentially you would run your VPN server in it's own container, and link all the other service containers to it. You can then only expose the VPN port on the host machine, but once you are inside the VPN container you'll have access to the other services via docker's container linking private network magic.
If the containers are on different servers
Look into Linking docker containers across multiple hosts - this solution is a little more involved / complicated.


The incompatibility is only for v2.x of PGP.  For v5.x, the GPG (not PGP as you state) needs to have more options.

If the problem with PGP 2.x is truly an issue, then you will probably have to shell out for the PGP command-line version.  Note that PGP v5 appears to have been released in 1997 and PGP v2 was in 1992-ish, so unless you are dealing with recipients that do not upgrade, you will probably have good coverage.

Import your key and others:

gpg -v --import c:\pgp\my-pub-and-priv-pgp-key.asc

Import each recipient key

gpg -v --import c:\pgp\pub\recipient1.asc
...
gpg -v --import c:\pgp\pub\recipientN.asc

For some reason the command-line options are really hard to find in the locally installed Windows manual; here they are.

Now use --batch for batch mode, --passphrase-file to have your private key unlocking phrase read from the given file instead of from the keyboard via the gpg-agent*, and always trust the recipient keys.  If you don't need to have the output signed, then obviously you won't need to use or unlock your private key.

Encrypt (-e) and sign (-s) a file

gpg -v --always-trust --batch --passphrase-file mypassphrasefile -se -r
 recipient1 -r recipient2 ... -r recipientN -o output-file file-to-encrypt

Files should be able to be decrypted and verified with PGP by the recipients.

*I don't think I have to say what kind of potentially bad idea it is to store your private key passphrase in a cleartext file.  Note that on Windows, the gpg-agent will read your private key from the keyboard and cache it.  The time period it caches it for can be set in the gpg-agent.conf file, though I've not tried this (see here for some potential pointers; the gpg-agent.conf resides in your home dir which is set using the GNUPGHOME env var or by setting the HKCU\Software\GNU\GnuPG:HomeDir string variable).


ASP.NET will be more secure than PHP if the developer masters ASP.NET more than PHP. And vice versa.

There are many claims that a lot of features of PHP seem to have been designed by a lemur who had taken acid, leading to a rather tortuous set of features and thus potentially making the task of developing securely rather harder than what it could have otherwise been. However, these details are dwarfed by the skills of developers, or lack thereof. Regardless of the language details, the developer must think of "what could go wrong with the code" and there is no automatic tool which will do the thinking for him.


Perform static analysis over executable Jar

Can you perform static analysis over executable Jar files?

Yes. Static analysis just means that you are not actually executing the software during your analysis.

What I did so far is decompile (JD GUI) the jar to get source code excerpts. Is there a better way to do this ?

Decompiling the jar file is a great way to start, and JD GUI is a handy tool to help you decompile. Now you just have to dive in and actually figure out what the Java code is doing. Good luck!


What to do with the extra bytes in ECDHE-RSA-AES-GCM-SHA?

According to RFC5246, the TLS 1.2 spec, SHA384 is used for signatures and MACs, not for a KDF.

Additionally, section 1.2 of the document specifies that all TLS 1.2 cipher suites use P_SHA256 as the PRF for Key Calculation, so they use a SHA256-based pseudorandom function defined in section 5.  The PRF specifies a way of generating exactly as much data as necessary (modulo the SHA-256 block size).  Excess data within the final block is simply discarded off the end.


You are correct. In fact, many defense systems are designed to look for the traffic going out to a C&C server, and the traffic details would identify the destination (the attacker's C&C server).

So, the attacker needs to take this into account and design around this problem.

The obvious solution is to not make your own personal PC the C&C server. Instead, use another compromised machine (unsecured web servers make great C&C).

If the attacker needs to connect directly, then the simplest options are to use free public wifi, crack a neighbour's wifi, VPNs, proxies, TOR, or use a burner SIM card. Something to obfuscate the attacker's IP or borrow another one.


Are RFC 2104 and FIPS 198 compatible with each other?

When testing with two libraries, one implemented against the RFC and another implemented against the FIPS spec, both seem to produce the same results.


If Apache is configured to parse PHP can users see PHP source code?

If Apache is properly configured with the php module loaded and correct mime types, you should expect to not have any code disclosed to the client.

Example:

AddModule mod_php.c
LoadModule php_module         modules/mod_php.so
LoadModule php5_module        modules/libphp5.so

AddType application/x-httpd-php .php

There don't seem to be any attacks against mime types in apache that would break this behavior that I know of. You should be more worried about poor coding practices, and disclosing the source code through other means such as file inclusion attack.

PHP does have a .phps extension that beautifies source code for sharing. If you use these files, make sure you strip them of any usernames and passwords before sharing them. It might be possible for a file to be incorrectly named .phps insteaf of .php -- unlikely, but possible.


Sextortion with actual password not found in leaks

While services like HaveIBeenPwned are fairly extensive, there are still many stolen user / password lists that have not been revealed to the public eye. Maybe a company didn't actually disclose what happened, never realized anything happened, and/or no researcher has yet found the list. Unless you somehow find the list that included that password somewhere, there isn't a good option to try and report this incident.


Why is faking SSL certificate difficult?

Let me explain via a practical example.

There are a set of Certificate Authorities (CAs) that browsers implicitly trust. You can see the list of trusted CAs in your browser. For eg. the CAs trusted by Chrome browser can be found at "Wrench Menu > Preferences > Under the Hood > HTTPS/SSL (Manage Certificates) > Authorities tab".

So, the certificate that mail.google.com presents to your browser is 'signed' by Thawte SGC CA. This CA is implicitly trusted by the browser. These CAs will issue certificates only after thorough (and manual) verification.

You and I cannot trick Thawte or Verisign to sign us a fake certificate for google. Although such cases do happen but are rare and mostly require some insider help.

Now, on your own machine, you can go ahead and create certificates stating them to be of google.com. But these certs are 'self-signed' and will not be trusted by browser because the CA (you) are not in its trusted certificates list. In this case, browser will show you the certificate warning.

So, now to answer your question, there are a couple ways in which spoofed certificates are created (or made to work):

Just as I mentioned above, a person can trick a CA (which is trusted by browser) to issue you a certificate for a site which doesn't belong to you. For this reason people often manually remove trusted CAs from their list. God know what procedures does that CA in that never-heard-of country follows. I've seen paranoid people removing CAs from browsers trusted list.
The CA gets hacked (or is made to issue fake certs). In such a case you can issue certs at your will. Not to mention, such CAs immediately go out of business once this is found.
You can also have a fake "self-signed" certificate of google.com and still manage to bypass the browser security check if you explicitly add your own CA to browser's trusted list. Companies can do it. I've seen (and worked at) companies where they openly do it for "Compliance reasons". Since your desktop machines are in their control, they install their own CA to your browser's trusted store and present a fake gmail cert to the browser - which browser trusts and they happily intercep ALL your conversations/emails.

In all the cases - what do you get by faking a certificate: You can MITM (Man in the middle) the server and the users computer and decrypt the SSL session.

I've left many finer nuances of certificate creation in my description above to present a broad picture. You can read about Cert Patrol and perspectives to see how you can prevent falling a victim of a fake certificate even if its CA is in browsers trusted list.

You can also read about certificate pinning which can help prevent such certificate hijacks.


Depending on the filesystem, physical device, etc., those will have varying levels of effectiveness.  I'll take a look at each one, and generally I'm assuming ext4 on magnetic hard disk, as it's the most common default Linux FS right now.  I'm also assuming recovery starts immediately after the command completes: i.e., there are no intermediate writes to this filesystem.

  shred -uvz -n500 file

500 passes is overkill.  Generally, it's believed that a single pass is sufficient on modern drives (Source 1, Source 2, Source 3), so the 3 passes shred offers by default should be plenty.  Of course, this assumes that you're overwriting in-place (the same disk blocks) which is true of default ext4 setups.  If you have odd mount options (like journal=data) you'll find this isn't true anymore, and any form of overwriting won't be enough unless you overwrite the entire partition.

  dd if=/dev/null of=file

/dev/null gives EOF upon reading.  Consequently, this just truncates the file, which is equivalent to echo -n ''>file.  All of the data blocks will remain on disk, and can be recovered.  If the file is not fragmented (all data blocks are consecutive) this is trivial, if it is fragmented, it may take much more work to reconstruct the file.

  dd if=/dev/zero of=file

By default (unless conv=notrunc is passed), dd opens the output file with O_TRUNC, which causes the filesystem to immediately de-allocate the existing blocks of the file, then starts writing, triggering new allocations.  Will these be the same blocks as freed by the truncation?  Maybe, maybe not.  It depends on how much space is free, whether the file was fragmented, and your mount options both now and at the time the file was created.  (Switching extents on/off would be a big difference.)  Also, this command, as given, doesn't specify any point to stop -- you'll keep writing until the partition is full.  (Which actually gives you a good chance of overwriting your data blocks, but will probably take much longer than is desirable.)

Finally, you didn't specify what media you're doing this on.  I assumed a magnetic disk above because the answer is much more straight forward.  On an SSD, it's a completely different world.  Wear leveling means you're never going to be overwriting the same blocks, and there are many blocks that exist but aren't visible from the operating system.  Even the built-in security features of SSDs won't necessarily erase your data.  In the case of an SSD, my best recommendation is to encrypt with a strong passphrase, and when you're ready to recycle the drive, hit it with both an overwrite of zeros and an ATA secure erase.  Between the two, there's a very good chance you'll have destroyed the master key, and even if you haven't, forensic recovery will be highly doubtful.


What's the best way to authenticate an user using a websocket?

If you want security, transmitting authentication data through TLS is a big start.
But let's assume the websocket is already set up over TLS.
A solution I would recommend would be based on a challenge-response mechanism :

The server would set up a random set of bytes (the challenge), set a timeout at the end of which the challenge wouldn't be authorized.
The client would send in "plain text" the username and the challenge and an hash (with a SHA2 or SHA3 algorithm) of challenge || username || f(password),
f(password) being how the password is stored in the database (a SHA256 of password for instance).
The server verifies with the username's data and the challenge the response and if so, authenticates the user. It also invalidates the challenge to invalidate any future attempt using this challenge.

This method provides an anti-replay functionality : an attacker could not capture the data and replay it later to authenticate.

I however have one big problem with this method : f(password) has here the roughly same security as password : if the database leaks, any attacker could authenticate as anybody else. I say "roughly" because, if stored in clear text, since a lot of users are using the same password on multiple websites (which is bad), their accounts could be compromised elsewhere.

I can't think of a method protecting against a database leakage and an anti-replay mechanism, but an anti-database leakage mechanism (send user password in clear text over TLS, hash password with database salt and compare with database) over TLS should be sufficient enough against most risks you will face


Showing bank routing/account numbers, and storing them safely

It depends on the bank's  security in general. Europe is better than the US, but there are stories of forged debits in the UK as well where they only used basic information.

If you are worried about routing numbers and account numbers (as leaking a database can be a PR nightmare regardless if the info regards financial information), you could opt for a second instance of your application for internal users only (and a shared database, just be careful of race conditions).

You can then use assymetric encryption to store the sensitive information in the database and put the public key in the instance for clients (where the information is encrypted when sent to the database) and the private key for decryption in the backend system. That way the frontend exposed to clients can only encrypt information.


TLS- Key exchange for session keys. Why?

When you use the term, 'exchange session keys', I think what you are really referring to is the fact that the client and the server exchange ECDHE public keys.
See https://tlseminar.github.io/first-few-milliseconds/ for a write-up on how TLS 1.2 works.  You'll see that in the ServerKeyExchange message, the server sends its ephemeral public key.  Then, after that, in the ClientKeyExchange message, the client sends its ephemeral public key.
Once the two sides have one-another's public keys, the server calculates the pre-master secret by multiplying its private key with the client's public key.  Then, the client does the same by multiplying its private key with the server's public key.  This produces the same result, so the client and the server both come to the same pre-master secret.  Then, finally, the master secret is derived from the pre-master secret.


How does a hacker know how many times a password was hashed?

Number of rounds is often stored with the password and hash. For example, using bcrypt:

$2a$10$oEuthjiY8HJp/NaBCJg.bu76Nt4eY4jG/S3sChJhZjqsCvhRXGztm

The 10 indicates the work factor, effectively adding 10 bits of entropy in terms of hashing time to brute force. 2^10 = 1024 rounds.

It is stored with the hash in case of the need to up the work factor due to Moore's law.

If your system had a secret work factor that is the same for all accounts, this could be used as an additional security measure, much like a pepper. In fact in the case of an attacker being able to set their own password and view the hash, you would need to combine it with a pepper otherwise they would be able to determine the number of iterations in play from viewing the resulting hash. However, it is more complex to up this in future than it is when storing with each separate password, as you'll need to instead store an indicator of which iteration configuration version was used for each password. You could though have a secret work factor that is added to the value stored with the hash.

Veracrypt has recently added a PIM (Personal Iteration Multiplier) feature that can be used as an additional secret to protect your encrypted data.


What is a Security Guideline and how does it stand in relation with Standards, Policies, Procedures?

Welcome to the quagmire of documentation terminologies!

In short, there is no single standard way that documents are named and labeled. It is best to pick a set of definitions, either from an established framework (NIST, ISO 27000, etc.) or define the terms in your organisation (and stick to it!)

I have worked in a number of organisations and when the topic of "what do I call this security document?" comes up, everyone sighs and rolls their eyes. In practice, everyone has an opinion, and each organisation does it differently. The (series of) meetings about what to call things can be lengthy indeed for what should be a simple process ("'policy' seems like such a stuffy and unfriendly term!").

What complicates it all the more is when you need to combine different types of documents into a single document so that "we don't have dozens of different 1-page documents that no one will read".

In general, a guideline document is an over-arching set of goals and intentions that can be used when there is no policy/procedure in place, and potentially to guide the content of policies/procedures. It's more of a cultural document than a technical one.

A great example is the "User Password Guideline" document. The policies and procedures for how to handle passwords at the system level are set independently and may have technical controls in place. But the organisation wants to encourage good use of passwords by the users. So, even though the system password Policy states that passwords should be no shorter than 8 characters (or whatever) the Guideline for users is about encouraging them to use very long passwords. It's not something you can force to happen, but there's a guideline in place to handle the risks of poorly formed passwords when the policies, procedures, and technical controls might not be able to address that risk on their own.

In some of my organisations, I combined the Password Guidance and the Password Policy into a single document. One part to explain the whys and the organisation's expectations about how passwords are handled, and then all the technical bits after. If users follow the Guidance, they will be fine. If they need to get fancy with the requirements, then those details are available, too.


Why did Java (JRE) vulnerabilities peak in 2012-2013?

I think this is a "trend effect" which is also the drive under everything about fashion (in the "clothing" sense). Please allow the local Frenchman to talk about fashion.

Fashion is a deeply self-contradictory social behaviour. People who follow fashions seek both:

to gain acceptance in a given local group by displaying adherence to perceived agreed upon codes (e.g. the arbitrary choices of cloth shapes and textures and colours);
to gain visibility within the same group by displaying a bold (implicitly: bolder than other group members) will to embody the most up-to-date or even future social codes for that group.

In effect, the fashion-victim must be both a leader and a follower. If the context were electronics, we would say that we observe a circuit with positive feedback, which must necessarily exhibit sharp transitions between locally stable configurations. An extra effect is that, in clothing fashion, the only universal effect is fast depreciation: no fashion may ever remain active for more than a few months. In short words, fashion is fast-pace, and when it tilts one way ever so slightly, everybody rushes in that direction. This explains the way fashions come and go with violent abruptness.

Hackers are the geek version of fashion victims. Their interest and efforts are always driven by what seems to be "hot subjects". People who spend their days and nights on keyboards are often very sensitive to social exclusion (since they get little society on average) so they abhor the idea of concentrating on an "has been" technology which would deprive them of the last shreds of peer recognition that they may hope for. Therefore, when a topic seems to promise glory, they all run towards it. "Glory" can here be equated with "slashdottable".

In the specific case of security and Java, the trigger may well have been, indeed, the acquisition of Sun by Oracle. Oracle is a known "bad guy" so there always is some fame in finding security holes in Oracle's products (computer people have always had a soft spot for nihilism). Moreover, the security model of Java (the applet model) looks ripe with potential vulnerabilities: in the Java applet model, the "security perimeter", which is the boundary between the hostile world (the applet code itself) and the protected world (the host system) goes through the standard library API: hundreds of system classes must check and enforce the complex system of permissions. The attack surface is huge. There MUST be holes now and then. Sun's people were quite good at what they did, but making the applet model safe would take divine development powers.

As soon as a few bugs were found and publicized, the idea of unclaimed reputation riches went through the collective hackers' minds like a fire in the savannah, and they all rushed. Such is the power of Bonanza. Once brains are ablaze with the promise of wealth (in this case, Twitter followers or Slashdot scores), there is no stopping them.

It will end soon, though. "Java bugs are soooo 2013 !"


Do drive-by attacks exist in modern browsers?

Do drive-by attacks actually exist within modern browsers and if yes how do they work?

It is absolutely possible, and there is a big market for it. As SmokeDispenser mentioned, no one is going to burn a 0day just to show you, but you can look at countless patched vulnerabilities. Google for any MFSA (Mozilla Foundation Security Advisorie) for anything that says "arbitrary code execution" or "potentially exploitable crash". These are all vulnerabilities (security bugs), not exploits (code to take advantage of said security bugs).

The way they work varies. It would be too difficult to explain even the basics of any number of classes of vulnerabilities. Look into buffer overruns/underruns, UAFs, ROP (and similar techniques like JOP and LOP), heap spraying, JIT spraying, exploitable undefined behavior, integer overflows, or any other common attack technique.

  I found a lot of blog posts, forum discussions etc. but none of them actually give real examples. They simply talk about how JavaScript is a programming language so it isn’t predictable.

What they are likely talking about is things like buffer overflows and use-after-free vulnerabilities. They mean that JavaScript does not always do what you want it to do, not that the standard itself isn't entirely deterministic.

  JavaScript isn’t unpredictable in a way that let’s it do things it’s not supposed to. Unless of course there is a vulnerability in the browser.

That is correct. JavaScript is not designed to do anything outside of the context of a browser, but what it is designed to do is be parsed and compiled from attacker-controlled sources. A single bug in the interpreter or JIT compiler (among many other things) can result in exploitation. This isn't just an issue with JavaScript. CSS and HTML can also be exploited, though that's less common as they're simpler. WebGL is a common target due to its complexity. Image decoding is also a target.

  Show me code that would for instant delete all the photographs on my machine without me having to explicitly download and run anything. Just visiting a malicious website is enough.

If you want an example of actual code, how about https://github.com/cryptostorm-dev/torsploit, which was used by the US government to attack outdated versions of Tor Browser (which is based on Firefox) a while back. In that specific example, it caused the browser to phone home, bypassing the proxy. The shellcode could be modified to do anything, such as delete pictures on your computer like you said. Honestly, I don't care enough to write shellcode to do something like delete pictures, but it would not be hard. The hard part is getting the code to execute. The easy part is making it do whatever you want.

In that specific example, the shellcode is in the magneto variable. You can change it to whatever you want and it will be executed without restrictions. All you have to do is learn a bit of assembly, enough to write the code without the help of the usual assembler. You can find a huge amount of pre-written shellcode for plugging into a working exploit, though usually it does more interesting things than delete pictures, like install malware.

The way that specific exploit worked was by using a type of heap spraying called JIT spraying (a technique to increase the predictability of the memory layout of the target program), and a simple buffer overflow into the now-predictable code.

See  https://www.exploit-db.com/search/?action=search&description=Mozilla%20Firefox for countless other examples, complete with code. If you want in-depth explanations of how this kind of exploitation is done, I strongly recommend you read some browser-related Phrack articles.

  And no, simply making my browser crash without any permanent damage on my computer doesn’t count.

Unfortunately, virtually all exploitable bugs will result in a harmless crash if they are not designed specially to exploit the application. Most PoCs will show nothing but a crash. You have to live with that. There are absolutely real, weaponized exploits that you can use, but there are not as many in public.

  And to be clear: I only care about browser vulnerabilities, not plugins or other things. And also modern browsers not IE from 2004 (you know what, let’s just ignore IE).

Virtually every single update for a modern browser fixes one or several of these kinds of vulnerabilities. As of this post, Firefox 56 has just updated to fix 5 exploitable crashes with mfsa2017-21, as well as a collection of 12 other potentially exploitable memory-safety crashes. This isn't just an issue of one possibly bad bug every 10 years. This is multiple exploitable bugs every release. In general, any large program which parses complex data can be exploited with malicious crafted input if someone tries to find a vulnerability badly enough. This applies to browsers, image decoders, video or audio decoders, and even your operating system kernel.