Why is Address Space Layout Randomization not effective against the Open SSL Heartbleed Vulnerability?

ASLR randomizes the addresses of critical parts of the processes memory, i.e. stack, heap and where libraries are loaded in order to make it unpredictable where a specific piece of code or data structure is located. But this kind of knowledge is not needed in the first place to exploit Heartbleed.

The Heartbleed vulnerability relies on an out of bounds read within an already allocated buffer on the heap. It does not need the base address of the heap for this, all what it needs is that sensitive data are still located at the heap and that they are located behind some newly allocated buffer. An image taken from Inference of Memory Bounds: Preventing the Next Heartbleed visualizes the problem nicely:

Relating to this image: in case of Heartbleed the buffer allocated for the TLS heartbeat was the blue one. But since the claimed size given in the heartbeat request was larger than the actual size of the heartbeat request and the heartbeat response trusted this wrong size OpenSSL ended up not only to include the payload of the original heartbeat request (blue) but also the data behind it on the heap (red) and thus leaked the sensitive information. No knowledge of any actual address was required for this.


Shared folders in Windows to/from unsecured PC on the same network

First, this assumption is highly optimistic:

  It's password-protected and I'm not concerned about it being physically accessed by bad actors.

You should. As soon as an evil guy has physical access to a machine, many things can happen:

at the simplest level, just boot from a CD or an USB key (UBCD or UBCD4WIN are great for that). That is normally enough to by-pass any password protection (and IMHO much simpler than attacking the desktop from the laptop)
at more complex levels are malware hardware devices such as a physical keyloggers (password is know next time you enter it), or USB devices simulating a keyboard

But your actual question is about what could happend to your desktop if malware are installed on the unprotected laptop.

This part highly depends on how your system is configured. The default installations assume that the local network is secured, and it is common for guest accesses to be allowed. That is not enough to execute something but that means that it is possible to read files from the computer - you know whether private information can be present, I do not.

Another possible way is more like social engineering. It consists of letting innocent looking files (images, videos, music) containing an infected payload targetted at common media readers in places where they could not notice them as suspect. As your main destop can read from the laptop, it would be possible that you inadvertantly load the malware on the desktop.

And as soon as it is on you local netword, it can spy all network traffic, perform Man In the Middle attacks through ARP cache poisoning (pretend to be your router for example), and various other network attacks. Not speaking for possible exploits in the OS itself on any service running on it.

TL/DR: The real problem here is the exposition of the desktop. Common security practices recommend that the higher is the exposition, the higher should be the security: only required services and applications, strong passwords and often changed. And if physical access is possible, no USB ports, no bootable device and a consistent control of all physical devices before use. And of course a physical lock to prevent box opening.

That being said, the security level must accomodate to the actual risk, and only you can know whether the cost (money and time) for securing that is worth it.


How to stop people from spamming the account creation url on my website

Most of the techniques which will help you are anti-automation tools. The following may be a helpful resource in this regard:

http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation

This is the reason many websites deploy tools like re-Captcha and that may even be one of the easiest quick-fixes to your problem but it's not foolproof. There are even anti-anti-automation tools just to get around defenses like re-Captcha.

Another tool you will definitely want to look at is Fail2Ban but you will need to enable the specific configuration to protect your website. This is easy to do but by default, it only protects SSH. In many cases, Fail2Ban by itself will take care of your problem.

If you have a more persistent attacker you may need to look into what is unique about their attack technique and either stop it by writing a custom IDS rule for something like Snort or by using a tool like mod_security. Sometimes rate limiting tricks in IPTables works too if you are either on Linux or can place a Linux box in front of your website. There are a lot of ways to solve these but you may need to dig deeper into how their attacks work. Another low-tech way to handle this is by changing your "submit form" url semi-frequently via a cron job, this isn't the easiest solution but it can be very effective. There are many other techniques as well including things like using GEO-IP locations to block the source of the attacks but the key is looking for anti-automation tools which work with the stack you are currently using. Finally, search if the tools or frameworks you currently use have anti-automation tools built-in, some times these ship with things like web-frameworks but need to be enabled/configured by the user of these tools.

One problem you need to be aware of is the attackers likely already know your current public IP address so simply adding a cloud-based WAF solution, like CloudFlare, may not be a practical or useful option to quickly stop active attacks especially if you have other sites linking to your current website via IP (this shouldn't be the case but it happens). Likewise, you will have to make firewall changes to enforce that ONLY connections from CloudFlare can access your application otherwise it will have no effect at all on attacks directly to your current public IP address. This is still a useful security control for future attacks but may create other short-term problems if not implemented correctly and these won't protect from all types of attacks either. It should be noted that there are a number of WAF-bypass techniques which will allow attackers to continue to submit form requests even with one of these in place.

More information about these problems can also be found here:

OWASP Automated Threats to Web Applications

Finally, in case the attacker changes to brute force in response to your implementation of anti-automation tools you may want to go ahead and read the following too:

OWASP Blocking Brute Force Attacks

Hopefully, this helps.


"Security Best Practice" depends on many factors since your control environment (e.g. Health Care, Payment Systems, etc.) will have different regulations and standards that must be followed. (e.g. HIPAA, PCI-DSS, etc.)

  Besides following VMware's security best practices

I'm assuming that you mean the hardening guides available here: https://www.vmware.com/security/hardening-guides

If that is the case, those are mainly technical controls - very good controls to implement if you can -  and do not cover many of the controls outlined in something like ISO 27001/2 or COBIT. Again, how far and deep you need to go with security and compliance depends on your control environment.

  are there any other recommended security technologies that are aimed
  at security and compliance in virtual environments?

VMware offers some free compliance checkers for things like the Hardening Guide (mentioned above), DISA, and HIPAA - I recommend these to get started. There is a PCI checker tool but it is a bit outdated:

https://my.vmware.com/web/vmware/evalcenter?p=compliance-chk

In order to narrow down what is best for your control environment, I would suggest looking for white papers in your industry. I did a quick search for "vmware security partners" and saw that Symantec has an offering to help with security and compliance - Control Compliance Suite - http://www.symantec.com/control-compliance-suite

For specific security improvements there are products like McAfee MOVE that moves the antivirus scanning load to the hypervisor instead of the virtual machine.

http://www.mcafee.com/us/products/move-anti-virus.aspx

Also note that what you can do with VMware and 3rd party offerings depends on the type of licensing you have as well - if you are not using Enterprise for example there might be some "gotchas" along the way. For example if you need a distributed switch, which is required for something like NSX, then you must have an enterprise license. The Symantec Control Compliance Suite that I mentioned above also requires a VMware Enterprise license.

I don't think you will find an all encompassing solution but a good strategy would be to understand your threats and control environment, perform a gap assessment, analyze the amount of effort required to remediate (i.e. mitigate, accept, transfer the risks) the gaps, and then see if there is a 3rd party solution that can help save you time and money in remediating the risks that must be mitigated.


How misappropriation-resistant are common deployed signature formats?

Mildly formal definition: a signature scheme is misappropriation resistant if...

The properties you describe as signature misappropriation have acquired a few different names in the academic literature:

Conservative Exclusive Ownership is name of what you describe as misappropriation resistance without message alteration. Schemes lacking this property are said to be vulnerable to key substitution attacks or duplicate signature key selection attacks.
Destructive Exclusive Ownership is name of what you describe as misappropriation resistance with message alteration. Schemes lacking this property are said to be vulnerable  to message key substitution attacks.
Weak Variants are also defined where the attacker does not know the correct private key as in your weak notion.

We wrote a paper which contains formal definitions of these properties and their consequences: See sections 3.1.1 and 3.1.2 of Seems Legit: Automated Analysis of Subtle Attacks on Protocols that Use Signatures. It has a discussion of their history and references to the papers which first described these properties.

  If the public key, or a second premimage resistant hash thereof, is part of the signature, or [...], then the scheme is misappropriation-resistant.

This seems intuitively true and the very first paper to discover this kind of attack made the same observation. However, this isn't true in general as the attacker can use the message alteration property so that the included public key is changed to be the theirs. However, you are correct that EdDSA's specific design does prevent this.

  Which deployed signature formats are resistant (or not) to such signature misappropriation?

Vulnerable to "strong signature misappropriation" (lacking CEO/DEO):

RSA with PKCSv1.5
RSA with PSS
DSA
ECDSA with the elliptic curve parameters treated as part of the public key.

Vulnerable to "weak signature misappropriation" (lacking  wCEO/wDEO):

ECDSA with fixed elliptic curve parameters

Source: Seems Legit Paper, Table 1.


What's the point of encrypting /boot or / partition?

It prevents accidental leaks of private data that is copied around.

For example, if /tmp is on the / partition, files from your encrypted /home partition could be copied to the unencrypted /tmp, thereby making them accessible to an attacker.

By encrypting the entire system, you avoid this channel.


Is it possible to redirect someone to a fake site without changing the hosts file?

There are lots of ways besides editing the hosts file:

Your web browser got hijacked by some malware to request a different domain than you entered.
Your router got hacked. Remotely exploitable vulnerabilities in consumer-grade routers are not unheard of. Or you are using a public network which isn't trustworthy.
Your DNS server might be compromised. You can verify this by using a different DNS server like 8.8.8.8 (Google DNS server)
When you are using a proxy server, VPN or some anonymizer like TOR, that service might redirect you. When you are using such a service, try accessing the website directly. Check the network settings of your browser if there is any proxy server.

And these are just some which come to mind at first though.


From when does the operating systems sign the updates?

For apt package manager

  In recent releases, Debian has been using strong crypto to
  validate downloaded packages. This is commonly called
  "secure apt" (or "apt-secure") and was implemented in Apt
  version 0.6 in 2003, which Debian migrated to in 2005.

Although work for the underlying dpkg-verify had started since 2000.

From rpm change log, rpm seems to support PGP, presumably for code signing, since at least version 2.0, which was released around 1996.

Windows is a bit difficult to research. There are evidence that Windows 98 had support for signed hotfixes:

  Installing Windows 98 and Windows 98 Second Edition Hotfixes

  ... To install a Windows 98 and Windows 98 Second Edition
  hotfix on a single computer, run the self-extracting installer.
  This installer performs the following actions:

  Unpacks the files that are needed for installation into a
  temporary folder. Typically, these files include:

  ...
  A digital signature file (.cat) used to digitally sign
  the hotfix binary files (in most situations).
  ...

However, I'm not quite sure what Microsoft means by "in most situation", perhaps it doesn't always require hotfix packages to be signed?


Is it necessary to have security documentations, policies, DRP & BCP's at place in order to execute secure network architectural review?

I have worked in the IT Audit / IT Security profession for a while now, and I will answer from my professional experience.

  Is it necessary to have these documents, policies, DRP, BCP's etc
  built from the scratch to tighten up security to carry the task at
  hand?

The policies you specified in your list are a basic necessity to a well functioning IT security program. Ask yourself the following questions:

How do you ensure a consistent , reliable method of administering Information technology if you don't have tangible documentation in place?
How do you expect employees to cooperate in IT Security mission if they don't know the purpose, polices, and their role in the program?
It is almost a given that at some time, a failure will occur with IT assets of a company. Without a functioning, and well-tested, BCP / DRP, how do you mitigate the continuity threat to the business?

  If we are to provide serious risk assurances, should we provide them another service to create these docs, policies or shall it be covered along with SNA?

Absolutely Not. This is a conflict of interest and would be considered unethical. If you were to offer this service, your professional judgement is Impaired and any subsequent assurances you provide for this client is inherently untrustworthy. Please see this document from ISACA for additional guidance of professional independence of the assurance function:

http://www.isaca.org/Knowledge-Center/Standards/Documents/1003-Professional-Independence.pdf


TLS library problem when connecting to Dovecot

I had a very similar problem with Postfix and Dovecot on Ubuntu. I had purchased the basic SSL certificate from Comodo and because I selected "other" as the server type I ended up with a zip file with four certificate files in it, as per the above posts.

I wasn't getting security exceptions in the client. In my case I couldn't even get past the account setup and server detection in Thunderbird, despite selecting the correct ports in Thunderbird. In the server's system log I was getting SSL connection abort errors about unknown CA, much like mentioned above.

I fixed this successfully by using a text editor to concatenate all four certificates into one file, starting with my own cert at the top and then subsequently the two intermediate certs and finally the CA cert at the bottom. I then pointed the config of both Postfix and Dovecot to this combined file and Thunderbird was able to connect and I could send/receive email.


JSON web token vulnerability with HMAC and RSA

Finally I bypassed it with custom JWT algorithm, where HMAC accepts public key as its secret key. Which cannot be done in python's pyjwt module or any other language since it is fixed.

Check out POC code here


Would a custom random string do what I want?

Contrary to giving a hardware key to some family member the random string you propose is just data and could be easily copied without notice. And while you might feel that the transport of the hardware key in the pocket is sufficient protection the situation is different with data only as the key.

Still, if you protect your data key well it might be secure enough in your environment, although the exact security requirements of this environment are unknown. Protecting the key means at least using HTTPS so that nobody in between client and server can sniff the key.

But even with HTTPS it is enough that a single of the systems having the key gets compromised. In this case the key can simply be copied and misused because all systems use the same key. Assuming that the misuse of this shared key is noticed at all the only option is to revoke this single shared key which means a new shared key need to be distributed to all systems. In this case it would already an improvement if you use a different key for each system since then the impact of misuse is limited and you only need to revoke and update the key for a single client. This scheme of having a different key for each client could be simplified by using client certificates with your own certificate authority and just trusting any certificate issued by this authority.

Client certificates also have the advantage that they could be hardware backed using a smart card or similar. This way an attacker needs to have physical access to the system to steal the key. Compromising the system from remote is not sufficient, but misusing the existing key from remote might be possible if there is no local interaction required for using the key (i.e. always in smart card with no PIN). And even if the attacker manages to get physical access to the hardware key he will probably not be able to copy it with acceptable costs so the loss of the key will be noticed and access to the key could be revoked.


Client Certificate in SSL HandShake insecure?

The certificate contains only the public key -- that's public data. The important part is not the Certificate message that the client sends, but the CertificateVerify message which the client also sends. That message contains a digital signature which the client computes using his private key, and over the previous handshake messages. The attacker can sniff all he wants, he will not get the private key, which is not sent, and he will not be able to compute another signature, applicable over another SSL exchange.


Is the undesirable conversion of a scientific number a vulnerability?

Why does this happen?

It's because PHP has loose typing. Take a look at this example:

$x = "1e6";
echo strlen($x); // 3
echo $x * 1;     // 1 000 000

On the second line, $x is assumed to be a string, and as such is obviously three characters long. On the third line, $x is interpreted as an integer, or 1 000 000 in this case.

Is it a problem?

This can definitely cause bugs, and every bug is a potential security vulnerability. But on it's own, it does not make your application vulnerable by default. But lets try to imagine a scenario where it would cause a problem.

Let's say a forum has numbered groups that users can freely join, but the first 10 groups (0 to 9) are reserved for administrators. The code for joingroup.php looks like this:

$group = $_POST['group'];
if(strlen($group) > 1 || $isadmin) {
    join_group($group, $uid);
}
else {
    // Fail.
}

You could sneak into an admin group without actually being an admin by posting e.g. 0.3e1, that has string length 5 but evaluates to 3. I know, it is a silly example. The point I want to make is that if you rely on strlen() (or anything else that treats the input as a string) to validate numeric data, you might be vulnerable.

Just posting 3.0 or  3 would bypass this check as well. For more on how PHP implicitly converts strings to numbers, check the manual.

How should I deal with this in PHP?

Validate user input. Check that you actually get an integer when you expect to get an integer:

if(!ctype_digit($group)) {
    // Fail.
}

It is also a good idea to always treat something that should be an integer as an integer and not a string:

$group = (int) $_POST['group']
if($group > 9 || $isadmin) {
    // ...

Is this leaking system information?

Apparently this can reveal the maximum integer value. Perhaps someone could deduce that you are using PHP from this, but there are probably many other ways to do that already. The max value is platform dependent, so it could be used for fingerprinting. But in practice 32 bits are probably used on a 32-bit system, and 64 bits on a 64-bit system. So that is the only information you are leaking.


RSA blind signature vs signing a *random* hash

Yes. Unlinkability is one of the Security goal that needs to be achieved.

For that, First hash of the message is performed and then add some randomness then give it to signer for signing. So that, Even after you send a signature and message, hash of the message would be easily computed by receiving party, he will not be able to collude with signer to know sender's identity.


How to store Personal Access Token securely on shared machine

Use a password manager.

A) I can access it, but no one else can.

This is quite tricky on a shared machine. Using a password manager does ensure nobody will be able to access the stored token as it will be encrypted, but malware may still be able to keylog your password manager's master password when you enter it. But in the case of malware, the token can already be stolen when you copy it to clipboard. So, to minimize possible damage, make sure the scope of the token is limited to only those permissions that you need while giving the demo


Is this a bot fishing for security vulnerabilities on my site?

These requests seem to try to locate Ajax File Manager, in which several vulnerabilities have been discovered.

If you don’t use that, there is no need to worry.


Short answer is that the parameter should be encoded regardless. As paj28 mentions in above comment, it depends what client side page does with the data.

The book, "The Tangled Web" by Michal Zalewski has a chapter about content detection.  He says, "In the history of the web, nothing has proven to be as misguided as content sniffing."

He gives advice at the end of the chapter. Primary tip from this book and from other sources is to use the X-Content-Options: nosniff header to prevent the browser from sniffing the content and coming up with its own answers and ignoring your content-type header.

Your browser's reaction to the actual JavaScript in your example will depend on the browser version.
Note:

text/javascript content type is deprecated. The official MIME type for JavaScript is application/javascript  (as of 2006)  http://www.rfc-editor.org/rfc/rfc4329.txt


Try compressed version

What you posted there as "example key that is working" is a base64 encoded EC pubkey without the PEM wrapper and without the usual line breaks. And more specifically it is a COMPRESSED version of the EC pubkey. But openssl writes  UNcompressed keys by default.

You can convert between the compressed und uncompressed versions like so:

$ cat ExampleOfRejectedKey.headerlesspem
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE85KGK3YiX7tC7mFm+Te1xRYOeDq23h80MPPt1nMZ/ZRpwjRGPEUr6vaoOCB8QC3uHmaPKOAgQ0Kk9Sc4M1QUmA==

Make openssl parse in the key

$ openssl ec -inform DER -pubin -in <(base64 -d ExampleOfRejectedKey.headerlesspem)
read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE85KGK3YiX7tC7mFm+Te1xRYOeDq2
3h80MPPt1nMZ/ZRpwjRGPEUr6vaoOCB8QC3uHmaPKOAgQ0Kk9Sc4M1QUmA==
-----END PUBLIC KEY-----

Again but with "-conv_form compressed"

$ openssl ec -inform DER -pubin -in <(base64 -d ExampleOfRejectedKey.headerlesspem) -conv_form compressed
read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgAC85KGK3YiX7tC7mFm+Te1xRYOeDq2
3h80MPPt1nMZ/ZQ=
-----END PUBLIC KEY-----

As you can see: It's a lot shorter now. And closer in length to the working key. Try this. (Why any API would insist on a compressed representation, and not say so, is beyond me.)

Further reading

See this question: 2011-07-12, Is there a standardized fixed-length encoding for EC public keys?


openssl crl "Error getting CRL issuer certificate" reasons

Given that you did not specify the filename for the certificate my guess is that you just placed it into the directory given by -CApath without taking care of the special file name as needed. From the documentation of x509:

  -subject_hash
       outputs the "hash" of the certificate subject name. This is used in OpenSSL
       to form an index to allow certificates in a directory to be looked up by
       subject name.

Also the documentation of -CApath for openssl crl states:

  -CApath dir
  verify the signature on a CRL by looking up the issuing certificate in dir. This directory must be a standard certificate directory: that is a hash of each subject name (using x509 -hash) should be linked to each certificate.

If you use the hash c7f51c60 returned by openssl x509 -subject_hash as the base for the filename, i.e. put the certificate into dir1/c7f51c60.0 then it works. If you don't want to fiddle with these special filename just put all the certificate into a single file and use -CAfile instead.


It is extremely improbable that any IP address you retrieve from the header links to the spammer. Almost all spams nowadays go through botnets. Also, remember that message headers are as fake-able than message contents; usually, after careful analysis, you can determine which is the first trustworthy mail host through which the spam went, and possibly that mail host may have added the IP address from which the mail came -- which may be only a gullible open relay.

Therefore, while you can usually have reasonably accurate information on which machine is part of the botnet, you will have a hard time finding proofs which could hold in court. Also, 99% of the time, the infected machine is a home PC and the ISP will not give you any name unless forced by a court order -- which may become tricky since most home PC are from other countries. Chances that an ISP will react on your complaint are nil. As a way to warn innocent owners of infected machines, a lawsuit is about as appropriate as trying to squash mosquitoes with a sledgehammer: even with awesome amounts of luck, results will be miserable and completely disproportionate with the invested efforts; and there is a high risk of backfire.

Theoretically, German law makes owner of open WiFi access points responsible for what goes through, to a limited extent. I have not heard of any actual enforcement of that law yet.


Those numbers are a combination of unique identification and data source. Each Snort signature is identified by a SID (Signature ID) and a revision number. The SID is used to uniquely identify that specific signature and the revision is the edit number of that signature. So the original signature is rev:1;, then if it gets updated then incremented to rev:2; and so on.

There is also what's called a GID (Generator ID). Generators are different analysis routines within the snort process. Specifically each preprocessor has its own GID, the tagging system has a GID, and the rules engine has a GID. The rules engine is the processing subsystem that actually processes packets against the signatures found in all the various and sundry rules files.

Now, putting all that context to good use, the string [1:1071:6] tells us this alert was produced by GID 1 and triggered by SID 1071 revision 6. Since it has a GID of 1 we know that this can be found in the rules files. I usually run this command to view a specific rule:

grep 'sid:1071;' /etc/snort/rules/*.rules

Running that today it gives me the result:

/etc/snort/rules/VRT-server-webapp.rules:# alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SERVER-WEBAPP .htpasswd access"; flow:to_server,established; content:".htpasswd"; fast_pattern:only; metadata:ruleset community, service http; classtype:web-application-attack; sid:1071; rev:13;)


Giving merchant account information to web programmer

Could you be more specific as to your situation? How is the web programmer in question related to your company? Is he a permanent staff or a contractor? A proper contract should protect you reasonably well from such threats.

In more technical terms, there is no reason why your programmer needs your actual credentials. Sites like PayPal provides sandbox environments to test out transactions without actually involving actual money. Your programmer should be able to code the transaction system and provide a configuration interface where you can add in the actual details yourself later on.


How likely it is that a hacker spoofed my own IP address when trying to log in to a website?

While it's technically possible to hijack an IP address, it's a pretty high bar and not readily done.

I say hijack as opposed to spoof because user/client generated IP spoofs while easy are not useful for TCP or any two way communication. If I spoof your IP address as the source in my IP packet, the server will respond to that IP which will be you not me and I will not get a connection.

There are two fundamental ways to hijack an IP.

The simplest for an individual is to place themselves directly in-line with your connection as a Man in The Middle (MiTM), but even this can be fairly difficult in most circumstances.

The other method is via a change to Border Gateway Protocol. This is the protocol where various router gateways around the world declare that any IP addresses in a defined range should be sent to them for re-distribution. A BGP change could send your IP (and many others) to somewhere else in the world for subsequent handling by someone else in an IP hijack or a remote MiTM.

Both of these scenarios are pretty unlikely unless you are a high profile target.

The most likely cause is a mistake, or another device/person on your home network.


Top 10 dangerous mistakes in C programming?

The topmost dangerous mistake in C programming is using C. This is an unpopular assertion, but decades of experience back me up.

C is a nice programming language in that it allows you to express operations in an "abstract machine" (that's how the C standard puts it) which will get translated efficiently into machine code (the translation tools runs fast and the result is fast). However, this translation comes at a high price, namely that they are no safeguard for mistakes, and there are a lot of "undefined behaviours" lurking in the shadows. Pointer aliasing rules, for instance, are almost never understood correctly, leading to seemingly good code which will fail (sometimes in ways which create exploitable vulnerabilities) when a newer compiler is used or an optimization switch activated.

Looking for a "list of mistake" is the wrong mindset. You want a blacklist: things to avoid, under the assumption that "everything else" is safe. You should want a whitelist: a list of allowed ways to develop, at the exclusion of everything else. Successful C programmers are programmers who are able to maintain their own discipline to never use any construction that they do not master from end-to-end; and by "mastering" I mean the ability to describe how the C compiler will translate that into assembly opcodes, including all the possible optimizations that C compilers are allowed to make.

A good way to "use C" is to write the one or two routines which really need speed in some optimized C, and the rest of the code in a safer language which will allow for faster, easier and safer development (e.g. Python, C#, Node.js, Perl... the choice is large).


What is the risk of SQL injection using bind variables with a 'like' clause?

I haven't found much discussion other than making sure the bind variable is properly escaped

Given the syntax you have presented here, it appears that ":userName" is a bind variable hence you should not be trying to escape it. If this is the case, then client binding will handle that. Nothing unusual here.

  I believe in this case the execution plan is created before the bind variable is applied

The execution plan will be created for both the queries you have shown us at the same point. That will be before the bind variable is applied for statements prepared serverside and after for statements prepared clientside - different DBMS/different bindings work differently.

  Other than making sure the variable is properly escaped

If you have established that this is a bind variable, stop trying to escape it.


How can you discover a password shared via LastPass?

You can't. End of discussion.

For them to log in, they have to know the password. If this is not acceptable to you, you will have to work out a solution with your provider where two separate accounts can get access to the same data. In my country, this is a rather common feature for banks.

Note that sharing your password will probably be in breach of any contract you have with the banks, which may severely limit their liability.


JWT supports RSA encryption
I'm not familiar with the term "2 way encryption", but I assume you mean symmetric encryption (AES).
The JWE spec does support RSA encryption, it's just not that commonly-used, for reasons I'll describe below.
From RFC 7516 that you linked to -- section 3.3 Example JWE

The Content Encryption Key is encrypted to the recipient using the
RSAES-OAEP [RFC3447] algorithm to produce the JWE Encrypted Key.

And if you click through to RFC 7518 which defines the list of crypto algorithms supported by JWE, you see that there are two RSA-based encryption methods available for JWE:

4.2.  Key Encryption with RSAES-PKCS1-v1_5
4.3.  Key Encryption with RSAES OAEP

Why do you never see JWEs with RSA encryption?
RSA can only encrypt messages up to (roughly) the size of the RSA key. For example RSA 2048 can encrypt up to about 2048 bits (256 bytes, actually a bit less depending on padding scheme). JWTs are often longer than 256 bytes. So when you say "encrypting with RSA" what you usually mean is a hybrid mode where you encrypt the content with AES and then encrypt the AES key with RSA. The reason to add the extra RSA layer around AES is where you want to encrypt for a different person; for example Alice wants to encrypt a message for Bob, but Alice does not know Bob's private key.
In all of the webapps that I've seen where the contents of the JWT are sensitive and need to be encrypted, the server that creates the JWT is also the one that consumes it. Basically, the server is asking the user to hold on to the JWE and hand it back later. In this case you can just use AES without the extra RSA layer because you are encrypting for yourself. As mentioned above, if you have a case where the server generating the JWT is different from the one consuming it, and the contents are sensitive and need to be encrypted, the JWE spec does support RSA-based encryption.


How to design a right VPN connection for an organisation (Interconnected MPLS link or Individual FW)

The fact that you have listed out the pros and cons pretty much speaks for itself. There is no right answer here. It comes down to what you feel works best for you.

Many large organisations I work with use MPLS, specifically for the ease of connectivity to anywhere globally, however MPLS itself doesn't offer much security, so a company-owned VPN is almost always used across the ISP's MPLS network.

Either way, you'll want to think about firewall positioning. Is it sufficient to segregate by country? I'd typically segregate by risk profile, country, service, and possibly other criteria...


How do I know if I can trust a DNS service

Trust is a tricky issue. How does one trust a person in real-life: Either one has already positive experiences with this person or because one trusts others which say that this person is trust-worthy too. Sometimes one also trust a person because of their appearance, like being dressed in a suite and a tie vs. a t-shirt and ripped jeans. But appearance alone can easily be faked.

As for DNS-Watch: they seem to try looking trustworthy by appearance. There are many nice buzzwords like Net Neutrality, Privacy or Uncensored on the page but there is nothing which makes verifying such claims possible. There are no well known and trusted references. Even quite contrary: the impress shows that the service is provided by a company which does among others social media management and movie based advertisement, areas which are not typically associated with privacy.

That said, I have not enough information to actually decide if the service is trust-worthy or not. But currently it looks more suspicious than trustworthy to me. If the provider really offers all these nice things it might be a good idea to make it possible for others to verify these claims. Or being publicly and verifiable endorsed by some well-known privacy focused organization might also help to establish trust.


How to tie encryption key to login if there are multiple users

In general, solutions that do this work something like the following. You should find a trusted system that already does this and use it, rather than trying to build one yourself.

First, generate a symmetric key. This is the Master Key and no user will ever see it directly. Do not store this key (in plain text) anywhere an attacker could potentially reach it.
Use the Master Key to encrypt the data, and ideally also HMAC it for integrity (or use some other way of ensuring integrity, such as using AES in GCM mode).
Run the user's password through a Key Derivation Function (like PBKDF2 or scrypt) using different parameters (such as a different salt) than is used for the password verifier. Do not store these Password-Derived Keys anywhere at all.
Encrypt the Master Key once with each user's Password-Derived Key. Store these encrypted copies of the Master Key with each relevant user's account data.

To access the data:

Authenticate the user. (This typically means retrieving the password verifier parameters for their account, running their password through the key derivation function that uses those parameters to produce a password verifier, and then checking whether that password verifier matches the one stored for that user.)
Get the Password-Derived Key for the user. (Retrieve the second set of KDF parameters, and pass the password into your KDF using those parameters; we already know the password is correct so you can expect that the re-derived key is correct without checking it against anything.)
Using the Password-Derived Key, decrypt the Master Key. Purge the Password-Derived Key from memory as soon as possible after doing this.
Using the decrypted Master Key, verify the data's HMAC (or otherwise ensure its integrity) and then decrypt the data.
Either purge the decrypted Master Key from memory and then access the data (in which case you'll need to repeat steps 2-4 if you want to modify the data and save the changes), or hold onto the decrypted Master Key in as secure of memory as you can arrange.
Purge the decrypted Master Key, and the decrypted data, from memory as soon as possible.

To change a user's password:

If the user has their old password (password rotation), verify the old password and then use it to generate the user's current Password-Derived Key and with that, decrypt the Master Key. Using the new password, generate the user's new Password-Derived Key and re-encrypt the Master Key with it. Replace the old encrypted Master Key with the new one (in the user's account info).
If the user has forgotten their old password, have an administrator verify the user's identity through some other means, and have the user select a new password. Then have the administrator get the decrypted Master Key by entering their own password, deriving their own Password-Derived Key, and using it on their own copy of the encrypted Master Key. Using the user's new password, generate the user's new Password-Derived Key and use it to encrypt the Master Key. Place the encrypted-with-the-new-key Master Key in the user's account information, replacing the one that was encrypted using the key derived from the old (forgotten) password.

To manage users:

For new users, basically just follow the "forgotten password" flow above.
To delete a user, or even just revoke their access to the data, delete the copy of the Master Key encrypted using that user's Password-Derived Key. This makes it impossible for the user to use their own password to get the Master Key by any means.

Despite the detail (which is only present to help you understand the system), PLEASE do not attempt to implement this yourself. There are numerous additional critical details that are either missing or mentioned only in passing. For example, it is vital that the user never directly see the Master Key (otherwise they can store a copy of it, removing your ability to effectively revoke their access without regenerating the entire key structure and re-encrypting the data). Many of these details (such as secure key storage in memory) will be platform-dependent.

Additionally, there are many ways to screw up the crypto itself, even if using library implementations of the cryptographic primitives; if you generate your keys or key derivation parameters incorrectly, and choose the wrong primitives, or implement any of the steps in a way vulnerable to side-channel attacks, your whole scheme could be compromised. Don't try to figure this stuff out on your own; go with something that somebody knowledgeable about crypto implementation has already put together, and that somebody else knowledgeable has reviewed.


TL;DR - upgrade, it works like you expect now.

In versions before 4.13.8, search used a union instead of an intersection of results. Thus your example ("search platform:windows type:exploit") would show you all modules that target Windows (including payloads, auxiliary, and post modules) and all modules that are exploits (regardless of the platform they target).

After that release (early December 2016), search now does what you expect.


How does wireless keyboards' encryption prevent frequency analysis?

Assuming that a block cipher is used as the standard AES or a lightweight block cipher as Prince. The lightweight is highly probable to reduce the power consumption.  Block ciphers need mode of operations.

In ECB mode: E(m1) = E(m2) if and only if m1=m2. So when you press a key k and later when you press it again then the encryptions will be same. When you typing a regular text then by knowing of your language the observer can infer the presses keys as in permutation cipher and see you data. Interestingly, in this mode, even the connected PC doesn't need to the decryption, they can use it as it is.
In CBC mode: a random IV is generated for each encryption then the encryption is performed as c=E(m xor IV). Since the IV is generated randomly for each encryption then the encryptions of each letter will be different every time. In this way, the randomization can prevent the frequency attack.

It is also possible to randomize by padding. That is, if the block-size of the block cipher is 8-byte then you can generate random 7-byte and append it to the binary value of the keystroke, here it is assumed that the keyboard can only send 256 different values, then the encryption. The random padding size can be adjusted according to the device.


If a user is able to install and capture packets with Wireshark, they must already have administrative privileges. If a user has administrative privileges, they can likely already tamper with your application in other, more serious ways.
If you don't want a user to have the ability to tamper with your application, do not give that user administrative privileges.


Your script is fine that you run on NMAP and consider the people in your company who use your servers/connected to the servers or network somehow, may be using software that open certain ports in order to run. For example, Skype uses port 80 and 443 by default. If it can't use those it will change to a different port. Make sure that you have narrowed this down completely. Try add the -sV option to see what is running from where, may give you more incentive.

Check your firewall, see if it is filtering out certain connections, make sure your applications or OS's are accepting TCP connections and check if there is anything with closed ports that are accepting packets but not being listened to by any application.


What's the best way to test for SQL Injection vulnerabilities? Manual or SQLMap?

Using SQLMap will be helpuf, since it scan for most well-known vulnerabilities and will save you some time and efford. But, the greatest threat is a hackers' imagination and ability to exploit something more complex and unusual than SQLMap can find. For me, the best way to check for sql injection vulnerabilities - and even more types of vulnerabilities - is to think out of the box. Become the attacker, not the defender. These tools (like SQLMap) are part of the solution, but not the solution.


Are there reliable Linux ChaCha20-Poly1305 implementations available for stream encryption?

Last I read openssl enc specifically avoids providing a MAC or AEAD cipher because they're worried about providing a footgun to inexperienced users. And rightfully so, if you were to pipe the decryption output somewhere that processes it (rather than a temporary file) you would be processing unauthenticated data, only verifying the authenticity after the damage has been done.

While it's possible to safely stream encryption, it is definitely not safe to stream decryption, so I expect you are unlikely to find such an implementation. If you do, expect it to be insecure.


Does Unbound re-use TLS connections for DoT forwarding?

Currently there is a ticket saying that Unbound does not re-use TLS connections, but it is planned.
https://github.com/NLnetLabs/unbound/issues/47


How get data from password protected rar file?

The current version of RAR uses 128bit AES, which is very secure. A brute force attack will be useless; and while there are some known attacks on AES, none of them are of any practical use. The specific implementation of AES they use is well respected.

That leaves:

Guessing the password
Dictionary attack
Social engineering the password
Rubber Hose cryptography


How To Recover End-To-End Encrypted Data After Losing Private Key?

You have found another example of the balance security vs usability. If you want true E2E encryption, end users are responsible for their keys and for possible backups of their messages. Full stop.
If you stray from that path, you will fall in a grey zone where everything is E2E encrypted but some features allow to recover messages. Said differently: even if traffic were encrypted, the software can still access old messages - which defeats the point of E2E. WhatsApp, for example, chose to implement the ability for a user to ask for a re-send of all their passed (received) messages without the sender being aware of that. If a user genuinely changes their smartphone, they "automagically" recover all of their old messages. Great... But that means that the application contains all what is required for the system to ask to send everything to a rogue address. Gulp...
That being said, you will have to make some executive decisions here. Provided that you and your users are aware that any recovery option does lower the overall security, that will be fine. Do not worry too much -- while most users insist for everything they send or receive to be strongly E2E encrypted, for most users it is far more important to be able to recover their messages than to totally prevent an attacker from accessing them... For better or for worse, most users aren't aware of the full definitions of E2E encryption and strong cryptography, and are usually satisfied with them being claimed


http://www.irongeek.com/i.php?page=security/wargames

WebGoat. WebGoat is a set of deliberately insecure Java server pages

http://www.hackthissite.org/

http://www.smashthestack.org/wargames

from their FAQ:

  The Smash the Stack Wargaming Network hosts several Wargames. A Wargame in our context can be described as an ethical hacking environment that supports the simulation of real world software vulnerability theories or concepts and allows for the legal execution of exploitation techniques. Software can be an Operating System, network protocol, or any userland application.

http://www.astalavista.com/page/wargames.html

http://www.governmentsecurity.org/forum/index.php?showtopic=15442

http://www.overthewire.org/wargames/

the list is long... some are up, some not...

Update 26 Feb 2011, i found a nice post from http://r00tsec.blogspot.com/2011/02/pentest-lab-vulnerable-servers.html . Some links might be broken. I copy from there:

Holynix
Similar to the de-ice Cd’s and pWnOS, holynix is an ubuntu server vmware image that was deliberately built to have security holes for the purposes of penetration testing. More of an obstacle course than a real world example.
http://pynstrom.net/index.php?page=holynix.php

WackoPicko
WackoPicko is a website that contains known vulnerabilities. It was first used for the paper Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners found: http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf
https://github.com/adamdoupe/WackoPicko

De-ICE PenTest LiveCDs
The PenTest LiveCDs are the creation of Thomas Wilhelm, who was transferred to a penetration test team at the company he worked for. Needing to learn as much about penetration testing as quickly as possible, Thomas began looking for both tools and targets. He found a number of tools, but no usable targets to practice against. Eventually, in an attempt to narrow the learning gap, Thomas created PenTest scenarios using LiveCDs.
http://de-ice.net/hackerpedia/index.php/De-ICE.net_PenTest_Disks

Metasploitable
Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.
http://blog.metasploit.com/2010/05/introducing-metasploitable.html

Owaspbwa
Open Web Application Security Project (OWASP) Broken Web Applications Project, a collection of vulnerable web applications.
http://code.google.com/p/owaspbwa/

Web Security Dojo
A free open-source self-contained training environment for Web Application Security penetration testing. Tools + Targets = Dojo
http://www.mavensecurity.com/web_security_dojo/

Lampsecurity
LAMPSecurity training is designed to be a series of vulnerable virtual machine images along with complementary documentation designed to teach linux,apache,php,mysql security.
http://sourceforge.net/projects/lampsecurity/files/

Damn Vulnerable Web App (DVWA)
Damn Vulnerable Web App is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.
www.dvwa.co.uk

Hacking-Lab
This is the Hacking-Lab LiveCD project. It is currently in beta stadium. The live-cd is a standardized client environment for solving our Hacking-Lab wargame challenges from remote.
http://www.hacking-lab.com/hl_livecd/

Moth
Moth is a VMware image with a set of vulnerable Web Applications and scripts, that you may use for:
http://www.bonsai-sec.com/en/research/moth.php

Damn Vulnerable Linux (DVL)
Damn Vulnerable Linux  is everything a good Linux distribution isn’t. Its developers have spent hours stuffing it with broken, ill-configured, outdated, and exploitable software that makes it vulnerable to attacks. DVL isn’t built to run on your desktop – it’s a learning tool for security students.
http://www.damnvulnerablelinux.org

pWnOS
pWnOS is on a "VM Image", that creates a target on which to practice penetration testing; with the “end goal” is to get root. It was designed to practice using exploits, with multiple entry points
http://www.backtrack-linux.org/forums/backtrack-videos/2748-%5Bvideo%5D-attacking-pwnos.html
http://www.krash.in/bond00/pWnOS%20v1.0.zip

Virtual Hacking Lab
A mirror of deliberately insecure applications and old softwares with known vulnerabilities. Used for proof-of-concept /security training/learning purposes. Available in either virtual images or live iso or standalone formats.
http://sourceforge.net/projects/virtualhacking/files/

Badstore
Badstore.net is dedicated to helping you understand how hackers prey on Web application vulnerabilities, and to showing you how to reduce your exposure.
http://www.badstore.net/

Katana
Katana is a portable multi-boot security suite which brings together many of today’s best security distributions and portable applications to run off a single Flash Drive. It includes distributions which focus on Pen-Testing, Auditing, Forensics, System Recovery, Network Analysis, and Malware Removal. Katana also comes with over 100 portable Windows applications; such as Wireshark, Metasploit, NMAP, Cain & Able, and many more.
www.hackfromacave.com/katana.html


Why does Google cripple the 2FA Google Authenticator PAM module?

The initial commit for this code already includes the "80 bits" secret key length. It was not changed afterwards.

Now let's analyze things more critically. HOTP is specified in RFC 4226. Authentication uses a "shared secret", which is the value that we are talking about. What does RFC 4226 says about it ? Essentially, there is a a requirement in section 4:

R6 - The algorithm MUST use a strong shared secret.  The length of
the shared secret MUST be at least 128 bits.  This document
RECOMMENDs a shared secret length of 160 bits.

And then section 7.5 explains at length various methods for generating the shared secret.

Now the google_authenticator code generates an 80-bit shared secret with /dev/urandom and then proceeds to encode this secret with Base32: this encoding maps each group of 5 bits to a printable character. The resulting string thus consists of 16 characters, which are written "as is" in a file, with ASCII encoding, meaning that in the file the shared secret has length... 16 bytes, i.e. 128 bits. It is thus possible that the initial confusion comes from that: what is stored has a length which can be seen, in a way, to comply with requirement R6 of RFC 4226.

Of course, the RFC talks about the "shared secret" by calling it "K" in section 5.1 and then proceeds to using it as key for HMAC (section 5.3, step 1). With the shared secret generated with the command-line tool in google_authenticator, what enters HMAC really is a sequence of 80 bits, not 128 bits, even though these 80 bits happen to be encoded as 128 bits when stored (but they are decoded back to 80 bits upon usage). Thus, this 80-bit secret cannot really, in a legalistic way, comply with requirement R6 of RFC 4226. However, the confusion on "length" (after or before encoding) may explain this feature of google_authenticator.

Note, though, that this is just for the command-line tool which can be used to generate the secret as an initial step. The rest of the code supports longer secret values.

(Another theory is that the author wanted to test his code, and, in particular, test the situation in which there is no QR code. In that case, the user must type the code, and an 80-bit secret is easier to type than a 128-bit or 160-bit secret. Possibly, the author first used a short secret to ease development, and subsequently forgot to set it back to its nominal length afterwards. This sort of mishap happens quite often.)

Is it critical ? With my cryptographer's hat, I must answer: no. An 80-bit secret key is still quite strong against brute force, because even with a lot of GPU, 279 evaluations of HMAC/SHA-1 will still take quite some time (with an 80-bit key, average cost of brute force is that of trying half the possible keys, i.e. 279 evaluations). Indeed, HMAC/SHA-1 is deemed "cryptographically strong", meaning that the best known attack is brute force on the key. Let's put figures on it:

HMAC/SHA-1 uses two SHA-1 invocation. So the attack cost is, on average, the cost involved by calling SHA-1 280 times. This page shows benchmarks at 2.5 billions of SHA-1 calls per second for a good GPU. If you are mounting a cracking farm, you will usually use a "middle range" GPU, not a top-notch model, because you will get more power-per-dollar that way. Let's assume that you use 100$ GPU that can do 231 SHA-1 per second (that's a bit more than 2 billions). With a budget of one billion dollars you can have ten millions of such GPU, and they will run the attack in an average of... 652 days.

Of course, 10 millions of GPU take quite some room and, more importantly, use a substantial amount of power. If we suppose that each GPU can run in 50W (a quite optimistic figure), then each attack run will need a bit less than 8 TW.h (terawatt-hours). I live in Canada, province of Québec, where electricity is known to be very cheap due to huge dams and substantial government subventions, resulting in a price of about 0.05$ per kW.h (see the prices). With this price, each attack run will cost around 400 millions of dollars on electricity alone. This does not include cooling prices, because all this energy will become heat and will have to be dissipated (to some extent, a Canadian winter can help). Also, notice that all the GPU will collectively draw 500 MW, a non-discreet amount (that's about half of a nuclear power plant...).

What this amounts to is the following: in practice, an 80-bit key is strong enough. I would be nervous if an 80-bit key protected the launch code for nuclear missiles; however, if the strategic dissuasion was protected by Google's 2FA, I would also be quite nervous for... other reasons.

So we can say that while this 80-bit secret is non-compliant and academically "a bit short", it still is quite strong and does not mandate immediate and drastic actions. It would be cool if the code was fixed; the World won't stop spinning if it is not.


URL escape before inserting user data into HTML URL parameter values?

This isn't to prevent possible future attacks after clicking on the link. Instead, it prevents attacks on this page, where the link is inserted (at the same time, it preserves the correctness of the link, because - as you noted - the server will properly URL-decode the values).

If you would not encode the data here, an attacker could perform XSS, eg via ">[XSS].

If - after you click the link - the parameter is again inserted into the page, you need to again take preventative matters matching the context it is inserted into.


Is it really required to encrypt files explicitly our self knowing that S3 will keep everything encrypted?

In terms of explicit versus implicit use of cryptography, most of the time it is the latter that is most widely used on the internet (i.e. when sending an email or making an https connection, it all happens in the background through trusted software) but the choice of which to use should depend on the degree of trust in an implicit process, for example.

Regarding the part of the question about the need to encrypt prior
to uploading to a service that will encrypt the data anyway, I
think that also depends on the level of trust and level of security
needed.

For example: some services don't have access to encrypted data as the encryption takes place client-side, where only the resulting cipher-text is held on the server, however, most of the time this requires a trusted setup where you are trusting the service provider's web interface or desktop software to allow the local client-side encryption to take place.

If a user didn't completely trust this process another option would be to encrypt their data themselves explicitly beforehand, and then import/upload as-is with no subsequent encryption by the service (if that option is available), or the service would encrypt the already encrypted ciphertext anyway (obviously with a different key) so that even if that service was compromised and that ciphertext would be decrypted, it would only decrypt to the initial ciphertext, and not the underlying plain-text (unencrypted data). This would be a form of double-encryption.


Can JavaScript defeat source port randomization?

As far as I know, the kernel will allocate a new local port for each outgoing connection (unless the application enforced a specific port value with bind() -- this can be done even for a TCP client) and will not allow two outgoing connections to use the same local port simultaneously. Indeed, if you try to force two client connections to use the same local port number, with explicit bind() calls, the second bind() should fail.

A Linux will allocate local ports in the 32768-61000 range (see this page). This is system-wide.

I doubt Web browsers select specific local ports. I do not see what this would buy them, and, moreover, this will be lost when traversing a router which does some NAT -- a very common thing, both for home users and enterprises.

Guessing the local port in advance does not give an advantage per se to the attacker -- it can be part of a larger attack which also guesses TCP sequence numbers  (which seems harder).

Edit: actually Linux will allow a port to be reused for another connection while the first one is still active, but this does not happen often. Linux randomizes ephemeral ports (see RFC 6056) so, generally, a new port will be used. When the application does an explicit pre-connect bind(), a new port is necessarily allocated, since at that time, the kernel does not know the target address yet. For a bind-less connect(), another algorithm is used, which tends to prefer using a new port but may reuse an older. See this blog post for an analysis.


Will deferring password choice until after account activation improve security?

So if I'm reading your question correctly, you're concerned about attackers creating accounts using e-mail addresses they did not own.

The first question would be "why is this a problem?" I'm guessing that only a small percentage of the people who's e-mail addresses were mis-used would have clicked a sign-up link for an account they did not request?

Also it's generally possible for anyone to create an account on a site which just requires a valid e-mail address.  If you have your own domain name you can use [anything]@domain.name for as many accounts as desired and also there are services which provide temporary e-mail addresses explicitly for the purpose of signing up to things.

If the problem is that you don't want these accounts cluttering up your system, then I'd suggest that the best way to prevent it is to make them take some action after they click the link in e-mail, before you activate the account.

For example ask them to log in with the credentials they used to sign-up, and tie that to the one-time code in the link.


Is it possible to run commands that exist only on the host on a docker container?

Yes this is possible using nsenter or similar tools, depending on what you want to do you can also use Docker tooling.
A Docker container is just a namespaced Linux process, so using namespace aware tools you can execute a command from the host inside a given namespace.
For example, say you want to use tcpdump to diagnose a problem with networked nginx web site.
you can run docker run -d --name nginxtest nginx, to start the container, then run ps -ef | grep -i nginx and get the PID of the nginx process.
Once you've got that you can use something like sudo nsenter --target [PID] --net /usr/sbin/tcpdump to run TCP Dump from the host inside the network namespace of the nginx container.
Another option is to use a sidecar container which shares namespaces with a main container.  So for example you can run docker run -it --net container:nginxtest raesene/alpine-containertools  /bin/ash to run a new container which shares the network namespaces of the nginxtest container.
For mount namespace, it's a little more complex but still possible. you can view/edit files via the proc filesystem. So for example vi /proc/[PID]/root/etc/passwd would allow you to view/edit the /etc/passwd file from the running container . With this you do need to be careful of file permissions


Always use HTTP POST for sending data to the server.GET should be used for fetching the data.
You should always use HTTPS for your web service.

  API clients use the private API key to salt the hashing of the given username / password

If you are referring to the private key of your authentication server then this is a wrong approach.The private key of the server should not be kept with the client.If you are using a secure connection then you need not perform password hashing on the client side and let your server handle the load.

here is a good reference for password hashing techniques and using the salt.


Sort of.

Loopback traffic does not reach a physical network interface. It is routed through the virtual loopback interface, so it never leaves the machine.

Administrative applications (so that includes administrative users) and the system's high-privilege processes will be able to sniff the loopback interface, at least on Windows, OS X, and Linux. In some configurations, non-root processes may be able to access pcap and sniff loopback. In modern pcap installation config scripts it asks whether you would like to restrict pcap access to root-only, which prevents this issue.

TCP network sockets are not limited to particular users, so on multi-user systems a listening TCP socket will be accessible by all users on that system. Additionally, a process which runs before yours has chance to start may launch its own listening server on that port, and accept requests from the client. Whether or not that's a vulnerability depends on your use-case and threat model.


If your question is whether or not your ISP can tell that you're using OpenVPN rather than browsing an HTTPS website then the answer is yes. Even though both use the same port and TLS, the handshake process differs between HTTPS traffic and OpenVPN. This means that DPI is able to differentiate between an OpenVPN connection and that which is HTTPS.

Your options for circumventing this are either SOCKS proxies (preferred) or Tor (can be detected and blocked by some parties).

If your question is whether or not your ISP can decrypt your VPN connection once one has been established, then the answer is no. They cannot run DPI on an encrypted session without performing a MITM attack.


Overall, I would recommend HMAC unless you have particular requirements for client certificates. The reasons are:

Expiry

While it is true that there is no mandatory expiry with HMAC, in reality, you should expire any kind of password/secret/encryption key on a regular basis. This is enforced by certificates but you should do it as a matter of policy for any such key. I don't think this is a genuine pro for HMAC.

Intermediaries

If you have some intermediary like a Web Application Firewall that needs to inspect requests, it can be complex to use client certificates. This is a con for client certificates and a pro for HMAC.

Complexity

Is it really so complex to create an HMAC? There are client libraries to do this for Ruby, Java, .Net, Node and Python. I stopped googling there, but I'm sure most modern platforms have an existing library. This is probably a pro for certificates as you said, but a relatively minor one in my opinion.

Familiarity

HMAC is in use in some popular APIs from different market sectors (e.g. Twitter, AWS, Xero). I think client certificates are relatively uncommon outside of an enterprise setting. This is a pro for HMAC and a con for client certs. Disclaimer: This is subjective. I have no hard evidence for this - it's just based on what I've experienced in practice.


Why is an IV needed when encrypting a private SSH key

Because the CBC mode of symmetric cipher requires IV to decrypt the encoded key, as explained in the common picture of Cipher Block Chaining (CBC):

.

The IV is not part of the passphrase, because it is not a secret. It was generated as a random number, but you can decrypt the key itself only with the knowledge of this IV.

  Given a password protected private key like:

And note that it is not a password, but pass-phrase, which makes it basically the source data for key encryption key.


Is a file hash checking system 100% secure and non-bypassable/fakable?

If I understand you correctly, you're asking if the process you've described places the security burden on the hash algorithm, hence the question about how good hash algorithms are. Well scrutinized algorithms (like SHA1 through 3) should be very good, in that creating a collision should be extremely difficult.

However, from reading your process, I think the weak point lies elsewhere.

What is stopping the malicious user from lying about their hash result?
To prevent #1, you may require the users files to be uploaded and hashed on the server (creating its own set of problems). If so, how do you prevent the malicious user from sending the files you expect to see, while running modified files?

Tools such as MITMproxy make this trickery a lot more accessible that it used to be. You will probably find that Stackoverflow is also very good at noticing general process/workflow issues like this one.


Given a vulnerable JavaScript snippet from a Stack Overflow answer, how can I cheaply find websites whose authors have copied and pasted it?

There is no easy and powerfull way to mass scan for a given code.

Most of the possibilities I can think of have been written, but I will try to resume them into a complete answer. Also, my answer will applies for all snippets and not only for those from Stack Overflow.

Search for context : This is probably the most efficient way to search for source code. Are you searching for a vulnerabilities on a CMS (Wordpress, Joomla, e107) ? Most of them have specific context, such as Proudly powered by ... that you can Google. This does not seem apply to the questions you linked us, but sometimes, you can also guess a context where the code would be executed, which can help you to find them on traditionnal search engines.
Use source code search engines : Despite the fact that they are not as good as traditionnal search engines, you can still get some results for most popular website. There are plenty of them : nerdydata, globalogiq, publicwww, searchcode ...
Use code sharing platforms : As aborded in your question, you can use source code sharing platforms to find vulnerable code and trace back to the websites. Github has a effectively, but you might also try pastebin.
Crawl websites : This is probably the worst and slowly options, but it sure works.

If you are more interested about your own security, you can also :

Use a plugin : The plugin would look at the source code of the pages you visit and check if it can find a match with one of the code your searching for.

Of course, there are others powerfull way, such as using botnets, softwares you distribute ... but they require either time or illegal issues so they are not in the scope of the questions.


SSL interception with client certificate

You are typically trying to perform a Man in the Middle. There are many ways to do it.

easy way is by using Wireshark - refer blownie55's answer
Web Browsers these days come with Developer Tools Which show a lot. (Press F12 in Chrome)
Packet Dump at your Gateway. - Collect Packets from Client and then decrypt them using the Private Key (pretty hard, but doable).
Port Cloning or Port mirroring at your Gateway - Your Gateway simply forwards all traffic from a particular Port(say port A) in your router/switch to another Port of your choice(say port B) - you decrypt traffic from Port B using the Private Key.
Web Proxy -You can achieve this by:

setting up a Web Proxy with the Private Keys of both the Server and
Client, so the Proxy appears to be the Server to the Client and Vice
Versa.
Then you have to Route the traffic through the Web Proxy.(like using a Host file at the Client). - If your Gateway is also the web proxy, then don't bother with this step.


Learn about network and security for securing a server

I refer you to the answer to this question, and will copy relevant parts below. I've also added a section or two at the end.

Choosing a strong passphrase

Yes, we've all heard it time and time again, but there is probably no easier way to improve your security. If you're a fan of passwords, make sure to choose something that contains enough entropy to be reasonably secure, while still being easy to memorize. A random series of letters and numbers is great, but you probably won't be able to memorize a very long string of them. Anything that includes personal information should also be avoided. Mixing your name with your birthdate is not secure, no matter how long and random it might look.

Personally, I'm a fan of pass phrases. Pick a few random words from a dictionary (I choose somewhere between 5 and 10 depending on the required ammount of entropy), and you've probably generated enough entropy to keep an attacker guessing for much longer than will be practical (see the XKCD on the topic for a laugh).

Other people prefer to use pass-sentences. While these may be longer than your typical passphrase, they may or may not be anymore secure.

For more information on passphrases and passentences see, `Linguistic properties of multi-word passphrases' by Bonneau and Shutova of the University of Cambridge [PDF], or their blog post on Light Blue Touch Paper.

Install security related updates

Actually, if you're running anything make sure you've got the latest security updates. Simply turning on Automatic Updating in Windows, or making sure to run updates often in Linux can go a long way towards keeping you safe.

SSH

If you're using SSH to access your computer remotely, make sure to turn it off for the root account, and always use public key authentication. Other things you can do include disabling protocol 1, allowing only certain users to login remotely, and disabling X-forwarding (depending on your requirements). For more info, see this article on the CentOS wiki.

Websites

If you've setup a website that you'll be logging into (admin interface in a CMS for instance), always login over SSL (eg. make sure your browser says ``https://"). It's possible to buy a certificate for a reasonable price (I like Rapid SSL) or you can generate a self signed certificate and use that.

Social Engineering

Just to rehash my comment on the original post, social engineering is always possible. Never assume that you won't be vulnerable. Chances are you won't fall for the obvious stuff (an email from your colo provider asking for the root password to your machine, etc.), but even something as trivial as where your machine is hosted (maybe you give your address out on a form for something completely unrelated to some guy you randomly met in a coffee shop) can be very useful to an attacker.

WiFi

Logging in remotely via a wireless access point? Make sure it's using WPA2. WEP and plaintext connections are a no. If it's your own access point (maybe even on the same network as your server, though I'd hope not) make sure to choose a strong password (see above).

Security through obscurity is not security

As someone else pointed out, security by obscurity should never be seen as a security measure. The second of Kerckhoffs' six design principles for military ciphers states:

  It [the algorithm] must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience

This is applicable to much more than encryption algorithms, however, and should be taken as a general rule in any form of security engineering.

This principle is also known as Shannon's maxim after it was rephrased more simply by Claude Shannon as, "The enemy knows the system."


Access encrypted files (dm-crypt/LUKS) through web app

> Will a java app be able to seamlessly access those files?

Yes, and you don't need sudo for that (NEVER RUN A WEBSERVICE AS ROOT). Once the luks partition is opened and mounted, application software just sees a normal filesystem.

> Can I consider mounting the volumen through a webapp?

Mounting requires root permissions, so you must be very careful when writing the webapp. Ideally, write a small suid executable that just does the mounting with a given password, and call that from the webapp, giving the webapp no special privileges whatsoever. Be very careful on passphrase handling - if you're not careful, the passphrase might end up in a log on the server or be viewable on the running system unter /proc.

> How bad is the overhead for decrypting on the fly?

For just 4 to 5 users decrypting only 50MB of data each, you won't notice the additional cpu usage caused by the decryption.

Note: As long as your server runs with the luks partition opened, anyone with access to the server will obviously be able to read all the encrypted files. Luks only protects data at rest (e.g. when someone yanks the hard drives from your server and runs away with them).


Credit card information being sent over HTTP?

Yes, it's a big problem.  It's insecure, and it's a violation of PCI DSS 4.1:

4.1 Use strong cryptography and security
protocols (for example, SSL/TLS, IPSEC,
SSH, etc.) to safeguard sensitive
cardholder data during transmission over
open, public networks.

You can notify them that they're out of compliance, but the odds are they already know that.  If you can determine who their acquirer or processor is, you can try and notify them, as they're the ones who actually get fined if a breach occurs (...and they then pass fines down to the merchant(s) involved).  Overall, though, the PCI DSS structure is designed to encourage security and punish responsible parties, not to enforce security.


How to maximize security for a password repository?

Saving other people's passwords to other services is a very, very bad idea. It means that you now have the ability to steal every single password from your users, because you have the decryption key and your users only have your word that you won't use it. And even if you can convince your users that you are really a paragon of incorruptibility and would never do something like that (don't take it personally, but you certainly won't convince me), there is still the risk that someone will hack you. And considering how valuable you are as a target, many people will try their best to do that. You really can not expect any sane person to put that much trust into you and your operational security.

If you really have your user's best interest and privacy in mind, store their whole password database as a BLOB, encrypted with a key which is under the user's control. Do both the encryption and decryption of the password database on the client-side, so your server never sees the user's key or their data in cleartext. Your client-sided application can derive the key from the user's master-password (which you should not know either) using a key derivation algorithm like PBKDF2.

Problem: When the user forgets their master-password, they lose their whole password database. You can not help them, because by design you don't have the ability to decrypt it.  There is no good workaround for that. Data security always requires some secret, and a secret known to a 3rd party is no secret anymore.


You can request a CVE number without the details being published.

The timeline I have previously followed is:

Notify vendor
Request CVE number, while waiting for vendor response
Publish advisory, once issue is fixed or a certain amount of time has passed

I consider the CVE guys reasonably trustworthy, and I will disclose high-level details of the vulnerability to them before I published. They need this to avoid duplicates, but you can tell them to keep details private. If someone searches for the CVE at this point, it just says "reserved". When I publish, I copy the CVE guys and they then update the CVE entry to include the information.

You do need to get the CVE before you publish - it's pretty much essential to include a CVE number on your advisory.


Linux passwords are stored in the /etc/shadow file. They are salted and the algorithm being used depends on the particular distribution and is configurable.

From what I recall, the algorithms supported are MD5, Blowfish, SHA256 and SHA512. Most recent distributions should be on SHA512 by default if my memory serves me right.


Data will be encrypted while transmitted over the internet, not on either sender or receiver. So in other words:

sender (not-encrypted data) -> transmission (encrypted data) -> receiver (not encrypted data)

If you want your data to be protected even when received at the receiver side, then you will need to apply some encryption scheme before sending them over TLS. Also consider using digest authentication and not plaintext.


How can a site know about insecure password?

John the ripper is a password brute force and dictionary cracking utility that has been used for many years to determine user passwords. Some companies and organizations use it to validate employees are using passwords that meet complexity requirements.

http://www.openwall.com/john/

They may well have used John and cracked your password.

They may also store it with reversible encryption, and have analyzed the plaintext of your password. This is bad practice and one I would caution you about; if they do this, they are not adhering to industry accepted practice in this area. Where else are they not following the preferred way of doing things?

They may indeed have gathered statistics when you entered it, and have now gone back and analyzed that data. This is rather unwieldy. More likely they would use a function or module or dictionary (e.g. pam_cracklib.so) when you first tried to create the passwd; the system would tell you it was insecure right then and there in most cases.

Hard to say exactly, but if they are coming back after the fact, it sounds suspicious.

Make sure it isn't a phishing email... don't click the links, go to the site directly by hand.


No, you are almost certainly not being hacked.

This looks like standard behaviour for a browser. You probably typed those numbers into a site somewhere and now your browser is trying to be clever by thinking that Pinterest has similar text inputs to the previous site you put the numbers into, and suggesting you type the numbers into the text input on this new site.

To see exactly what is happening you can view the auto-fill data for your browser and you should be able to see those numbers:

Chrome

(I had to change my profile for the location of my "Web Data" file %LOCALAPPDATA%\Google\Chrome\User Data\[your profile]\Web Data)
Firefox


Blocking all incoming traffic, will it still accept a response from a request I initiated?

Stateful firewalls are mindful of incoming connections that are part of a circuit that was previously established. iptables can certainly do this.

The short answer is that you need a firewall rule that blocks all new incoming connections, but allows established incoming connections.


Sharing a message broker between remote systems

Anything that secures the connection will do.

The most compatible option using a layer 2 or 3 VPN to connect the two systems (and firewall them properly against anything else): unless you're dealing with a really, really strange protocol, you're pretty much guaranteed to be able to make it work. The downside is that it can be delicate to configure that on cloud-based hosts and it doesn't scale well.

The second option, as you guessed, is to use TLS connection between machines, That will depend heavily on what software you're using but TLS is a pretty common option and you can usually configure it for mutual x509 certificate authentication which will give you a pretty good level of security. Note that all HTTP-based RPC will be able to use TLS and that forcing mutual authentication is typically a matter of configuration.

The third option is to enable encryption inside the message broker architecture.  Contrary to what you wrote, many message broker system will allow you to configure end-to-end encryption at the message level. It's usually not really trivial to implement, however. for instance, take a look at WebSphere's help page on that subject. The main advantage of that option is that messages are encrypted at rest as well as in transit and that means the message queue system doesn't have to be able to decrypt the messages themselves: all it requires i^s the correct enveloppe data.


How do VPN providers prevent getting blocked using e.g. Cloudflare, like it is the case for Tor exit-nodes?

Cloudflare and IP blacklist services do not specifically target anonymity networks. What they do is look at the amount of traffic coming from particular IP addresses or ranges of addresses and catalogue how much of it is malicious. They apply blocks based on how malicious a given address appears to be.

VPN providers do not have any particular technique to avoid this. In fact, popular VPN IP addresses often are heavily blocked. The only reason Tor is more likely to be blocked is the fact that, because it is free, each IP address sees significantly more use, including for spam. This results in services like Cloudflare seeing more malicious traffic coming from Tor exits and applying increasingly harsh blocks. It is true that the list of Tor exit addresses is public. This is an unavoidable aspect of the protocol's design. However, that fact is not a significant reason for why Tor relays are blocked more often.

There are entire third party services which collect IP addresses that have been used for malicious purposes and provide such blacklists to their clients either for free or in the form of a subscription. A popular example would be DNSBL, which contains IPs from both many Tor exits and VPNs.


Can Untrusted Admin decrypt HTTPS traffic in Linux without Server Private key?

When SSL handshake starts, the first step is, server is authenticated using a private key associated to the server's certificate.

In a 2nd step, client and server exchange a session key used to encrypt the payload of the connection.

The session key is used for one session means when the session is closed the same key can't be used to encrypt the traffic of another session.

Now the problem is SSL often use RSA cipher suites in which the session key is derived from private key. So the session key can be calculated in future if the underlying private is known.

DHE and ECDHE provides Perfect Forward Secrecy(PFS), means session keys are not derived from private key. So the attacker cannot decrypt the traffic even when he has the private key used in the session handshake.Also Session key is not generated by client & nor derived from private key. Session key is not encrypted/decrypted/transmitted


Does Google Global Cache let the ISP intercept encrypted requests to Google?

As described here:

  Once registered and qualified by Google, we will send you a simple agreement for joining the GGC program. After you have electronically signed this agreement, Google will ship you servers that you install in your facility and attach to your network. Google will work with you to configure the servers and bring them into service.

Emphasis is mine. What this means is that your ISP can potentially inspect all the Google queries that the GGC is supposed to cache -- but this entails "opening" some tangible servers shipped by Google themselves. I suppose this would be a flagrant breach of the contractual agreement between the ISP and Google, so chances are that your ISP won't do that. Unless Google agrees, of course. Even if your local Law enforcement agencies insist on eavesdropping on you, it is probable that Google will be involved.


How to ensure that a router is fully reset to factory defaults

This is not the "slam dunk" answer you're hoping for.  Someone else might come along later and provide a better answer, but I figured I still had some helpful things to add.

The reality is that the intended way to completely wipe a router is by using the factory reset.  Your question basically boils down to, "Yes, but does the factory reset actually wipe everything???".  Unfortunately answering that question requires an expert on this particular router, or information directly from the manufacturer.  Neither of those things are likely to happen.

Fortunately it doesn't really matter, because realistically whoever ends up with your router is not going to be an expert on electronics to the extent that they will open the router, dump all memory in the device, and attempt to reconstruct old logs.  This is the sort of attack that you would have to worry about if you were developing nuclear weapons, but that is unlikely to be the case for you and I, so I wouldn't worry about things like that.  As a result I'd suggest something simple:

Factory reset the router
Login to the admin portal and see if you can find any residual logs or other data from its past life.
If not, give it away without worry
If so (and you are uncomfortable giving away that information), then perform a rapid unscheduled disassembly.


How can i fine tune hydra to find the correct password

Without seeing your test webpage it's hard to say.  However, looking at Hydra's source code, it appears to follow redirects and eventually inspects the content of the final page (assuming it didn't hit the redirect limit).

As for the HTTP module's options, you can specify a pass or fail criteria.

The option field (following the service field) takes three ":" separated
values and an optional fourth value, the first is the page on the server
to GET or POST to, the second is the POST/GET variables (taken from either
the browser, or a proxy such as PAROS) with the varying usernames and passwords
in the "^USER^" and "^PASS^" placeholders, the third is the string that it
checks for an *invalid* or *valid* login - any exception to this is counted
as a success.
So please:
 * invalid condition login should be preceded by "F="
 * valid condition login should be preceded by "S=".
By default, if no header is found the condition is assume to be a fail,
so checking for *invalid* login.

Your current pattern considers the password a failure if the resulting page contains "invalid".  Given that correct logins redirect, it may be better to instead search for a "pass" condition instead by prefixing the pattern with S=.


Is creating secondary account on Black-Box Pentest Forbidden?

ok so on any security assessment you must have a terms of engagement (which should largely spell out what is and is not in-scope of the review).  Assuming you're doing what would traditionally be thought of as "red-team" style assessments, then on those generally "any action an attacker might take" is valid for the assessment. However there are many different definitions of red team (like there are many for penetration test) and that's why the scope and contract are so important (to make sure the customer and supplier are on the same page).

As the comment from @adnan mentions, at the end of the test you should tell the customer about any created accounts, so that they can remove them from the system (along with any data created).  If you haven't done that, then a level of suspicion from the customer isn't too surprising.

However generally I would be inclined to respond that the account was created as part of the conduct of the test and as to data mis-use, this is governed by the NDA and contract that you have in place (again it's really important these are in place) which dictate what you can and cannot do with data retrieved during the conduct of the test.


Does this htaccess snippet provide sufficient security?

It is partial security as you mentioned, but this blacklisting approach will get you nowhere. For one, these snippets supposedly protect you from various attack vectors:

base64_encode looks for (most likely) PHP Remote Code Execution payload
script rule tries protect from XSS
the others are weird and possibly related to RCE or old PHP vulnerabilities where you could overwrite global variables.

Obfuscation

All of the rules you give are very simple to bypass, even with basic obfuscation. For example, XSS payload does not require <script> at all. For example, attacker might execute Javascript by sending <img src=1 onerror=js_code_here> and many, many other ways.

Obfuscation techniques are really advanced now and are often used to bypass application filters. If you're interested in obfuscation techniques, I recommend you read "Web Application Obfuscation" - it's an excellent book describing multiple ways of dealing with the filters you described.

What should I do then?

If you want to protect from malicious input to your application, the only way is to do both positive (i.e. not based on a blacklist) input validation and output escaping - you already should know how to do that from your previous question.

Web Application Firewalls

If you don't have control over application code (e.g. it's a legacy code deployed on a server that you need to maintain) or wish to take the 'defense in depth' route think about implementing Web Application Firewall e.g. based on mod_security. These firewalls are still base on a blacklists, so they won't offer 100% protection, but these blacklists are way more complete than the one you cite. For example, look at the problems mod_security faced & fixed when they announced a contest to bypass their SQL injection protection

Having said that, it's always best to fix the code of vulnerable application than to try to hide the vulnerability behind a firewall rule.


Is there any known Malware for Windows Phone 7?

It appears Flame can hit Windows Phone 7 as Microsoft just released a patch to address an attack via the Microsoft update vector using the cert flaw (Information Week article of 5 June 2012). So that answer is yes there is malware that attacks Windows Phone 7.


Does Kerberos authentication handle DNS names the same way between Windows 7 and Windows 10?

What you're seeing is name canonicalization during the formation of the SPN. Kerberos requires clients to resolve names to the official record in an attempt to restrict hijacking/ticket theft and Windows enforces that.

Both Windows 7 and Windows 10 will do this by default, but it's possible to configure it to not do that through registry settings like DisableStrictNameChecking. However, that's pretty drastic and dangerous.

The recommended approach is to register the appropriate SPN cifs/filesvr1234.prod.company to the service account you're using for the NAS.


Further potential problems with Windows 8 SmartScreen

Actually the article does not say that the SmartScreen client uses SSLv2; it just says that the server which SmartScreen contacts would be happy to accept incoming connections using the SSLv2 protocol. It would be surprising if SmartScreen indeed used SSLv2: most plausibly, Microsoft reused their own existing code for a SSL client, and that code does SSLv3+ by default. Using SSLv2 would imply extra effort for no gain.

Also, most of what is said about security of SSLv2 (in this article or elsewhere) is covered with a heavy layer of FUD. SSLv2 has issues, sufficient to warrant not using it (especially since SSLv3 and TLS are available), but not as dire than what is usually suggested. See for example this page; it is claimed that:

  Message integrity compromised. The SSLv2 message authentication uses the MD5 function, and is insecure.
  Man-in-the-middle attack. There is no protection of the handshake in SSLv2, which permits a man-in-the-middle attack.
  Truncation attack. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer cannot tell if it was a legitimate end of data or not.
  Weak message integrity for export ciphers. The cryptographic keys in SSLv2 are used for both message authentication and encryption, so if weak encryption schemes are negotiated (say 40-bit keys) the message authentication code uses the same weak key, which isn’t necessary.

The first point is downright FUD. It is a knee-jerk reaction: "MD5 ? BAD BAD BAD !". It is unsubstantiated. I am not saying that MD5 is rock solid; but I claim that the integrity check in SSLv2 is not that easy to defeat.

The second point is, at best, confusing and misleading. The "man-in-the-middle attacks" which are alluded to are the following: in SSL (v2, v3+...), both client and server may support several cipher suites; the client sends the list of suites it supports, and the server chooses one. With SSLv2, an attacker who is in position of doing a MitM can alter the list sent by the client, to force the client and server to use a specific cipher suite (within the set of suites that both supports, of course). The alteration is not detected later on (whereas, in SSLv3+, it would be detected at the end of the handshake). Then, the reasoning goes, SSLv2 is weak because the attacker can force client and server to use a "weak cipher suite" (e.g. one with 40-bit keys). But can it ? In fact, the attacker can force the use of a cipher suite that both client and server were already ready to accept -- and THAT is the weakness. What the attack breaks is the optimistic upgrading to stronger cipher suites when available; but the real weakness is when client and servers accept to use 40-bit keys.

The fourth point is more of the same: it says that if a key is weak and used for two usages, then breaking the key allows attacking the two usages. But the true weakness here is using a weak key.

Only the third point is really true: an attacker can force a connection close, and the machines cannot know whether the closure was intended by the peer. This is a serious problem with HTTP/1.0 without Content-Length attribute but not with other protocols, including HTTP as it is used nowadays.

Summary: SSLv2 is "broken", but not as much as is rumoured. No, a SSLv2 connection cannot be instantly decrypted by an attacker. And I personally deem it highly improbable that the SmartScreen client uses SSLv2; it would make too little sense.

(None of the above says anything about privacy issues with SmartScreen.)