What is the evaluation criteria that a site uses for a password as strong , moderate or less secure

Password strength meters are universally limited by the amount of rules and lookups put into them compared to the amount of rules and lookups put into attacking tools, particularly of the offline cracking variety like oclHashcat.

Most common password strength meters use a simplistic algorithm that combines length and some approximation of keyspace to give your reading.  For instance, some will consider an 11 character password with upper case, lower case, numbers, and symbols to be "Very Strong".

  P@$$w0rd123

If you think that "password" with a leading capital, a little common leet-speak, and a 123 at the end is a "very strong" password, I suggest you read up on rules based attacks.  Note that some of the rule sets that come with Hashcat have in excess of thirty thousand rules, and rule sets are commonly used in combination with dictionaries of tens of thousands to billions of words (essentially cartesian joins - for every dictionary word, apply every rule in the rule set chosen), depending on how good the hashing was and how much the attacker invested in GPUs.

Some password strength meters include a small to medium dictionary and a small set of rules (which are much more efficient because they're operating on a cleartext password), such as zxcvbn; however, they're still limited compared to what a good attacker (such as a competitive cracking team at an event or a security research, not even counting real bad actors, using  leaked password list).

The summary is:
If a password strength meter says your password is weak, your password is weak (or the meter is completely broken).

If a password strength meter says your password is strong, ignore it; assume it knows nothing.

Long purely random passwords are as strong as you can get; I second the 14 character minimum, and that's only for a purely randomly generated passphrase.

Random word combinations can be ok, but "correct horse battery staple" as a specific example is pretty bad;three of the words are in a common Top 5000 english word list, and the last one's still in both the phpbb dictionary and the Ubuntu american english small dictionary.  Further analysis at my answer to should i reject obviously poor passwords, but it boils down to the fact that an attacker using a small subset of English words would find this example, and many examples humans would choose on their own, without needing to exhaustively search anywhere close to the entire 4 word combination English language keyspace.

At minimum, choose at random only longer words, after eliminating common words as well.

For instance, take the Ubuntu american english insane dictionary
then remove all words under length 7
then remove all the remaining words that are also in the american english small dictionary
then use a random number generator to select lines and random, and use whatever word is on the line
Even better, put some unique random separators in between them as well

The flaw in correct horse battery staple and the flaw in most password strength estimators is the same; they do math assuming it's randomly generated, and without help, very few humans even come close.  Attackers know this, and work with it and the results of what humans have chosen before that's already been cracked (or was stored in plaintext).


How to exploit buffer overflow without space after return address?

You could deliver a sizeable package with your first request and then craft an smaller exploit to hunt for it in regular memory, see 'egghunters'.


Trip to China - safeguarding phone and laptop

I flagged this as a duplicate because the elements of your question have been asked many times before; it's nothing personal. The linked thread should give you a good idea of what you're facing with your laptop (Chromebook or not) since it's easy to shoot yourself in the foot with bad OPSEC-- you're competing with the combined might of both corporate espionage and national intelligence agencies. Don't make the same mistakes that guy did, like plugging right back in to the corporate network upon return.

Even if you're "nobody important," don't assume you're not a target. You still have value as a patsy. Your credentials are desirable because if captured, they can allow foreign agents (corporate or government) access to your corporate network, within which they'll exfiltrate anything they can touch. The added bonus is that since you're "nobody important," your company may be unlikely to keep an eye on "your" activity-- unlike a higher-profile employee like a lead engineer, sysadmin or executive.

  I assume that if I don't use a local SIM, it would be difficult for someone to put malware on my phone but wanted to confirm if I am right about this

Consider this-- the Chinese government is trying to move to a cashless society by forcing everybody to install WePay on their smartphones. While it serves a purpose (convenient payments), it also makes it so that in order to function at all in society and buy basic goods, you must consent to backdoor/keylog a device critical to your daily operations and have all your transactions monitored remotely.

In practice, it doesn't matter what SIM you use if you end up voluntarily installing government-controlled malware just to pay for McDonald's. That said, plenty of urban centers still take cash, but be wary of the seeming obligation to install random apps to ride the subway, buy things, whatever. Each one compromises your OPSEC.

  I was thinking of taking a Chromebook since that has full disk encryption. I read that it's easier to do a full reset on this than a windows laptop. I have also read that malware can't be installed through USB on a Chromebook

FDE doesn't help if your machine is compromised while it's running and unlocked. The government has been known to replace links to Javascript libraries on unencrypted pages with malicious versions at the Great Firewall level. Browse with HTTPS only; there are plugins for this. VPN is also good, assuming you have one that actually works, and assuming it's not leaking DNS queries that get responded to with state-controlled IPs.

Being forced to unlock laptops at the border is largely a US thing. I haven't heard of anybody being forced to do it in China, but even so, what are your options besides refusal or compliance? Refusal will only end one way. FDE just makes it look like you have something to hide, and if in the end you're going to unlock it for them anyway, what was the point?

My opinion- don't bother with FDE. Just travel with clean images on your phone and laptop and assume both are compromised upon return. Change all your passwords and reimage your devices.


Certificate Revocation List (CRL) checking Best Practice

I would go with strict certificate revocation checking and reject certificate for which revocation information is not available.

Why? If you are going to take actions (reject connection) when the certificate is revoked, you need to have this information (from CRL/OCSP). If the information is not available, you cannot determine whether the certificate is revoked or not. From the security perspective, the certificate is invalid unless opposite is proven. This means that the certificate should be considered revoked unless at least one reliable source (valid CRL and/or OCSP response) tells you that the certificate is not revoked (CRL does not contain subject's serial number in the revoked certificates list and/or OCSP explicitly says that the certificate's revocation status is good).

General rules/algorithm are described in the RFC5280 §6.3


For this kind of purposes, there is a website, keylength.com, that uses various academic and private organizations mathematical formulas to approximate.

If you select 2030 you will get the results.


Can my physical location be detected with double VPN?

If you connect to the company VPN through your routers VPN the source IP seen by the companies VPN is the exit of your routers VPN. This way your company will not see the real IP address, assuming no other leaks exists.
But, the company will see the properties of the IP address from the VPN exit. It can find out that it is not an IP address given by your ISP. It might even be able to associate the IP address with a given VPN provider (i.e. ExpressVPN in your case). Thus, it might not know where exactly you are but it can deduce that you attempt to hide your real IP and that you are therefore likely not at home.


wpa2-psk + wireless isolation = secure connection?

Wireless isolation will stop wireless clients from being able to talk to each other.

It will NOT however stop someone from sniffing the traffic and possibly decrypting it.


Malware spreading through jump server and SSH data transfer

It is highly advisable to use two factor authentication in jump servers. The whole purpose of having a jump server is to segregate a "more trusted" set of resources from a "less trusted" set of resources. For example, by virtue of your desktops being exposed to Internet (and potentially phishing via email), they constitute a less trusted zone. The bar to "jump" into the more trusted (say, servers) zone must be higher than for being in the least trusted zone. Now, if your password got compromised or keys got used or you have ticket forwarding, having a second factor will protect against lateral movement. Malware tends to jump around and spread - having a second factor for protocols such as RDP/SSH prevents malware from abusing those management protocols.

Hope that helps.


As far as memory related issues go, there are still issues e.g. you can still stumble upon a null pointer, use an out of bounds collection index, accidentally share mutable data with other classes, make the application use all its allocated memory, or in some cases where almost all the memory is used and a lot of new temporary objects are created, the GC can take up almost all of the execution time - but most of these are exceptions/errors on the JVM, and can be handled, though they should be avoided with configuration and careful coding, if possible.

Additionally, in scala null is frowned upon in favour of Option, and mutable state in favour of immutable, so with an idiomatic functional style, null and mutability issues are reduced further.

There are a few scala static analysis tools (disclaimer: I'm the maintainer of Linter), but they aren't specialized for security. That said, they often find issues that would crash the application at runtime, make it run slower than necessary, or find code that logically doesn't make sense - all a potential source of security issues. I'd like to mention Wartremover which features checks that restrict the language to a more safe/pure subset.

You can also use the tools that run on the JVM bytecode, e.g. find-sec-bugs plugin for Findbugs. The default Findbugs checks work too, but are triggered by generated scala code, so there are a lot of false positives. The language authors do look at these results, and fix if they find anything, but unfortunately the false positives make Findbugs less useful to the rest of us.

(I'm very interested in hearing if anyone has used any other tools with Scala in the comments)


For a great introduction to the topic of SS7/MAP security (especially SMS Interception), Insinuator has great coverage of the ULIN story, as well as a links to:

The Tobias Engel prezo from CCC that covers competitors to the ULIN as well as mentioning that a Linux server would need SS7 Network access as well as SCCP roaming on the target network(s)
A link to a SANS paper detailing service-provider countermeasures
Discussion of potential intrusion-detect systems for subscribers based on the CryptoPhone

PTSecurty published a paper which mentions a lot of the required elements to perform SMS interception -- https://www.ptsecurity.com/upload/ptcom/SS7-VULNERABILITY-2016-eng.pdf

Using the following 4 resources, I was able to ascertain exactly how all of the elements you described function:

The SS7 Vulnerabilities eBook, available via direct link here -- [PDF] http://www.cellusys.com/?dl_id=14 [PDF]
A book, Mobile Cellular Communication, which covers many of the messages in the section Common channel signalling
The section on SMSC interaction with the VLR in the book, IP Design for Mobile Networks
Chapter 13 on GSM and ANSI-41 Mobile Application Part (MAP) in the book, Signaling System No. 7 (SS7/C7): Protocol, Architecture, and Services -- particularly the discussions around sendRoutingInfoForSM and updateLocation messages


Message signing disabled (dangerous, but default)

Message signing, in this context, refers to SMB (Server Message Block) signing.

Server Message Block (SMB) is a common Windows "application-layer" network protocol, and signing is a feature that allows SMB communications to be digitally "signed" at the "packet-level". The subsequent "signature" provides a mechanism by which a recipient can verify the authenticity of a source.

For example, it is important for Domain Controllers to have SMB signing enabled because SMB is the protocol used by clients to download Group Policy information, and SMB signing provides a way to certify that the client is receiving a genuine Group Policy.

SMB signing is supported on all versions of Windows, but is only enabled by default on Domain Controllers.

Nmap is letting you know that:

SMB signing is disabled;
This is the more dangerous — or less secure — option (as opposed to having SMB signing enabled);
This is the default setting for the system you are scanning.


How are you able to inject bash script through the user agent

What you are refering to is the Shellshock Bug, see https://blog.cloudflare.com/inside-shellshock/

The Shellshock problem specifically occurs when an attacker modifies the origin HTTP request to contain the magic () { :; }; string discussed above.

Suppose the attacker change the User-Agent header above from Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 to simply () { :; }; /bin/eject. This creates the following variable inside a web server:

HTTP_USER_AGENT=() { :; }; /bin/eject

If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed (I've omitted the deeply technical explanations of why () { :; }; makes bash behave like this for the sake of clarity in this essay.)

The problem is that HTTP_USER_AGENT came from the User-Agent header which is something an attacker controls because it comes into the web server in an HTTP request. And that's a recipe for disaster because an attacker can make a vulnerable server run any command it wants (see examples below).

The solution is to upgrade bash to a version that doesn't interpret () { :; }; in a special way.


Should I test my SSL certificate for "RSA Shared Primes" before using it?

If it is simple enough to test, then you might as well do so. I don't know of any service or other mechanism that will do this test for you, but if you do then have at it. The likelihood of an attack is probably pretty slim, but the severity is pretty extreme. It's certainly worth fixing if you detect it.

Yes, any prior sessions, if captured, can be decrypted if your private key can be derived. Unless you use Diffie-Hellman to generate your ephemeral session key (currently extremely uncommon); just search for "Perfect Forward Secrecy" for information about protecting today's sessions against tomorrow's attacks.

Note that your primes are determined when you generate your key, not your certificate. Generating a key costs nothing (but your time) and can be done as many times as you please. So if you're going to test, you might as well generate the key ahead of time (or perhaps several in one go) test, and then generate a CSR based only on a "strong" key. A computer with a good TRNG (such as recent Linuxes and BSDs) is helpful here, since a bad PRNG is typically your source of bad keys.

Also, several CAs will allow you to "re-key" a certificate, which essentially means issue a new one with the original expiration date. So if at any point your key is suspect, that may be an option.


Disable support for static key cipher suites

As stated earlier by Sjoerd 'Static cipher suites are suites that do NOT provide forward secrecy'. So our objective is to limit ciphers suites to those which do have forward secrecy feature.

Forward Secrecy is provided by the ephemeral aspect of DHE (Diffie-Hellman Ephemeral) and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) ciphers.
Ephemeral DH uses a distinct key for each exchange vs. one key for entire session used with fixed DH.

The perfect forward secrecy offered by DHE comes at a price: more computation. The ECDHE variants uses elliptic curve cryptography to reduce this computational cost.

The list provided by Roger Martínez Hernández above includes only those cipher suites that have DHE or ECDHE in them. So the list is good. An easy way to implement this is to use IIS Crypto 3.0 and select or check only these ciphers from the "Cipher Suites" section.


Would it be possible to extract user agent strings from 3G/4G Data

Mobile carriers have limited capabilities of performing mass deep packet inspection on their infrastructure. One proof is the lack of incentive for many carriers to detect DNS tunneling through their mobile networks (DNS traffic is not being charged).

This document presents an overview of 3G and 4G mobile services and methods supporting the lawful interception of targets subscribing to these services:
http://www.aqsacom.com/resources/pdf/LI-3G-4G-AQSA_WP_2012_01.pdf

These interception systems cover a wide range of services and technologies, including wire-line voice, wireless voice, wired and wireless data, and emerging services such as VOIP. Deep packet inspection can be performed during these intercepts and data such as user agent strings can be extracted.


Giving malicious crawlers and scripts a hard time

You're hurting yourself.

The "attacker"/crawler... probably doesn't pay for their traffic or processing power (ie. they use a botnet, hijacked servers or at least are on a connection that doesn't make them pay for traffic), but you will be billed for traffic and CPU/storage/memory, or your server's hoster has a "fair usage" clause, under which your server's connection will be throttled or cut off if you serve Gigabytes of data on the short term, or your storage bandwidth will be reduced, or your CPU usage limited.

Also, why should anyone be so stupid to download Gigabytes of data when they're just looking for a specific page? Either, they're just looking for existence of that page, in which case the page's size won't matter, or they will definitely set both a timeout and a maximum size – no use waiting seconds for a server to complete a response if you've got hundreds of other servers to scan, and especially not when greylisting is a well-known technology to slow down attackers.


This won't work with reverse payloads unless you can do portforwarding on the system which is NATing your traffic. Hence it's better to generate a payload which allows you to connect to it rather than a payload which connects back (but if your target is also using NAT, then this becomes obsolete as well). For instance:

shell/bind_tcp

This does give problems if there is a firewall between you and the target. Best thing to do is take away the NAT completely if possible. In your case this seems quite difficult...


Specific security concerns with (now unupdatable) Win XP

Using an unsupported OS will leave you at risk.  Note, that with the latest IE zero-day vulnerability released in the wild, XP was still given an out-of-band patch as about 25% of desktop users still use XP (in May 2014 - judged by internet traffic user agent strings).  However, you should not expect Microsoft to continue to patch XP in the future.

You really should upgrade to Win 7 (or Win8) or switch to Linux.  Linux will still need to be periodically upgraded, but it is often easier to gracefully upgrade, as the upgrade is free, you don't have to deal with license issues, and it is often easier to automate the process.

As for what attacks you'll be vulnerable to will completely depend on the future attack.  DDoS isn't a particularly worry - in that servers (or your home router) typically worry about that attack (and in that modern OSes don't have much protection against DDoS attacks).  Something like a ping-based attack could happen if someone finds flaws in their networking stack.  And again browsing the web very much puts you at risk, especially with tools like Flash, JavaScript, Java, etc enabled.  Even if you don't search out sketchy sites (e.g., looking for pirated software/media), its very easy to accidentally go to the wrong site (be tricked into clicking a random link).  Or an exploit on some live trustworthy website causes your browser to forward to an untrusted page.


What does ModSecurity bring to my hosting account?

what extra security does this bring

Out of the box? None. You need to add rules to the system in order to start restricting access. The problem is that some of these may break your application.

We don't know what your magic button in cPanel does. I would recommend you have a look at the OWASP rules. If they don't make any sense to you then you need to work on your knowledge of HTTP, attack methods and mod_security before you press that button. And you should be asking the people who provided the button to tell you what it does.

You didn't say if this was a VM, container or shared host.

  I look to minimise our risk of attack

Is that your question or are you only asking about mod_security? Your biggest risk is probably the applications you are running on your server. Keeping them patched and up to date will therefore give you your biggest security wins. Similar for the underlying OS and distribution.

The attack you reference in your post was possible because the admins had not installed a patch available from the software supplier.


Security of certificate when using DNSSEC

Plain DNSSEC

DNSSEC only secures DNS records, and on its own does not help at verifying certificates. This mitigates DNS hijacking (when some man in the middle, for example a network provider threatened by governments) returns faked DNS records.

It does not help against other attacks, especially redirecting the traffic (without spoofing the DNS records) or tampering the traffic in-between (and wrapping it in TLS again). In this case, an attacker could use a valid certificate issued by a compromised CA.

DANE

DANE uses special, DNSSEC-signed DNS records (TLSA-records) which declare what certificates are allowed for a domain. If you put together DNSSEC and DANE, it is possible to either declare self-signed certificates as trusted (verified against the DNSSEC trust hierarchy), or have a second validation path of CA-signed certificates.

The large disadvantage of DANE: implementation coverage is still very, very low; pretty much nobody is using (or even able to use) it at the time of this answer: Firefox and Chrome plugins are available, and Postfix has support for it.


Using public IP addresses inside site-to-site VPN

Yes, it's done quite often. Using public addresses eliminates a lot of problems when connecting multiple networks which use the same addresses in their local networks. If you're connecting multiple networks with the same IP ranges on the inside, things can get very, very ugly with very complicated NAT setups.

Of course, only public IP addresses actually assigned to the networks should be used or you'll probably be blocking some part of the public internet.


Firstly, firewall is not a magic word: simply installing one at random without a clear idea of what you want it to do is not going to help.

Secondly, neither NAC nor IPS are VPN solutions, so you need your contractor to explain her recommendations again.

More generally, firewalls used in conjunction with a VPN are normally designed to restrict what the VPNed in user can access on your internal network. By default a VPN connects a remote user over the public Internet to your internal network, giving them the exact same access as if they came into your server farm and connected their machine there.

Sometimes you want people coming in via VPN to have less than total access to the internal network: you do this by putting a firewall between the VPN connections and the rest of the network.

In this way you can define firewall rules such as "if someone comes in over VPN, only allow them access to servers A, B, and C, and nothing else."


At what level of abstraction should a developer work with with regards to cryptography?

Half of cryptography is about the raw algorithms, like SHA-256 or AES. The other half is about assembling these algorithms into complete protocols like, for instance, SSL/TLS; designing a secure protocol is not easier than building a secure algorithm. When a developer meddles with an algorithm, then, by definition, he is in the process of creating his own protocol, i.e. doing his own crypto. Thus, caution is advised.

In an ideal world, a developer would:

analyze the problem he is trying to solve;
find an existing, vetted, thoroughly verified protocol which matches his problem;
use a library with a well-designed API, which implements the protocol (and its underlying cryptographic algorithms) with all the care that is needed for such things.

Unfortunately, the real world happens to be, as it were, real, i.e. not ideal at all. Available libraries often have a difficult to use API, mostly because the library designer was overenthusiastic: he took great pains to understand how the protocol works, and he wants to share. Thus, he makes an API which exposes a lot of how the protocol works internally, and the library user is confused.

Moreover, there are not so many ready-to-use protocols. You would like to find a protocol which applies to your problem; but you often have to squeeze and shove and torture your problem until it looks like something which fits one of the few existing "all-purpose" protocols (namely, SSL or bcrypt). When your only tool is a hammer, all problems are strongly expected to behave like nails.

And, of course, developers do not analyze their problems. They first code it, then they throw cryptography at it as a kind of exorcism against the demons of insecurity.

Developers should not have to think about cryptography except at a very high level of abstraction, using existing implementations of protocols. But since it is not practical, due to the general lack of ready protocols and available implementations, developers must get their hands dirty and understand cryptography down to the minutest details. This is not specific to the field of cryptography, but cryptography has an aggravating characteristic which is that you cannot test security: you can know that your product is secure only by having many people look at it and think real hard. If you are outside of the existing protocols where such scrutiny already took place, then you are doomed to do your own thinking.

Now if you think that my conclusion is that, on average, cryptography is sloppily applied by developers who do not grasp it, leading to countless vulnerabilities and a general state of rampant chaos, well, you guessed well.


Blocking Business Email Compromise (BEC) emails

If the sending account uses an alias that is an internal account, then it is easy to detect and block.

From: Ali@example.com <bad@evil.com>

Each server will have their own methods to do this.

If the external server is spoofing an internal email, then you need to employ SPF, DMARC, DKIM.


Does EFS protect against data theft by ransomware?

When you copy the file to a flash drive, it remains encrypted

When EFS-encrypted file is copied to a drive that do no support encryption (FAT/exFAT families), the file is decrypted before copied and copy is unencrypted. I believe that only NTFS-formatted drives support encrypted file copy.
If you attempt to ZIP the file, it is decrypted first and then zipped (encrypted files does not support compression). In other words, transferring EFS files removes the encryption.
This means that if attackers run something under your account which can decrypt the file, then attacker can get to raw unencrypted content.
The purpose of EFS is to provide security for offline (when you are not logged on) and other user access (locally or remotely).


Stream/block cipher add a simple hash to guarantee integrity

Why it does not guarantee integrity is easier to see in the case of a stream cipher like RC4, where the encryption is a bit-by-bit XOR of the data with a key-dependent stream. Basically, the encryption of message m is: e = m XOR sk, where sk is the RC4 output (a long stream of pseudorandom bits produced from the key k). Suppose that you apply the "append hash then encrypt" method. You start with message m, and you get this:

    e = (m || h(m)) XOR sk

Now an attacker comes by, and he is smart, and he guesses the contents of m (remember: the attacker is after integrity, not confidentiality, so we assume that he already knows the message). Since a hash function has no key, the attacker can recompute m||h(m). From that he gets:

    sk = (m || h(m)) XOR e

Now the attacker has the key-dependent secret stream sk. He then proceeds to encrypt his fake message m' by computing:

    e' = (m' || h(m')) XOR sk

This works as along as m' is not longer than m (it could be shorter). Upon decryption, the hash will match, and integrity is defeated. Fun fact: I know a system for Web-based online banking that was using this construction for integrity, and was widely deployed. Fortunately, it has been fixed more than a decade ago.


What are good precautions to take before cleaning an infected website?

First of all if you are downloading and running code from an infected website, you basically may infect your machine. So at this point it's time for you to format your computer and reinstall everything.

Second of all when doing incident response (which this basically is) you always start from a fresh build with your tools, either in a virtual machine or on a physical machine, and download the files to your machine. You can then analyze the malware. Afterwards you either discard or store the image. You then copy your clean image again for your next IR. You NEVER re-use the same OS where you already did analysis on.

Also refer to our topic here How do I deal with a compromised server?


What vulnerabilities are there for a website that does not use SSL for a login page (or any pages)

SSL/TLS provides confidentiality, integrity and trust. Trust being the most important one, giving the client assurance they are really communicating with the person they thought they were. In case of SSL/TLS; without trust there is no point in encrypting data. Anyone can pass itself of as the intended party, and you wouldn't be able to verify this.

The other way around doesn't work either, and allows for an attacker to listen in and change the data. The internet is just a bunch of networks connected to each other, and because you can only protect your LAN at best, we conciser the internet to be an insecure channel. Network interception is no science fiction, and happens on large scale (your ISP, telecom provider, governments, etc) without targeting you in specific.

  I personally find that unlikely and so I'm wondering how severe is this vulnerability these days?

The opposite is true. In the last few years demand for secure communications has never been this high, and this is no paranoia. You really should care about SSL/TLS, and use them whenever possible. Anything that send personal data back and forth should use SSL/TLS, although this isn't the case by far, unfortunately. But, if you are going to setup an SSL/TLS secure environment, do it the right way. It has been argued that wrong SSL deployments can cause more harm then do good. In information security there is no such thing as doing it half.


Is SSL over HIP (Host Identity Protocol) possible?

Cisco says that HIP is an alternate to TLS:

  HIP provides a network layer alternative to using Secure Sockets
  Layer/Transport Layer Security (SSL/TLS) for application security,
  which has its benefits and drawbacks. HIP is a generic solution that
  should work for any transport protocol, whereas until recently TLS
  supported only TCP. HIP enables host mobility and multihoming, which
  is not supported by TLS. TLS runs on top of TCP, leaving it vulnerable
  to various TCP attacks; for example, using spoofed reset (RST) packets
  or DoS attacks with SYNs. Applications must be designed explicitly to
  use TLS, whereas HIP can provide security as an add-on to existing
  traditional applications. On the other hand, TLS does not have a
  problem with traversing traditional middle-boxes such as NATs and
  firewalls that need special attention for HIP. Both protocols share
  the characteristic of endorsing host identity. TLS relies on
  certificates issued by one of the known Certification Authorities,
  whereas HIP can use Domain Name System Security Extensions (DNSSEC)
  [18] or a PKI infrastructure.

As for whether it is possible to run TLS over HIPS, it doesn't seem possible. There is great conflict in the layers they interact on.


Which strategy to encrypt data accessed by multiple users?

TL;DR: Generate a data-key pair, encrypt the private part with the public key of all users that have write access, encrypt the public part with the public key of all users that have read access.

Let's tackle this one by one:

  Data must be securely encrypted in the database

  This is to secure against attackers, and mainly for the users to know that even the staff cannot access their data, hence the keys must not be accessible by the tech team.

Given this requirement, the most important property you need to consider is that under no circumstances that the server can obtain the information necessary to encrypt or decrypt the data. This implies that all encryption/decryption must happen on the client side. Since web-based system is inherently insecure when you need to do end-to-end encryption, due to the ability of the server to inject JavaScript code-on-demand; the more security conscious users would want to control the client software used to access the service, so they would want this implemented as a desktop application.

  Data is scoped to user accounts
  The owner of the encrypted data must be able to give access to his data to other users

These two constraints means that multiple users will need to be able to decrypt the data. This means that the secret to decrypt the data needs to be shared to the other users.

  Other users can be revoked from this given access

  Meaning that, if we consider the private/public key solution we must be able to delete the private key that was given to the user being revoked.

To revoke access you need to reencrypt the data with a new key. As other answers have discussed, you cannot enforce forgetfulness.

The best way to describe this, is perhaps by way of an example.

Notations:

P(x) is the private key named x.
Q(x) is the matching public key for x.
e = E(d, Q(x)) means e is the result of encrypting plaintext d with public key x.
d = D(e, P(x)) means d is the result of decrypting the ciphertext e with private key x.

Suppose that Alice wants to share data to Bob, Charlie, and Dave. Alice wants to allow Bob to be able to read and write the data, Charlie can read the data but not produce a valid data, and Dave can only write but not decrypt what others have written (essentially it is a drop folder to Dave).

All users have user-key pairs. P(Alice), Q(Alice) is Alice's user-key pair; P(Bob), Q(Bob) is Bob's user-key pair; P(Charlie), Q(Charlie) is Charlie's user-key; and P(Dave), Q(Dave) is Dave's user-key pair.

The system has a registry of user-key where users can share the public part of their user-key. How a user can securely retrieve and authenticate another user's user-key is beyond the scope of this answer and is left as an exercise to the reader. Most users may simply put some faith on the access restrictions that you put on your server, but the more security-conscious users would need to do something similar to a GPG key signing party;.

All users are expected to keep the private part of their user-key a secret for themselves. How to do this in details is beyond the scope of this answer, but you definitely don't want to store the private user-key in the server unencrypted. Instead what I suggest can encrypt the user-key with a symmetric key derived from the user password and a salt, then store the encrypted user-key and the salt on the server.

To store the data "Hello World" securely, Alice starts by generating a data-key pair: P(data), Q(data). Alice then encrypts the data with the data-key public key:

plaintext = "Hello World"
ciphertext = E(plaintext, Q(data))

Given the properties of public key cryptography, we know that ciphertext can only be decrypted by someone that knows P(data). (Note that the notion of private and public for a data-key is just a matter of convention, both P(data) and Q(data) must be kept private from everyone that doesn't need them, like the server)

Alice wants to allow Bob and Charlie to be able to read this data, so Alice retrieves Bob's and Charlie's public key Q(Bob) and Q(Charlie) and encrypts P(data) with them, additionally to allow Alice to decrypt the file in the future, possibly from a different machine, Alice does the same operation with her own public key:

alice_read_key = E(P(data), Q(Alice))
bob_read_key = E(P(data), Q(Bob))
charlie_read_key = E(P(data), Q(Charlie))

Alice wants to allow Bob and Dave to be able to write data that can be read by Alice, Bob, and Charlie. Alice also wants to be able to update the data in the future. To be able to do this, Alice encrypts the public data-key Q(data) using Q(Alice), Q(Bob), and Q(Dave):

alice_write_key = E(Q(data), Q(Alice))
bob_write_key = E(Q(data), Q(Bob))
charlie_write_key = E(Q(data), Q(Charlie))

Alice then sends all of encrypted_key, alice_read_key, bob_read_key, charlie_read_key, alice_write_key, bob_write_key, and charlie_write_key to the server.

Since the server/attacker is never in possession of P(data) or Q(data) and since the server also do not have the private key to decrypt any of the read_keys, the server would not be able to decrypt ciphertext.

When Charlie wants to retrieve the data, what he does is he needs to download both ciphertext and charlie_read_key and decrypts charlie_read_key with his private user-key to obtain P(data) and then use P(data) to decrypt ciphertext:

P(data) = D(charlie_read_key, P(Charlie))
plaintext = D(ciphertext, P(data))

Now Charlie is in possession of plaintext. However, as Charlie does not have a write-key, he does not have a Q(data), so he would not be able to update data in the system in a way that others would be able to successfully decrypt.

Next, Dave needs to be able to add to the data. He cannot read the ciphertext but he can append to it by decrypting his write-key to get the Q(data):

new_plaintext = "New Data"
Q(data) = D(dave_write_key, P(Dave))
new_ciphertext = E(new_plaintext, Q(data))
updated_ciphertext = ciphertext + new_ciphertext

Now Dave can send updated_ciphertext to the server.

(Note that in most asymmetric encryption algorithms, you cannot simply concatenate two ciphertexts and expect to be able to decrypt it, so you may need to store some metadata that keeps the ciphertext blocks separate and decrypt them separately)

This leaves us with only revocation. To revoke access, you need to have at least P(data) to decrypt the ciphertext back to plaintext, generate a new data-key pair: P'(data), Q'(data), and reencrypt the plaintext with the new data-key pair:

plaintext = D(ciphertext, P(data))
new_ciphertext = E(plaintext, Q'(data))

and then you'll need to update everyone's write-keys and read-keys.

To add a new user to an existing file, all you need to do is just create their write-key and read-key. Only people that themselves can decrypt their read-key can extend a read-key to a new user, and only people that themselves can decrypt their write-key can extend a write-key to a new user.

If you do not need the fine-grained permission permission in this system, (IOW, if all users that can read the data can also update it); or if you use other ways to enforce fine-grained permissions, then you can replace the asymmetric data-key with a symmetric data-key (Trivia: the system with symmetric data-key would be similar to how multi-recipient PGP-encrypted email works; so you may want to investigate that).


Infect an existing Android app with malware and redistribute

Possible yes, but it would not install as the same app. Also most (all?) apps on Google Play are signed with a certificate with vouches for authenticity.

An example:
They take the official YouTube-App, modify it and replace the real YouTube-App on your device with their fake. In Google Play, the app will show as "Not installed" and you may install the real one parallel to the fake one. The reason is the different signature and maybe different package names.


Boot Attacks possible on encryption keys used in virtual machines

Let's say a virtual machine uses full disk encryption to encrypt its virtual disk.

If I have access to the host on which the virtual machine runs, I can simply dump the portions of RAM in use by that virtual machine and recover the encryption key for the virtual disk. Not to mention anything else that happens to be in RAM.

In this scenario you (1) have to trust the host, and (2) would be better served by having the host do the disk encryption, assuming you control it, which would defeat the above attack (though you still have to worry about the cold boot attack and other compromises of the host).


How can I extract the certificate from this pcap file?

With new versions of wireshark:

Make sure the traffic is decoded as SSL, i.e. setup the SSL analyzer for this TCP stream in Analyze >> Decode As. Now it will show the SSL details for the packets.
Pick the packet which contains the certificate, in this case packet 6.
In the packet details expand Secure Socket Layer etc until you get to the certificate itself:

Use the context menu (right click) and save the raw data of the certificate with Export Packet Bytes into a file, for example cert.der.
With openssl x509 -inform der -in cert.der -text you can have a look at the certificate, with openssl x509 -inform der -in cert.der -outform pem -out cert.crt you can convert it into a PEM format (i.e. what you mean with crt format).


What is the meaning of KEX DH host key and KEX DH H signature in SSH key exchange

DH server f - the exchange value used to calculate a shared secret.

KEX DH H signature - the signed exchange hash, which is used to authenticate the key exchange.

KEX DH host key - the public key of the server, used to sign the exchange hash

See RFC 4253, Section 7.2 for more details.


Can a company see where you've taken their mobile hot spot?

I would assume they would be able to as long as the hotspot is on, they could call their provider of the hotspot and get them to trace it.


How do I convert from this weird John/Asleap format to lc (for HashCat)?

This hashcat thread claims that simply rearranging the fields should be sufficient - but hashcat only recognizes the resulting hash as NetNTLMv1, not v2.

$ cat john.hash
Domain\User:$NETNTLM$57822355cd6810ed$6ddcaca61ecbeab77fdcb4088930b6826e3715a41e921fb6

$ cat john.hash | perl -ne '/(.*?):\$.*?\$(.*?)\$(.*)/; print "$1::::$3:$2\n";'
Domain\User::::6ddcaca61ecbeab77fdcb4088930b6826e3715a41e921fb6:57822355cd6810ed

... but it's not recognized as NetNTLMv2:

$ hashcat -m 5600 --quiet -O -a 3 hashcat.hash hash?l?l?l
Hashfile 'hashcat.hash' on line 1 (Domain...e3715a41e921fb6:57822355cd6810ed): Salt-length exception
No hashes loaded.

... and I can't crack it as "hashcat" and NetNTLMv1:

$ hashcat -m 5500 --quiet -O -a 3 hashcat.hash hash?l?l?l
$
[no output]


Where to find about web application vulnerabilities' history?

You can

search the CVE list for keywords or specific CVEs and
search the NVD of the NIST.

Those two links should be fine to answer questions you might have about individual vulnerabilities - not only constrained to web applications - although they do not usually disclose the actual person that found the vulnerability.


How to defend against SSL-Exhaustion attacks?

"SSL exhaustion" is a mean looking expression for a more generic attack known as "not playing nice". In broad terms, it goes like this: a server is offering a network service, which, on the server, is not free: when a client comes, the server must invest some of its precious CPU cycles into responding to that client. The "attacker" is then someone who mimics many needy clients, overburdening the server. In the case of SSL, the investment is substantial because of the involved cryptography; but the concept also works when the server effort is the meagre amount of CPU and RAM needed to simply establish a TCP connection (that's called SYN flood, but, from a high level point of view, this is the same thing).

A possible countermeasure (not possible in the case of SSL as it is, but it could be added as part of a modification of the protocol) is to require a "proof of work" from the client. In SSL, it is easy to mimic the initial steps of a client connection without doing any of the hard cryptographic work (simply send random junk instead of the expected RSA-encrypted pre-master key, or the client Diffie-Hellman public key): this is what should be changed. There are some pointers on the Wikipedia page on that subject.

For SSL as currently specified and deployed, you have no choice but to:

try to identify offenders early enough, e.g. too many repeated connection requests from the same IP (this means that you block DoS which is not DDoS -- in simple words, the attacker will need to hire underlings / zombies);
select cipher suites which are "cheap" for the server (don't use oversized keys ! 1536 bits are enough)(try RSA instead of DHE_RSA);
counter the attacker by putting more muscle in it, e.g. hardware accelerators, or more PC (PC may be cheaper, but use more hosting space, and load balancing requires some additional system administration).


Securing application-application communication from devs and admin

I have seen something similar to this done before, but there is a pretty massive downside: the only way you can guarantee it to work is by preventing all human access to the machine where B resides. It was accomplished like this:

System A is configured to only accept calls from System B. System B is a virtual machine image which contains only a single admin user, and on first boot a script runs which changes the admin password to a long random one using a cryptographically secure algorithm. At this point the only way to stop it is to shutdown the VM. Edits are made by changing the image and starting it up again.

This isn't a perfect solution, as an admin on the virtual machine's host could take a memory dump and possibly extract some of the "sensitive" data while it is being processed. (Thanks Philipp for pointing this out.)


Bitlocker lock drive on standby or switch users

This is not what Bitlocker is for.

Full Disk Encryption (FDE) tools like Bitlocker are only meant to protect against off-line attacks. This is where the computer's operating system is not running.

Examples might be if the disk is removed and mounted in another computer, or if the computer is booted from a LiveCD or similar.

When the OS is running - which includes when the laptop is in standby - then it is the OS's job to protect the contents of the disk.


How does the hacker protect himself when using reverse_tcp?

"Spoof" may be a poor term that will lead you down unhelpful paths.

You want to obfuscate your location. Dynamic DNS or pivoting off of another server that you have cracked are ways to put layers in between yourself and the target and not expose yourself directly.

So, the victim connects to a static address (Dyn DNS or static IP of another hacked server), and then the attacker connects to this intermediate layer with a changing IP (free wifi, large network with NAT like a school, etc.).


Is TLS security for web server reliable or suffer a major design flaw

Is there any plan to replace this protocol with something more reliable, or is it that most problems are implementation-based and all those best practices/RFCs are there to mitigate possible human error?

There isn't a simple answer here, so I would "yes and no to all of the above". There are lots of factors at play.

Is TLS flawed?

Much like any other protocol (take HTTP or HTML for example) SSL/TLS is an evolving standard. Like any other protocol, it evolves to include:

new features (ex. DNS CAA or OCSP which give higher security)
performance enhancements (ex. OCSP stapling, and a lot of the TLS 1.3 stuff to improve speed and bandwidth usage)
new use-cases that reflect the changing way in which the internet is built (ex. wildcard vs multi-domain vs multiple certs in a load-balanced cloud server context).

Unlike other protocols, TLS also needs to keep up with increases in the CPU power available to hackers, and cryptographic research (both research into new algorithms, and research into breaking existing algorithms). That's why you see new ciphers added, old ones dropped, and key sizes gradually increase.

I wouldn't say that TLS is flawed, but rather that, like any software, TLS is being improved over time to reflect the changing internet.

Implementation errors

You are right to point out that most of the egregious vulnerabilities in TLS are not due to a problem with the TLS specification, but due to programmers not following that spec properly. Two examples come to mind:

Mining your Ps and Qs

[Paper]

The issue here is with (mainly) small embedded devices (think home routers or internet-enabled webcams) that need to generate TLS server keys on first boot-up. Turns out these devices all roll out of the factory almost identical, which means the keys they generate on first boot are not very random.

This is certainly a TLS vulnerability, but is not the fault of the TLS spec.

ROBOT

[Project homepage]

Here, the TLS spec (RFC 5246 section 7.4.7.1) gives very clear instructions for how to avoid Bleichenbacher-style attacks:

As described by Klima [KPR03], these vulnerabilities can be avoided
by treating incorrectly formatted message blocks and/or mismatched
version numbers in a manner indistinguishable from correctly
formatted RSA blocks.  In other words:

  1. Generate a string R of 46 random bytes

  2. Decrypt the message to recover the plaintext M

  3. If the PKCS#1 padding is not correct, or the length of message
     M is not exactly 48 bytes:
        pre_master_secret = ClientHello.client_version || R
     else If ClientHello.client_version <= TLS 1.0, and version
     number check is explicitly disabled:
        pre_master_secret = M
     else:
        pre_master_secret = ClientHello.client_version || M[2..47]

That's 3 pretty straight-forward steps. Turns out that the software developers behind a large number of the TLS implementations out there did not these steps properly, leading to vulnerabilities.

Again, his is certainly a TLS vulnerability, but is not the fault of the TLS spec.


Our domain being spoofed by email addresses to try and spear phish us - how to prevent

You can implement DMARC - https://dmarc.org/ - DMARC is a standard that allows you to specify mail servers that are valid for sending your email and contain some processes for filtering mail appropriately when it does not.


Readers may wish to see this question first, as it's a simpler presentation.  Or go to the source, which is the PCI SSC Information Supplement: Protecting Telephone-based Payment Card Data

  For a non-automated payment card entry system, if a caller is
  providing a payment card details over the phone to a call centre
  employee who confirms the number to the caller, does that mean the
  organisation is non-PCI DSS compliant?

If the call is recorded, here are the PCI DSS compliance requirements:

The recording must be "encrypted using strong cryptography, or otherwise rendered unusable."  So the card number - the PAN - may be recorded, but the recording must be encrypted.
Some parts of the call, however, may not be recorded: it is "prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization."

If the call is not recorded, then the PCI DSS does not apply (to the call - if the human call center employee is typing the card number they hear into a computer, the DSS starts applying there).

  Automated payment card entry system that typically include call
  recording and masking the bit where the caller says the number.
  Assuming this satisfies the PCI-DSS compliance, is there a way an
  attacker can steal the payment card data?

If the PAN portion of the recording is stored encrypted, then an attacker would have to compromise that encryption control.  That's certainly not impossible, but it represents a significant barrier that has to be overcome.

If the PAN portion of the recording is masked, that may be impossible to compromise.

If you PCI compliant, the CVV isn't on the recording, which would be impossible to compromise.

For all of these scenarios, the call center employee is going to enter the card data into a system for processing.  Everything else being equal, the attacker is going to focus on the processing end of the chain, not the call end - voice is analog and messy, but processing systems are juicy and digital.  And that's where the rest of the DSS kicks in...


Which tool/key manager to manage people's public keys in organization?

GPG and SSH are actually designed for different scenarios. GPG is typically used to identify the user so it would make sense for each user to only have one GPG keypair. However, SSH is typically designed to identify the client device - in other words you want each computer to have its its own SSH keypair.

Personally I use Lastpass to manage my GPG key, but NO SSH keys - my SSH private keys are never shared and never leave the clients they were generated on. I researched various password/key managers many years back (even answering some Lastpass questions here as well: answer 1, answer 2), and liked the Lastpass cloud approach for convenience, sharing of passwords with family members, and their approach seems secure.

One keypair per client. Each SSH client should generate its own SSH key pair, which should not be shared with any other device. So if I have a desktop computer and a laptop, they should each generate their own keypair. From a security perspective, it is best if the private key is never transmitted across a network or shared with any other device - it is only ever used by the device that generated it. This approach allows for scenarios where if you get a new laptop you can simply unregister the public key associated with the old laptop without affecting your desktop key.

Registration. You will need an alternative login mechanism to be able to add the public key of each client, presumably to the SKS server. Ideally, this alternative login mechanism should also be protected by a second factor.

SSH is commonly used by cloud git repositories such as github so you might find it helpful to see how it works there - particularly, the public key registration process.


How effective is disabling Firefox's geo.enabled setting for increasing anonymity?

geo.enabled is a Firefox configuration setting that controls location-aware browsing.  From that page:

  When you visit a location-aware website, Firefox will ask you if you want to share your location.

  If you consent, Firefox gathers information about nearby wireless access points and your computer’s IP address. Then Firefox sends this information to the default geolocation service provider, Google Location Services, to get an estimate of your location. That location estimate is then shared with the requesting website.

If you are concerned about anonymity, I highly recommend using the Tor Browser Bundle for your browsing.


Record Header as part of Handshake messages on TCP/IP stack

This is implementation-dependent. The RFC says clearly that messages with the same content type MAY be put together into the same record but also that a single message might spread over multiple records. From RFC 5246 (TLS 1.2) section 6.2.1 Fragmentation:

  Client
     message boundaries are not preserved in the record layer (i.e.,
     multiple client messages of the same ContentType MAY be coalesced
     into a single TLSPlaintext record, or a single message MAY be
     fragmented across several records).


How can someone go off-web, and anonymise themselves after a life online?

The problem is heuristics. All mentioned tools are built on heuristics and the only way to avoid them is to change how you live completely. You can be fingerprinted by the modules installed in your browser. By the programs you use and the frequency you use them.

These days you're going further than just online behavior. Shops know what you buy in what amounts, because nobody buys all the same brands you are getting fingerprinted constantly. This is used for targeted advertising, but it can also theoretically be used to track you.

MIT's Reality Mining project proved the same using smartphones. You prefer certain apps, you use your phone at certain intervals, you move around certain places. This all contributes to a somewhat unique pattern (back when I did some research on it during my internship we were getting 91% certainty in simulations, even when people changed their SIM card every few days we were still able to track them  based on the SSIDs they encountered, places they went, apps they installed and used, when they checked their phones, Bluetooth devices they connect to, cell towers they passed at a certain moment in time and what smileys they use in text messages).

Avoiding heuristics means changing everything you do completely. Stop using the same apps, accounts, go live somewhere else and do not buy the same food from the same brands. The problem here is that this might also pop up as a special pattern because it is so atypical.

Changing your identity is the first step. The second one is not being discovered. As Thomas said the internet doesn't forget. This means that photos of you will remain online, messages you posted, maybe even IDs you shared will remain on the net. So even when changing your behavior it only will need one picture which might expose you.


Is there an advantage to request the same information if authentication fails?

It prevents replay attack. If the attacker manages to intercept the partial memorable word from a number of previous interaction, the attacker can simply refresh the page until they are asked the part of memorable word that they know about. Pinning the part of the memorable word prevents the attacker from doing so.

Note that this is simply a poor man's implementation of OTP. A better implementation to prevent replay attack is to use hardware token, text message, or RFC 6238 compliant TOTP app like Google Authenticator.


You can authenticate based on certificate, username/password or by using a combination.

The reason why you do not want to use just a single certificate, without username or password, is that it will reduce your accountability as you can't pinpoint a single connection to a single person with certainty. You can use username and password as a measure to resolve this issue.

It's better  to implement a certificate per client as well as username/password. It will give you a form of 2 factor authentication setup (its effectiveness is debatable if stored on the same computer).

Something the client has: his certificate
Something the client knows: username and password


How do hackers find vulnerabilities in closed source operating systems?

Reverse engineering, is the process by which a man-made object is deconstructed to reveal its designs, architecture, or to extract knowledge from the object; similar to scientific research, the only difference being that scientific research is about a natural phenomenon. This is how we begin.

This is not an exploit I coded and deployed, but rather noticed on Windows 7 startup recovery would sometimes after finishing checks open the results in notepad.exe. More importantly, I presumed notepad.exe was running as an elevated administrator, also notepad.exe has the ability to open Windows Explorer. So, now I had elevated administrator privileges over all listed drive partitions. Now I could ensure cmd.exe could be executed from the lock screen, which also runs as a restricted elevated administrator. This is how I became a local admin on a computer which I was only a user and the machine had bios passwords, to protect against this type of attack. Furthermore, this attack could bypass BitLocker if it had been used.

This is one type of way, which I deduced Windows 7 had an attack vector, which I happened to be right about. Although, I suspect your question was focused around zero-day exploits. So, reverse engineering tools are often the way. This becomes black box testing.

With compiled code, I am presuming the programmer coded the program in a particular manner while observing how the input affects the output.

Input() = 3
Code()  = ... (We don't know, it's compiled)
Output() = 10

We can deduce now, based on the input being 3 and the output being 10. A likely calculation could be 3*3 + 1 = 10. Although, it could also be 3*4 - 2 = 10... What about if we do another:

Input() = 5
Code() = ...
Output () = 16

So, the pattern 5*3 + 1 = 16 could be a common pattern, we deduce other results and find which match between our tested inputs and outputs.

So a common arithmetic formula, for the code could be sum = $input * 3 + 1.

Now we have narrowed down what Reverse engineering is, let's focus on exploiting a networking service, Safari on iOS 4.0.2 which allowed '.pdf' Local Privilege Escalation 'Jailbreak'. An exploit like this would have likely, been detected by noticing the browser would crash (often a buffer overflow) when loading a PDF under certain conditions. Specifically CVE-2010-1797

  Multiple stack-based buffer overflows in the
  cff_decoder_parse_charstrings function in the CFF Type2 CharStrings
  interpreter in cff/cffgload.c in FreeType before 2.4.2, as used in
  Apple iOS before 4.0.2 on the iPhone and iPod touch and before 3.2.2
  on the iPad, allow remote attackers to execute arbitrary code or cause
  a denial of service (memory corruption) via crafted CFF opcodes in
  embedded fonts in a PDF document, as demonstrated by JailbreakMe.
  NOTE: some of these details are obtained from third party information.

This exploit allowed shown in JailbreakMe, allow arbitrary code within the web browser to be executed and elevated to root privileges without your permission. The browser would crash followed by the iOS restarting, somewhat often on iOS 4.

  OllyDbg is a 32-bit assembler level analysing debugger for Microsoft®
  Windows®. Emphasis on binary code analysis makes it particularly
  useful in cases where a source is unavailable.

Beginning Reverse Engineering Tutorial 1 [HD] outlines how OllyDbg works and should introduce you to using this particular tool for reverse engineering.

This is far from a comprehensive guide about reverse engineering. As points regarding Sqlmap, dex2jar, jd-gui, edb-debugger and Valgrind, just to name a few, have not been included. Let alone reverse engineering a closed directory web server or hardware reverse engineering.


Does this strange string of letters indicate that my Outlook account has been hacked?

This does appear strange. It is something that the technical support people should know how to fix. (maybe they don't know, but they should)

It is possible that it was a setting in your account with this string. If that is the case you can change it back, and that is a clue your account was hacked.
It is possible this is due to a bug in their software, in which case this does not raise a direct security concern.

The icon change on the top left corner is not a serious issue, but obviously a completely green icon is preferable.

Have you tried from a different browser, or from a different computer?
Have you tried accessing from your smartphone on a completely separated connection?

These might raise helpful clues. Sometimes a plugin can alter the page contents, but still this seems very strange. It does seem more likely to be a bug at Microsoft.

If you suspect the account was compromised, (i.e. your password got out or something is logging all your actions and passwords) then you should:

Change your password.
If you think a virus has caused the password to get out, then a professional machine wipe is the safest option. However, sometimes a password is accidentally leaked by phishing (entering your Microsoft password on a Microsoft-look-alike-fake-site), in which case you would not need a machine wipe.
Using 2-factor authentication is a real boost in your security, but not a silver bullet.


If all ports are closed, do I need firewall?

Connection requests to unbound TCP ports will not be DROPped, they will be REJECTed. (And although this requires a little more effort on your PC's behalf, this is also what most firewall configurations do, so it doesn't really matter.) Otherwise, your assumption is good - if no services are listening on any of your incoming ports, you don't need a firewall.

But how do you make sure this is the case?

Do you know of each and every program on your machine that is able to listen on a port? Maybe you have a program that happens to listen on a port for some useful function but it's buggy and it can be exploited. Maybe you have a virus that listens on a port to receive commands. Maybe you forgot to turn off file sharing and all of your family pictures are now on the laptop of the man across you at McDonald's, or worse, deleted.

Firewalls are much more convenient and secure. On a modern operating system, you can't make sure you know each and every process that may put your machine or your data at risk if you allow them on the net. You can easily block these using a firewall. If you configure your firewall well, you can make sure that only the processes you want are allowed to listen, because you need to give permission manually to every one of them.


You can achieve your goals with two methods:

offload logic into servers controlled by you. Lots of games do this already.
obfuscate your code. You can use XFuscator, for example.

However, with 2, its impossible to be 100% secure. Preventing people from actually running your code by themselfes and not a server is actually quite impossible.


Found an application (Whatsapp) initiating UPnP requests, is it something that I should worry about?

WhatsApp uses uPnP for NAT traversal and external IP Address discovery. It only happens when you initialise WhatsApp call.

Some of the NAT traversal techniques are:

NAT-PMP (obsolete but still used by some of the BitTorrent clients)
PCP (successor of NAT-PMP)
STUN/TURN
uPnP (also used by BitTorrent client)

Through uPnP WhatsApp establishes peer-to-peer communication to initiate VoIP. uPnP is also a dynamic port forwarding technique so it is active as long as the P2P communication is running. If you disable uPnP in your router, then WhatsApp switches to STUN.

It used to be only STUN/TURN in older versions and they recently added uPnP support. I think it is because they want to reduce the call set up time. STUN has its own complications like it doesn't work with Symmetric NAT and first client has to discover if it is sitting behind a Symmetric NAT, then only it switches to TURN using ICE which further increases call set up time.

Whereas in uPnP, client only has to talk to the router to initialise the session and keep it active. This greatly reduces the round trips and call set up time.


Use the SQL Injection cheat sheet. Most databases have a way to query the version e.g. SELECT @@version. If you have already found an injectable point that returns data try a couple of those until you get data back.

example methodology:

SELECT @@version # fails. Then you know it is not MS SQL or MySQL.
SELECT version() # fails. You know it is not PostGres
SELECT banner FROM v$version WHERE banner LIKE ‘Oracle%’; # Succeeds! You know it is oracle.

If those fail use other kinds of queries. You can try timed base injections e.g. SLEEP 10, or even executing functions such as TO_NUMBER('10'). Using version specific syntax will let you pretty quickly find out the backend database.

You can also start with some educated guesses. Java web apps often use oracle. .Net often uses MS SQL. PHP often uses MySQL. Django often uses Postgres. Just try specific queries until you get the query to properly execute.

SQLMap can also help fingerprint the backend database. I suggest a combination of using sqlmap + manual testing.


Security implications of download attribute

This is actually described in the HTML living spec:

  If the algorithm reaches this step, then a download was begun from a different origin than the resource being downloaded, and the origin did not mark the file as suitable for downloading, and the download was not initiated by the user. This could be because a download attribute was used to trigger the download, or because the resource in question is not of a type that the user agent supports.

  This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server.

The scenario, described here is:

You are on my onlineexcel.attacker.com website that allows to make Excel files
You click a link in there, stating like "download your excel sheet". This is actually a link that downloads your facebook profile, say <a href="https://facebook/myprofile/" download="your-sheet-from-onlineexcel.xlsx">
Later on, you wish to restore your excel sheet/load it online, so you click the upload button of my è onlineexcel.attacker.com, say` and you select the file that you thought was from onlineexcel.attacker.com (because it was a link in there)
You actually have uploaded your FB profile to my website

So the hazard here is that user do not know whether link is downloaded from the same origin or not.

That's why spec advises:

  Thus, it is in the user's interests that the user be somehow notified that the resource in question comes from quite a different source, and to prevent confusion, any suggested file name from the potentially hostile interface origin should be ignored.

But I suppose that since this is a bit difficult to properly tell to Mom-like users, then browsers preferred to block such downloads.


Difference between root login and passwordless sudo

Honestly, this is probably largely an attempt to protect the user against themselves.  One of the biggest benefits of "don't run as root" is that mistakes don't (usually) destroy the whole system.  (On desktops, this is of limited value -- I'd rather destroy my Apache configuration than all the data in my home directory!)  If you are using ec2-user, you at least need to realize you're escalating privileges by using sudo.  In that way, it is similar to UAC on Windows for an Administrative account.


To prevent XSS you need to:

Validate all user input that you'll process (for example - if id GET parameter should be a number, ensure it is with e.g. PHP's is_number() function or using Filter extension). This should not only include GET / POST parameters, but also cookie names, cookie values, HTTP headers, uploaded file names etc. Attackers can manipulate requests in many ways. If you need to accept & display HTML content from the user (e.g. in CMS application) use well-tested HTMLPurifier library to filter out Javascript & other XSS payload and leave only clean, sanitized HTML.
When displaying the value use contextual output encoding (sometimes called 'escaping'). There are different rules on how to encode user-supplied value whether it occurs in:

HTML context e.g.
{$_GET['id']}

HTML attribute context e.g.

Javascript context e.g.
CSS context e.g.

It's best to refer to recommended rules described in OWASP XSS Prevention Cheat Sheet. Read it thoroughly and adher to it - XSS is #2 risk to web applications today so you really need to protect from it. See also OWASP tutorial video on XSS.


The "hassle" is a trade off depending on what you are trying to protect. But it is benefficial to use GPG/PGP if you want to protect your emails. Make sure to train your employees.

On a side note:

If they really would want to get access to your files I don't think the NSA would be discouraged because you are using PGP, if the file is encrypted they will get the key...somehow.

image via xkcd.com


Best practice for connecting publicly available server to internal LDAP/Active Directory?

It does not appear to me that this produces a specifically dangerous attack surface - Provided your AD accounts are sufficiently secure that their passwords can't be brute forced, and that your LDAP server is properly secured and patched. While it's true that a compromise of the web server would open your LDAP server to attacks, there isn't necessarily much you can do to mitigate this.

I considered that if your web server gets compromised, it might be useful to have a proxy between your web server and the LDAP server, but that gives you one more server to update and patch, otherwise that will just be compromised and used to attack the LDAP server instead. That is, of course, not a certain thing, and requires another series of attacks to get into the same position as the situation without the web server, but it can provide some extra defense in depth.


What attacks does the disclosure of VPN user credentials allow?

A lot of the answers depend on the VPN technology used, but assuming it's a TLS-based vpn, knowing a user's credentials would allow someone to assume that user's identity, but not decrypt past or future traffic. If the VPN provider gives access to VPN logs (which is extremely rare), having someone's VPN credentials would allow the attacker to see usage history.

Generally, though, it only allows someone to use the stolen VPN account without paying for it and doesn't compromise the security of VPN sessions.

Edited to add: obviously, if it's the kind of VPN account that grants access to restricted resources (such as private company networks), then it's different.


How exactly do mobile apps achieve authorization code flow with PKCE?

Your mobile app is the "client application", and the API that makes the client app function is the "resource server" (the "resource owner" is normally the person using the app).

The use of PKCE here protects against an attacker intercepting the authorization code, which can be relatively easy on mobile apps if custom URI schemes are used. Like you say, mobile apps are public clients and so without PKCE an attacker would be able to exchange the authorization code for an access token and make calls against your backend, however when using PKCE the atacker also needs to know the "code verifier" which is randomly generated and stored only in memory by the client app each time it makes a request.

See also:

What is PKCE actually protecting?
Protecting Mobile Apps with PKCE


Quick Question About DNS Spoofing popular/non-popular sites

Do modern browsers have some kind of list of domain/IP relationships to check against

Yes. Modern browsers have a builtin list of important sites using HSTS which protect even a fresh browser installation against hijacking of these sites with sslstrip or similar. See the chromium source code for the list of sites protected this way by Chromium and derivatives (Chrome, Opera...) and at https://hstspreload.appspot.com/ you even propose your own site to get added.


ABAC is a generic term and access control model much like RBAC is. Both are defined and formalized by NIST. In their latest publication, NIST consider ABAC as the next evolution in access control.

CBAC on the other is not a model. It's vendor-specific, in this case Cisco. You can see CBAC as a specialization of ABAC.

I've written most of the ABAC Wikipedia page so I'll naturally recommend you check it out. There are implementations of ABAC out there (e.g. Axiomatics which is where I work) which you can use to define fine-grained access control on APIs, databases, and more.

Lastly, there is a standard that implements ABAC: XACML or extensible access control markup language


Do simple Linux servers really need a non-root user for security reasons?

There are a few reasons:

traceabilty: Commands run with sudo are logged. Commands run with bash are sometimes logged, but with less detail and using a mechanism that is easy to block.
privilege separation: almost every command is not the same as every command. There's still plenty which doesn't require root
file editing: the web files are owned by a non-root user and run by a non-root user... so why would you edit them with root?
attack mitigation: Consider the following totally-not-even-hypothetical scenario: Your workstation gets some malware on it which filches your FTP/SCP/SFTP/SSH login out of the stored authentication database from the appropriate client and transmits it to the attacker. The attacker logs on to your device to do some mischief. Now, can they cover their tracks, or will what they do be visible to you? I talk to someone new more than once every week to whom this has recently happened.
automated attack mitigation: A hacked server in Brazil is scanning your network and pulls up a listening SSH server. What username does the attacker use for his automated attack? Maybe webuser, or test, or www or admin -- but more than any other: root.

There are certainly many more reasons, but these are the first ones to come to my head.


Why do device vendors build-in backdoors when it can destroy the companys reputation?

There are several ways how a backdoor can get into a product.

The company is forced to do so by the law of the country where they have their company headquarter. When you live in Sweden or Norway, then most of the electronic devices you use will likely be imported from China (I just looked for some device connected to my computer which did not have a "Made in China" sticker - I couldn't find one) while most of the software you use will be imported from the United States (with help from programmers from India). When the companies are forced by their local government to backdoor their devices for export, they will certainly not remove the backdoors or tell retailers about them when the products leave the country. Keeping them backdoored is the whole purpose of this, and the local laws usually forbid the companies from disclosing the backdoors. This prohibition also serves as a PR rescue system for the involved companies. When caught they can say that they had no choice and can put all the blame on their government.
The company management is unaware of the backdoor. It was either introduced accidentally (an honest security bug) or intentionally by an employee who was bribed, extorted, otherwise manipulated by a 3rd party or thought that it might serve their own personal interest to have a backdoor in their product only they know about. In practice, accidental backdoors are much more likely (Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity").
The company management is aware of the backdoor, and considers it a legitimate feature. A possible situation is a remote administration interface which is supposed to make it easier to handle customer support requests. Such a feature seems really useful from a laymans perspective. Imagine your router doesn't work, you call the support number, just read them the serial number and they fix it remotely without you having to do any of that difficult computery stuff. Sounds great, doesn't it? Unfortunately managers lack the technical expertise to understand how difficult it is to implement something like this in a way which makes it secure but still convenient for the support staff and end-user. In some companies, management will be primarily concerned with minimizing the minutes per handled customer support request and meeting the deadline, so security considerations will often have low priority.


How do pendrives like IronKey protect against password guessing?

No, the pendrive (IronKey) in this story cannot be disassemble and here's why...
The original IronKey was FIPS-140-1 compliant and the current ones are FIPS-140-2 or FIPS-140-3 compliant.  These keys are tamper-resistant, because of the design of their metal cases.  The encryption key is also stored in a tamper-resistant cryptochip module, which has a self-destruct function in case of physical attacks.
Here are some basic details from vendor documentation:
Device Password Protection: The device password is hashed using salted SHA-256 before being transmitted to the IronKey Secure Flash Drive over a secure and unique USB channel. It is stored in an extremely inaccessible location in the protected hardware. The hashed password is validated in hardware (there is no “getPassword” function that can retrieve the hashed password), and only after the password is validated is the AES encryption key unlocked. The password try-counter is also implemented in hardware to prevent memory rewind attacks. Typing your password incorrectly too many times initiates a patent-pending “flash-trash” self-destruct sequence, which is run in hardware rather than using software, ensuring the ultimate protection for your data.
Here are some more details on the IronKey self-destruct function
Self-Destruct Data Protection:

Secure volume does not mount until password is verified in hardware
Password try-counter implemented in tamper-resistant hardware
Once password try-count is exceeded, all data is erased by hardware

Physically Secure

Solid, rugged case
Encryption keys stored in the tamper-resistant IronKey Cryptochip
All chips are protected by epoxy-based potting compound
Exceeds military waterproof standards (MIL-STD-810F)

Additional Security Features: USB command channel encryption to protect device communications


Does mixing different types of encryption make the connection more secure?

Yes and no.

SSL offers end-to-end encryption between the application using SSL and the server to which you are connecting. It's a layer 6 protocol and may only provide security for that particular application.

In case of IPSec, it works at layer 3. It's mostly used to provide end-to-end encryption between different sites. For instance, if you have several applications communicating across a link, but those applications do not use any security protocols, you do not want to use the internet as any intermediary router can see the traffic as it's in the clear. IPSec solves this issue by providing a site-to-site encrypted tunnel. So the applications are still sending information in plain text, but before it leaves the site towards the other site, it is encrypted.

Now both are strong security protocols and, if implemented correctly, considered secure. Now if you are communicating across SSL and add IPSec then it's not considered more secure. SSL provides end-to-end security. Adding a layer of IPSec does not matter.

When using IPSec and adding SSL this may be different. IPSec only provides security up to a certain router after which the traffic will become clear again. Using SSL you can ensure that your data is secure until it reaches its final destination. If an attacker has access to a router after the traffic is de-crypted, then he can perform a MiTM, whereas with SSL this still would not be possible.

So adding IPSec to SSL does not provide extra security, but adding SSL to IPSec may offer better security, depending on circumstances.


What techniques do advanced firewalls use to protect againt DoS/DDoS?

My experience of DoS and DDoS attacks is based from being a Cisco engineer for an ISP and later as a Security Manager for a very large Global. Based on this experience, I have found that to effectively deal with large scale and complex attacks requires a good partnership between the organisation under attack and their ISP or DDoS mitigation partner (Yes there are now companies dedicated to this, in essence they are a very large ISP in their own right but use their global network to take on the additional traffic generated during an attack).

Below are some considerations if you face an attack that is outside of your bandwidth tolerance (aka bandwidth consumption) and you need help in responding.

Where no mitigation partner exists:
Establish a strong relationship with your ISP. Identify the right teams and contacts that you will need if there is an attack.

Use your firewall (or other logging device) to obtain evidence of the attack (source IP, protocol, packet length, etc) as this information can be hugely valuable to the ISP in deciding how to respond. It's not fun trying to trap traffic on a Cisco routing device from the command line at three in the morning! So any help is appreciated. :-)

With this your likely approach will be to filter out the traffic within the ISP cloud. If you have been able to provide enough information and the traffic is such then the ISP may well be able to filter out the malicious traffic and leave valid network traffic free to access your network. However if you are causing latency issues for the ISP then they are likely to black-hole your entire route at their BGP gateway and you will disappear from the net. Additional routing filters cause load on gateways, so don't expect your ISP to add multiple filters as this may well impact on their other users.

Using a mitigation partner:

I can only speak from the experience of one provider for this, so you will need to do your homework to decide if you require this and if so who would be best placed to provide.

The service was based upon BGP route advertisement and attack monitoring. Once an attack had been identified the mitigation partner advertises your route to pass through their network, where core routers are used to filter out the malicious traffic prior to passing on to the organisation.

My role in all of this was to test the implementation of a partnered approach to DDoS mitigation. This involved utilising a global team of security engineers to generate enough traffic to make for a valid test. We were testing both the ability to identify an attack and then to respond effectively. Based on this, we were very impressed with their overall approach and the solution worked.


Is it possible to forge email info in header?

When your MX receives the message, it should write a line in the message headers showing the timestamp for this delivery, and the hostname and IP of the SMTP server that delivered this message to your MX.  This line would be difficult for the sender to forge, because it is your MX that writes it.  However, there may be a number of previous lines in the headers, denoting previous deliveries to various other SMTP servers that the message may have passed through en route to your MX.  These lines can easily be forged by the sender.


Possible Security threats and mitigations while accessing `/root` through any browser?

The issues are that anyone on your system will be able to maliciously elevate themselves to root privileges. Doing either of these things is a very bad idea. To address your specific scenarios:

Making root's home directory mode 0777 means that all users will be able to read, write, enter, and execute any files in that directory. Because many sensitive, privileged processes use that as their home, making it world-writable could allow any unprivileged process to tamper with root's home. For example, malicious code in /root/.profile would be executed with high privileges any time the root user logs in. There are many ways to exploit you in this scenario.
Running your browser as root is also extremely dangerous. It means an exploited browser will run as root, rather than as your normal user. This is not a hypothetical threat. Someone actually did run their browser as root and got infected with ransomware! Additionally, a regular browser is not designed to run with a privileged context and so does not take the necessary security precautions to prevent an unprivileged local user from exploiting it. For example, if you run your browser in your regular user's environment, but as root, then a modified configuration file or browser extension (in your regular user's home) could exploit it to elevate to root.

You could make /root mode 0755, which would make it writable only by root, but would allow everyone else to enter and read it (including your browser). Normally, it does not contain any sensitive information, but it is still not a great idea to let everyone look inside it.


Compute the AES-encryption key given the plaintext and its ciphertext?

I am adding an answer as a community wiki because I believe that the accepted answer is dangerously misleading. Here's my reasoning:

The question is asking about being able to derive the AES keys. In that regard the accepted answer is correct: that is called a Known-plaintext Attack, and AES is resistant to that kind of attack. So an attacker will not be able to leverage this to derive the key and make off with the whole database.

But there is another, potentially dangerous attack at play here: a Ciphertext Indistinguishablity Attack. From Wikipedia:

  Ciphertext indistinguishability is a property of many encryption schemes. Intuitively, if a cryptosystem possesses the property of indistinguishability, then an adversary will be unable to distinguish pairs of ciphertexts based on the message they encrypt.

The OP showed us that this column holds one of two possible values, and since the encryption is deterministic (ie does not use a random IV), and attacker can see which rows have the same value as each other. All the attacker has to do is figure out the plaintext for that column for a single row, and they've cracked the encryption on the entire column. Bad news if you want that data to stay private - which I'm assuming is why you encrypted it in the first place.

Mitigation:
To protect against this, make your encryption non-deterministic (or at least appear non-deterministic to the attacker) so that repeated encryptions of the same plaintext yields different cipher texts. You can for example do this by using AES in Cipher Block Chaining (CBC) mode with a random Initialization Vector (IV). Use a secure random number generator to generate a new IV for each row and store the IV in the table. This way, without the key, the attacker can not tell which rows have matching plaintext.


Is it possible to cause a DOS attack on a domain by spoofing the DC's NTP request?

Yes, in theory, you could significantly disrupt Kerberos (which is time sensitive) by blocking time or sending strange time answers in response to requests. This is why AD has moved to authenticated time, and mostly abandoned SNTP. Mind you, NTP (on which authenticated time and SNTP are based) uses quorum-counting, so you would have to disrupt multiple time sources or spoof answers from a majority of the time sources.


Without checking, I'm going to assume that your CentOS RPMs contain backported fixes which address the CVE's listed in their report.  (That's how RedHat does it and CentOS is RedHat in this regard).  Because of this, your packages are probably immune to issues that their banner would otherwise indicate they're vulnerable to.

What you need to provide Trustwave with is the version you're running (which you've done) but also the evidence that this version contains fixes for the CVE IDs they think you're vulnerable to.  If you go to the RedHat CVE database it will tell you which versions include the patches for a given CVE, just collect those links and submit them to Trustwave.


What is really wireless sniffing, and how can this attack damage someone

So what is the wireless sniffing attack

It is capturing packets (recording some traffic) that traverse your wireless network, without you knowing about it.

  how is it done

You need a network card that supports monitor mode, an OS and version that properly supports delivering traffic captured in monitor mode, and drivers that properly support it.  Linux is your best bet here.

In this mode, your wireless card will receive packets without having to be associated to an AP.  It will capture all traffic it hears on a given Wifi channel.  Other STAs or APs won't know this is happening.

This is different than promiscuous mode - a wireless NIC has to be associated before promiscuous mode will work.  Monitor mode has no such requirement.

  what is the damage that it can do

Collect valid MAC addresses to bypass SSID hiding.
Passively and undetectably collect data needed to break WEP/WPA (not WPA2) encryption.
Receive all data transmitted/received on open networks/networks without encryption, with the ability to read any plaintext information.


Why don't people hash and salt usernames before storing them

You see that thing up there where it displays your username? They can't do that if the username is stored hashed now can they?

One word, usability.


Indeed, Math.random() is not cryptographically secure.

Definition of Math.random()
The definition of Math.random() in the ES6 specification left a lot of freedom about the implementation of the function in JavaScript engines:

Returns a Number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with approximately uniform distribution over that range, using an implementation-dependent algorithm or strategy. This function takes no arguments.
Each Math.random function created for distinct code Realms must produce a distinct sequence of values from successive calls.

So let's have a look at how the most popular JavaScript engines implemented it.

SpiderMonkey, used by Firefox and many programs, implemented an algorithm named Xorshift128+ (link to Mozilla's repository).
V8, used by Chrome and Node.js, also implemented the Xorshift128+ algorithm (called in the RandomNumberGenerator function)
Webkit, used by Safari, also implemented the Xorshift128+ algorithm.
Chakra, the JavaScript engine powering Microsoft Edge, also implemented the Xorshift128+ algorithm.

Xorshift128+ is one of the XorShift random number generators, which are among the fastest non-cryptographically-secure random number generators.
I don't know if there's any attack on any of the implementations listed above, though. But those implementations are very recent, and other implementations (and vulnerabilities) existed in the past, and may still exist if your browser / server haven't been updated.
Update: douggard's answer explains how someone can recover the state XorShift128+ and predict Math.random() values.

V8's MWC1616 algorithm
On November 2015, Mike Malone explained in a blog post that V8's implementation of the MWC1616 algorithm was somehow broken: you can see some linear patterns on this test or on this one if you're using a V8-based browser. The V8 team handled it and released a fix in Chromium 49 (on January 15th, 2016) and Chrome 49 (on March 8th, 2016).
This paper pulished in 2009 explained how to determine the state of the PRNG of V8's based on the previous outputs of Math.random() (the MWC1616 version).
Here's a Python script which implements it (even if the outputs are not consecutive).
This has been exploited in a real world attack on CSGOJackbot, a betting site built with Node.js. The attacker was fair enough to just make fun of this vulnerability.

Lack of compartmentalization
Before ES6, the Math.random() definition didn't specify that distinct pages had to produce distinct sequences of values.
This allowed an attacker to generate some random numbers, determine the state of the PNRG, redirect the user to a vulnerable application (which would use Math.random() for sensitive things) and predict which number Math.random() was going to return. This blog post presents some code about how to do it (Internet Explorer 8 and below).
The ES6 specification (which had been approved as a standard on June 17, 2015) makes sure that browsers handle this case correctly.

Badly-chosen seed
Guessing the seed chosen for initializing the sequence can also allow an attacker to predict the numbers in the sequence. It's also a real world scenario, since it has been used on Facebook in 2012.

This paper published in 2008 explains different methods to leak some information thanks to the browsers' lack of randomness.

Solutions
First of all, always make sure that your browsers / servers are updated regularly.
Then, you should use cryptographic functions if needed:

If you're working in a browser environment, then you can use crypto.getRandomValues, part of the Web Crypto API (check the support table).
If you're working with Node.js, then you can use crypto.randomBytes.

Both rely on OS-level entropy, and will let you get cryptographically random values.