What is a good general purpose GnuPG key setup?

About Using Subkeys

Use one primary key for each identity you need, otherwise, use subkeys.

Examples for using multiple primary keys:

You don't want to mix up your private and professional keys
You need some key not connected with your "real life" identity, eg. when prosecuted by the authorities

Examples for using subkeys:

You want to use multiple keys for multiple devices (so you won't have to revoke your computer's key if you lose your mobile)
You want to switch keys regularly (eg., every some years) without losing your reputation in the Web of Trust

I recently posted about How many OpenPGP keys to make in another answer.

About Key Sizes

The GnuPG developers recommend using 2k RSA keys for both encryption and signing. This will be definitely fine for currently used subkeys.

As your primary key will not be used for anything but keysigning and validating signatures (and revocation of course), it is seen as good practice to have a quite huge key here, while using smaller sizes (huge enough for time you will need them) for subkeys (which will speed up calculations and reduce file sizes).

I had a more detailed answer facing RSA with DSA/Elgamal for another question at Superuser, go there for reading further.

Key Expiration

There are two ways a private key could get compromised:

Somebody is able to steal it from you
Somebody is able to recalculate it from your public key

First is a matter of your computer's security (and how you use your key, read below), second is a matter of time. Today (and probably the next few years), RSA 2k keys will be totally fine. But computing power rises dramatically, so an attacker needs less CPU cores/graphic cards/computers/power plants to recalculate your private key. Also, glitches could be found in the used algorithms, leading to much less computing power needed. Quantum computers could speed up things even more.

A key expiration date will limit the validity of your key to a given time you expect it to be secure. Any attacker cracking it afterwards will only be able to read encrypted data send to you, but nobody will use it any more; if an attacker gets hold of your key and you stay unnoticed, at least it will stop him from having use from it after a given time.

Expiring your primary key will let you lose all your Web of Trust reputation, but at least invalidates your key after a given time if you lose access (what should never ever happen, read on at the end of my answer).

Storing your Primary Key Offline

Your primary key is the most crucial one. All trust - both incoming and outgoing - is connected with this. If somebody gets access to it, he's able to:

Create new keys using your name (and GnuPG always uses your newest subkey by default!)
Revoking subkeys and primary keys
Issuing trust to other keys, which is the worst thing to happen: An attacker could create a new key, giving it trust from your old one and then revoke your old key, leaving you without any access to your "moved" identity - he's literally overtaking your identity.

  How important is it actually to keep the certification key offline when one uses a) a "really" strong passphrase [...]?

Your computer always could be hacked or infected by some malware downloading your keys and installing a key logger to fetch your password (and this is not a matter of which operating system you use, all of them include severe security holes nobody knows about at this time).

Keeping your primary (private) key offline is a good choice preventing these problems. It includes some hassles, but reduces risks as stated above.

Highest security would of course mean to use a separate, offline computer (hardware, no virtual machine!) to do all the key management using your primary key and only transferring OpenPGP data (foreign keys and signatures you issued) using some thumb drive.

  b) a hardware device like an OpenPGP card?

OpenPGP smart cards are somewhere in between storing it offline on a thumbdrive, but attaching it to your computer for signing and using another offline computer dedicated to this purpose. Your private key will never leave the smart card (except for backup purpose) which requires an "admin PIN", all signing and even key creation will happen inside the card. "Using" your key (encryption, signing, giving trust) will only require a "user PIN", so even if you connect the card to a "harmed" computer, the attacker will not be able to completely overtake your ID.

You can store your public key wherever you want, for having real use of OpenPGP, you even should send it (and your other public keys) to the keyservers.

And do not forget to create and print a revocation certificate of your primary key. Losing your private key not having this certificate means there is a key you cannot access any more lingering on the keyservers and you can't do anything about it.

Print it, possibly several times, and put it to places you trust. Your parents, some bank deposit box, ... - if this certificate leaks, worst thing to happen is losing your Web of Trust.


Port Scanning Host that has Rate Limiting Enabled

The --defeat-rst-ratelimit option works around rate-limiting of the target's responses on closed ports by allowing inaccuracies in differentiating between closed and filtered ports. It does not affect packet rates or open port detection.

In addition to rate-limiting the TCP RST and ICMP Port Unreachable messages, a host with an adaptive firewall can detect a port scan and firewall the source address for a time. Nmap does not have a native way to detect and correct for this kind of behavior. Instead, you should try to avoid hitting the thresholds that trigger a firewall response. This will drastically increase your scanning time, but will improve accuracy. Here are some useful options:

-T - Setting a conservative timing template will help slow the scan to acceptable levels. -T1 would be a good place to start for an aggressive firewall. -T0 is incredibly slow.

--max-retries - Nmap may continue to try to get a response from filtered (firewalled) ports in case a packet was dropped. Setting this to 0 will prevent this behavior, but you may miss some open ports if there is any packet loss.

-sT - Using TCP Connect scanning will avoid firewalls and IDS that detect the odd SYN, SYN/ACK, RST behavior of the default TCP SYN scan.

-p and --top-ports - The fewer ports you scan, the less likely you are to set off an alert. If you are only interested in a few ports, only scan for those.

This list is vastly incomplete, and Nmap scan tuning is very complex. Your best bet is to read the documentation in order to fully understand the behavior of Nmap and your target.


Using Linux iptables to implement a stateless, packet filtering firewall

For a stateless firewall, you can either accept or drop a packet based on its protocol, port number and origin ip address. For example, the rule below accepts all TCP packets from the 192.168.1.x subnet that are bound for port 80.

-A INPUT -p tcp -s 192.168.1.0/24 -m tcp --dport 80 -j ACCEPT

For output, the rules look similar. Therefore, outgoing(egress) packets are only accepted if there is a matching rule. The rule below allows only outgoing packets on port 80.

-A OUTPUT -o eth0 -p tcp --sport 80 -j ACCEPT

For a stateful firewall, you have the ability to monitor state. For example, the rule below only accepts packets to port 80 if it is initiating a new connection or is associated with an existing connection. The tracking is done by a kernel module "ip_conntrack". It keeps a table of all active connections.

-A INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT


Reporting leaked passwords in github repository

You should be able view the email address associated with a commit to the repo in the git log, the easiest way to view this on github by adding .patch to the URL

for example:

https://github.com/git/git/commit/9d77b0405ce6b471cb5ce3a904368fc25e55643d

the patch URL is:

https://github.com/git/git/commit/9d77b0405ce6b471cb5ce3a904368fc25e55643d.patch

This will give you the commit data, from which you can get the author's email address - you should be able to contact them on that!


How to make the Tag number of the RFID device appear as a secret number?

Most cheaper RFID tags are dumbtags which stores a static identification value that can be read by any NFC compatible reader. For these dumbtags, you can simply write an app that captures the code as it's being transmitted (or use one of the hundreds of Android NFC readers). In cases where the reader acts as a Keyboard HID, you can simply open a plain text editor and scan. Such RFID dumbtags have many uses but should never be used for security critical scenarios.

To prevent the internal secret code from being known to the user or from being transmitted to the reader/computer, you need an RFID smarttag that uses asymmetric cryptography so the actual secret is never actually transmitted to the reader. Instead, what happens is that such RFID smarttag computes a one-time use, time-limited code based on an internal secret and this is the code that's transmitted. The internal secret itself is never transmitted out of the tag, and the cryptographic algorithm is such that it's mathematically impossible to reverse calculate the internal secret from the one time codes.

The more secure tags involve a challenge-response protocol, in which the smarttag computes a code that can only be used for that particular transaction, and may also have a small display to review the transaction details before approving them.

These measures are designed to prevent and/or limit damage in the scenario where the reader unit may have been compromised, since the transmitted one time code would only be valid for that transaction only and can't be used for future transactions.

Even higher security tags may even include a keypad where you can type your PIN and are designed to be tamper proof to protect against both compromised reader and stolen tag, since the tag is not usable without the PIN.


Determine SSL/TLS version using Wireshark

(Adding a new answer which should be definitive, leaving the old around as it's useful debug for how we got here.  Credit for pointing to the actual answer in comments goes to @P4cK3tHuNt3R and @dave_thompson_085)

  Using Wireshark, I am trying to determine the version of SSL/TLS that
  is being used with the encryption of data between a client workstation
  and another workstation on the same LAN running SQL Server.

You are viewing a connection which uses MS-TDS ("Tabular Data Stream Protocol"):

...the Tabular Data Stream Protocol, which facilitates interaction with
a database server and provides for authentication and channel encryption
negotiation; specification of requests in SQL (including Bulk Insert);
invocation of a stored procedure, also known as a Remote Procedure Call
(RPC); returning of data; and Transaction Manager Requests. It is an
application layer request/response protocol.

If you view the TDS protocol documentation, it specifies that the SSL packets are encapsulated within a TDS wrapper:

A TLS/SSL negotiation packet is a PRELOGIN (0x12) packet header encapsulated
with TLS/SSL payload.

In the Microsoft Message Analyzer screencap you posted, we can see the TDS header (boxed in Red, starts with 0x12), followed several bytes later by the TLS CLIENT_HELLO packet (boxed in Blue, starts with 0x16 0x03 0x03):

0x16 is the TLS "Handshake" header indicator,
0x03 0x03 is the TLS version (TLS 1.2, as per RFC 5246):

The version of the protocol being employed.  This document
describes TLS Version 1.2, which uses the version { 3, 3 }.  The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0.

So the simple answer to your question, "determine the version of SSL/TLS", is "TLS 1.2".

Now, I've seen varying reports as to whether Wireshark can properly parse TDS packets with encoded TLS.  I think that the answer is what you started with - it will tell you TLS is there, but won't parse the details as it would with a native TLS session.

As per this StackOverflow question, it appears that Microsoft Network Monitor is capable of parsing both levels of encapsulation.  And a comment therein states that Microsoft Message Analyzer is the newer equivalent of that tool.


XSS attack on websites that allows JS file upload?

That depends on whether or not the website allows file inclusion via URLs, or if the site persists some JavaScript to run again later.

About Remote File Inclusion

Imagine the website has a feature where you can link to some external JavaScript file and run that. If this can be done via a link, e.g. via example.com?src=evil.com/mal.js, then this is a reflected XSS vulnerability.

The ability of the application to interactively load remote JavaScript is not enough. It needs to be done via an URL, so that the only thing the victim has to do is click the URL.

About Persistence

If the website allows users to run JavaScript that others have created, then you may have a stored XSS vulnerability, but it depends on how the site is structured. For example, if you visit example.com/mallory/mal/ and the website asks you if you are sure you want to run mal.js by Mallory and warning about the risks of running untrusted code, then you should be fine. If the website however just runs it, then I would classify this as stored XSS.

About Social Engineering

One might argue that it's a case of self-XSS, where an attacker could social engineer a person into downloading a malicious JS file and running it on your website. While this is a legitimate concern, I would not consider this a huge vulnerability. You could mitigate this risk somewhat by displaying a warning, though users may click that away.


Why did RFC 4158 (Path Building) restrict Trust Anchors to self-signed certificates?

This is one of those tricky subtle wordings. The full meaning of the RFC may not be obvious on the first reading. From your question (emphasis mine):

  Trust Anchor: The combination of a trusted public key and the name of the entity to which the corresponding private key belongs.
  Trust Anchor Certificate: A self-signed certificate for a trust anchor that is used in certification path processing.

A trust store serves two purposes:

Establish that all signatures generated by this public key should be trusted, and
Bind the public key to a name (usually an LDAP Distinguished Name (DN) is defined in RFC2253)

Some corollaries of that are:

All signature performed by that key will be trusted, including certificate issuances.
Because you are explicitly marking it as Trusted, This key can not be revoked through normal methods - the only way is to manually remove it from your trust store.

The subtly here is that the RFC allows you to pin either a certificate, or a public key directly, however if you pin a certificate then it needs to be a root certificate. The RFC gives some justification here:

  1.5.1.  Hierarchical Structures

  A hierarchical PKI, depicted in Figure 1, is one in which all of the
     end entities and relying parties use a single "Root CA" as their
     trust anchor.

From the CA's point of view, they may not want you pinning the intermediate CA because that removes their ability to revoke it if it becomes compromised: even if they publish a revocation for it, your client will ignore it.

In the case where a CA does want you to be able to use an intermediate CA as a trust anchor, I have seen them give a trust anchor both an issued certificate, and a self-signed cert for the same public key and DN. I would assume that Let's Encrypt does not do this for its intermediate CAs.

As to your actual question about wget, ftp.gnu.org, and the Let's Encrypt X3 intermediate CA, I think you have two options:

Find the self-signed root cert that issued Let's Encrypt X3 and add that to your trust store.
Figure out how to pin a public key directly. This will depend on the software / OS stack you're using and whether it supports the archaic and uncommon part of the RFC that allows a Trust Anchor to be a key and not a certificate.


RSA is actually two algorithms, one for asymmetric encryption, and one for digital signatures (the signature algorithm is traditionally -- but incorrectly -- described as "encryption with the private key" and this is an endless source of confusion).

Asymmetric encryption uses keys. Keys are parameters to the algorithm; the algorithm itself is the same for everybody (in software terms, it is the executable file) while keys vary between users. In a key pair, the public key is the key which is used to encrypt data (convert a piece of data, i.e. a sequence of bytes, into another sequence of bytes which is unfathomable for everybody) while the private key is the key which allows one to decrypt data (i.e. reverse the encryption).

Whereas in symmetric encryption, the encryption and decryption keys are identical, but with asymmetric encryption, the encryption and decryption keys are distinct from each other (hence the name); they are mathematically linked together, but it should be unfeasible (i.e. too hard to do with a mere bunch of computers) to recover the decryption key from the encryption key. This is why the encryption key can be made public while the decryption key is kept private: revealing the public key does not reveal the private key.

What asymmetric encryption achieves is no trivial feat. The possibility to reveal the public key while not saying too much about the private key, but such that both keys work together (what is encrypted with the public key can be decrypted by the corresponding private key, but none other), requires a lot of mathematics! RSA is full of mathematics. This contrasts with symmetric encryption algorithms which are "just" ways to make a big mess of data by mixing bits together.

Asymmetric encryption is the natural tool to use when we want to allow for confidential transmissions between any two users among a big population. If you have 1000 users, and you want any of the two users to be able to exchange data with each other without allowing anybody to spy on them (including the 998 other users), then the classical solution would be to distribute keys for symmetric encryption to every pair of users. Alice and Bob would have a known, common key; Alice and Charlie would also have a shared key (not the same); and so would Bob and Charlie; and so on. Each user would need to remember his "shared key" with every other one of the 999 other users, and you would have 499500 keys in total. Adding a 1001th user would involve creating 1000 additional symmetric keys, and give one to each of the 1000 existing users. The whole key distribution soon turns into an unusable/infeasible nightmare. With asymmetric encryption though, things are much more straightforward in terms of key distribution: every user just has to remember his/her own private key; and the public keys(being public) can be distributed through some sort of broadcasting (e.g. a directory).

RSA has some operational constraints. With the most used variant (the one known as PKCS#1 v1.5), if the size of the RSA key is "1024 bits" (meaning that the central mathematical component of the key pair is a 1024-bit integer), then RSA can encrypt a message of up to 117 bytes in length, and yield an encrypted message of length 128 bytes. That limited size, and the size increase when encrypting, are unavoidable consequences of the mathematical structure of the RSA encryption process. Due to these constraints, we do not usually encrypt data directly with RSA; instead, we select a small sequence of random bytes, which we call session key. We encrypt the session key with RSA; and then we use the session key with a symmetric encryption algorithm to process the whole message. This is called hybrid encryption.

SHA is the common name for a family of cryptographic hash functions. The very first member of that family was described under the name 'SHA' but was soon deprecated after a serious weakness was found in it; a fixed version was published under the name SHA-1 (the weak version is colloquially known as SHA-0). Four new SHA-like functions were added to the family later on (SHA-224, SHA-256, SHA-384 and SHA-512: which are collectively known as 'SHA-2').

Hash functions have no key. A hash function is an executable algorithm which is pure code. There is one SHA-1 and everybody uses the same.

Hash functions "just" make a big mess of the input data, which is not meant to be unraveled. Actually, it is meant to be resilient to unraveling. Even though everybody knows all that is to be known about a hash function (there is no key, only code, and nothing of it is secret), it still turns out to be "too hard" to recompute a matching input message, given the hash function output. It is even unfeasible to find two distinct input messages which, when given to the hash function, yield the same output; there must exist such pairs of messages -- called collisions -- because a hash function output has a fixed small size, while accepted inputs can be widely larger, so there are more possible inputs than possible outputs. It is a mathematical certainty that collisions exist for every hash function, but actually finding one is another matter.

A hash function, as itself, does not do anything of immediate high value, but it is a very important building block for other algorithms. For instance, they are used with digital signatures. A digital signature "proves" conscious action of a designated signer over a piece of data; like asymmetric encryption, this involves key pairs and mathematics, and associated constraints on the signed data. A hash function h is such that signing h(m) is as good as signing m itself: since it is unfeasible to find two distinct messages which hash to the same value, approval of the hash output is good enough. The point being that the output of the hash function is small enough to be usable with the mathematics hidden in the signature algorithm, even if the message itself is big (SHA-1 can process gigabytes of data, and yield a 20-byte output).

It can be noted that some recent variants of RSA-the-encryption-algorithm (with the 'OAEP padding' from PKCS#1 v2.0) internally uses hash functions. Hash functions are good "randomizers" (the output of a hash function does not exhibit recognizable structure) and this makes them appropriate for building more elaborate cryptographic algorithms with good security features.

In SSL/TLS (HTTPS is just HTTP-within-a-SSL/TLS-tunnel), hash functions are used for several things:

as part of asymmetric encryption and/or digital signatures;
as part of HMAC to allow client and server to verify that exchanged data has not been altered in transit;
as a building brick for a Key Derivation Function, which "expands" a given session key into several symmetric keys used for symmetric encryption and integrity checks in both directions of the tunnel.

The KDF relies on the "randomizing" and non-invertibility of the hash function. In SSL/TLS up to TLS 1.1, the KDF is built over two hash functions, MD5 and SHA-1, in an attempt to make it robust even if weaknesses were later found in either MD5 or SHA-1. It turns out that weaknesses were found in both, but it did not allow any break on the KDF as used in SSL/TLS. Nevertheless, TLS 1.2 switched to another KDF which uses a single, configurable hash function, usually SHA-256, for which no weakness is currently known.


What are the security risks of a phone-based authentication?

I do not see any security issues with this approach, it simply uses an already existing session (your Google session in your mobile browser) to approve a login request for a new session.

Facebook does something similar - when you enable 2FA it behaves as you would expect but if you have their mobile app you get a notification and can approve the login from the app itself without even having to enter an OTP on the login page.

I think it hasn't taken off because of usability issues and disadvantages compared to standard OTPs. In both cases you have to take out your phone, but with this system you also need to take a picture of the QR code and then be connected to a network to access the URL. Plain old TOTP is just as secure but without those drawbacks.

Finally this is aimed at thwarting malware on untrusted machines but the issue is, no matter how you log in, the compromised computer would still be able to use and abuse your account anyway it wants, as it will get access to a logged in session. How you logged in doesn't matter much if it can still get access and grab all of your personal data.


Preventing new NVRAM areas from being defined in a TPM

To clear an NV index or define a new one, you need to have access to the owner auth data. If you control this data, then you control the erase and write portions of the TPM's NV storage. The access controls for reading NV data are established when each NV index is defined. If the index is defined to require owner auth to read, then that is what the TPM will enforce.

The TPM is the sole authority over its NV storage, but it doesn't really care about its contents. (There is NV space used by the TPM for internal purposes, such as the storage of the private endorsement and storage root keys, but this portion of the NV is not exposed to the TPM owner or user.) The TPM does not read, write, delete, or modify anything in NV without explicitly being requested to do so. Anything in the OS that works with TPM NV needs to be TPM-aware. The TPM's NV is not treated like other forms of non-volatile storage that an OS has at its disposal.


The bigger problem is not your linkedin account getting hacked, it's Linkedin itself getting hacked and all users emails + passwords becoming avaiable
To unlikely? It already happened before. Adobe, eBay, Yahoo, PlayStation Network, the list goes on... all of these companies have had their database hacked and users emails and passwords leaked in the past (some of them, twice).
So, if you want to be safe, you should not use the same password for more than one website. Yes, that may be extremely annoying, but it doesn't have to. You can use a password manager that generates unique strong passwords for every account you create and stores them for you. Of course, this leads to a single point of failure, so you should use a very strong and unique password on the password manager. You can browse all about this if you want to know more.


Which CVE Numbering Authority (CNA) should I contact for a vulnerability found in the GNU Scientific Library?

First off, don't forget to contact the authors of the library (pick the appropriate contact from the list) so that they issue a fix by the time the CVE is fully disclosed.
If the product affected by the vulnerability is not covered by a CNA in the list (and the GNU Scientific Library certainly isn't), you need to contact the CNA of Last Resort.
There are two of them, but in your case, again, I'd go with MITRE itself: here's the form. I have positive experience working with them on a vulnerability disclosure and CVE number assignment.


The question is a bit vague, the short answer is Yes clicking on links could DoS your site.

A for a more in-depth answer you would need to look at what those links are doing. For example if every time you clicked a link it ran some monstrous database query that used all your CPU power or Disk IO, or if the links played a video that would quickly saturate your outbound bandwidth it wouldn't take a lot of clicking to DoS your site.

I've seen this happen with people's personal blog that's hosted at home on an ADSL connection and more than one person viewing a video at a time DoSes their site.

On the other hand if your links were to static HTML or something easily cached it would take a whole lot of clicking to DoS your site.


What is the difference between RSA1 & RSA in regards to SSH? Also when is the fingerprint & random art used?

In version 1 of the SSH protocol, the server has a RSA key (always) and the client asymmetrically encrypts a random blob with the server's public key. The random blob is then used as basis for the session key which will be used to encrypt the data.

In version 2 of the SSH protocol, client and server use Diffie-Hellman (or an elliptic curve variant thereof) to established a shared session key. The server signs his half of the protocol with his key, which might be RSA or DSA.

While RSA encryption and RSA signature can both use the same kind of mathematical object (a "RSA key"), they are nonetheless distinct algorithms. The SSHv2 way additionally offers Perfect Forward Secrecy, which is good (if someone steals the server's key, he can decrypt past SSHv1 connections that he recorded, but not so with SSHv2 connections).

In the SSH model, the client makes sure that it talks to the right server by remembering the public key of each server (that's the .ssh/known_hosts file). When it encounters a new key (a server to which the client never connected yet), it wants to display something which the human user may use to confirm that the public key from the server is genuine. The fingerprint is a hash value; the user is then supposed to phone the intended server's sysadmin, to dictate the fingerprint and get confirmation that's it is the right one.

The "random art" is a visualisation of the fingerprint in a way which is supposed to be easily remembered by a human eye & brain. The idea is that the user first memorizes the "art" associated with the server, and later on visually checks that the recomputed "art" is the same. (Intended scenario: being able to use random client machines while travelling.)

Personally I prefer to learn by heart the fingerprint; at least I can compute the success probability of the attacker. Better yet, I travel with my own device, which at least should be less virus-ridden than a random machine from an Internet café.


Encrypted disk at risk if laptop stolen while turned on but locked

There are known attacks using DMA and a firewire port that can override the locking screen's protection.  Unless certain firewire features that are on by default were disabled, simply plugging in a firewire adapter and running some specialized code can make the lock screen accept any password.


Do software do an integrity check before executing?

Performing such an integrity check is not a proper security measure. It might be some DRM-like obscurity that makes it harder to bypass licensing or some protection for accidental damage of executable file, but not a Keckerhof-like security countermeasure.

The problem is, once an attacker can modify the binary, she can also modify or completely remove the integrity check. (And if the attacker cannot modify the binary, such an attack is useless.)

Even if an attacker cannot find where the integrity verification is, she can, for example, create an executable that unpacks original executable and some malicious executable and runs both of them. Well, this might make it more obvious that there is some malware on the machine.

But vendors aren't likely to use complex solutions that are hard to find, because it is a lot of work and there is some risk of false alarms etc. On the other hand, some standardized solution will probably be easy to defeat – just because there would then be more motivation to make some universal tool.

A proper solution for the integrity problem are digital signatures that have to be checked before the binary starts. This is something that is commonly used.


SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?

You are correct that SSL uses an asymmetric key pair.  One public and one private key is generated which also known as public key infrastructure (PKI).  The public key is what is distributed to the world, and is used to encrypt the data.  Only the private key can actually decrypt the data though. Here is an example:

  Say we both go to walmart.com and buy stuff.  Each of us get a copy of
  Walmart's public key to sign our transaction with.  Once the
  transaction is signed by Walmart's public key, only Walmart's private
  key can decrypt the transaction.  If I use my copy of Walmart's public
  key, it will not decrypt your transaction.  Walmart must keep
  their private key very private and secure, else anyone who gets it can
  decrypt transactions to Walmart.  This is why the DigiNotar breach was such a big deal

Now that you get the idea of the private and public key pairs, it's important to know who actually issues the cert and why certs are trusted.  I'm oversimplifying this, but there are specific root certificate authorities (CA) such as Verisign who sign certs, but also sign for intermediary CA's.  This follows what is called Chain of Trust, which is a chain of systems that trust each other.  See the image linked below to get a better idea (note the root CA is at the bottom).

Organizations often purchase either wildcard certs or get registered as a intermediate CA themselves who is authorized to sign for their domain alone.  This prevents Google from signing certs for Microsoft.

Because of this chain of trust, a certificate can be verified all the way to the root CA.  To show this, DigiCert (and many others) have tools to verify this trust.  DigiCert's tool is linked here.  I did a validation on gmail.com and when you scroll down it shows this:

This shows that the cert for gmail.com is issued by Google Internet Authority G2, who is in turn issued a cert from GeoTrust Global, who is in turn issued a cert from Equifax.

Now when you go to gmail.com, your browser doesn't just get a blob of a hash and goes on it's way.  No, it gets a whole host of details along with the cert:

These details are what your browser uses to help identify the validity of the cert.  For example, if the expiration date has passed, your browser will throw a cert error.  If all the basic details of the cert check out, it will verify all the way to the root CA, that the cert is valid.

Now that you have a better idea as to the cert details, this expanded image similar to the first one above will hopefully make more sense:

This is why your browser can verify one cert against the next, all the way to the root CA, which your browser inherently trusts.

Hope this helps you understand a bit better!


Is it possible to change IP after each request

Yes it can be done.  It's trivial.

There are many ways for a user or an attacker to have multiple IP addresses - or to share IP addresses.  Here's a list, off the top of my head.

These all assume that the IP address of the target system is exposed to your server.  Either you're running some code (like JavaScript) to detect the IP address, or the client allows connections directly from systems without any interruption.

Shared Addresses

This list is how one IP address may be used by multiple systems.

Multi-user host.  Many hosts are used by multiple people.  by definition, they will all use the same interfaces to connect to your server, and therefore share IP addresses.
DHCP.  DHCP works by creating a pool of IP addresses, from which the client (the system that will eventually connect to you) is assigned one of the addresses.  The IP address used by this system is eventually returned to the pool.  At this point, someone else can pick up the IP address.  If both systems connect to your system, they could each connect at a time when they possess the IP address.
Manual IP configuration.  Anyone can configure their network interface to use any IP address they want.  A system could be intentionally configured to use an IP address in use by another system.
False Information.  If you are detecting the IP address by running code on the client, the client can feed your code false information.  For example, a Greasemonkey script can modify your javascript and cause it to return any IP address the attacker wants.
NAT. There are networks that use Network Address Translation to show a very small number of re-used IP addresses to the internet, while using entirely different addresses within the network.  This is extremely common.  WHen clients connect to your server through NAT servers, they will all appear to come from the same IP address.
Reserved IP Addresses.  It is very common to pair NAT with reserved IP addresses.  Reserved IP addresses, such as 192.168.*.*, are re-used by many organizations.  These addresses are only routable within the local network, so NAT servers present other networks with remotely routable addresses.  If you use something like JavaScript code to detect the IP address of the client, there will be many clients that reuse these addresses.

Multiple Addresses

This list is how a single host can appear to have multiple IP addresses.

DHCP.  As described in the first list, the IP address is eventually released by the system using it and returned to the pool.  When the system connects back to the network, it will be granted a new address, which is not guaranteed to be the same as the old address.
Manual IP configuration.  Anyone can configure their network interface to use any IP address they want.  A system could be intentionally configured to use one IP address, then five minutes later use another address.
False Information.  If you are detecting the IP address by running code on the client, the client can feed your code false information.  For example, a Greasemonkey script can modify your javascript and cause it to return any IP address the attacker wants.
NAT. NAT isn't required to use the same address the every time for the same client.  A single client could connect to your server through NAT and be given a different IP address every time.
Laptop roaming across networks.  When a system disconnects from one network and connects to another network, it gets a new IP address from the new network.  While there is a low probability of a getting a reserved locally routable address from the new network that exactly matches the reserved locally routable address from the old network, this is far from guaranteed.  More likely, the address will be different.  The NATted address is "guaranteed" to be different.
Multi-homed machines.  A multi-homed machine is connected to the network via multiple network cards, or to multiple networks with multiple interfaces.  This machine, by definition, has multiple IP addresses - one for each interface.  If traffic comes to you through one network one time, then the other network another time, the same host will connect using multiple addresses.  This is unlikely, but can occur given the right network structure.
Botnet.  Attackers can rent or build a botnet.  The botnet will, by definition, be constructed of multiple systems, each of which will have a different IP address.  The attacker will have multiple IPs at his/her disposal.


What security implications are involved when using a CSV file to fill a SQL table?

SQL injection is the "injection" of an SQL query/command with the intention of execution. A good summary and reference is available from OWASP.

In this case, the risk would be that the CSV file includes commands which would, upon being loaded into the SQL database, be executed rather than simply inserted into a table.

You could approach resolving this problem from either the position of the sender or receiver. Approaching this from the sender side - that is, manipulating the input data - only makes sense if you are in control of the data and are concerned about malformed input rather than malicious attacks. Mitigating SQLi at the database side is the correct and far more secure way to do this, however in some situations it can be more effort.

On the sender side, you may choose to parse inputs before they are sent to ensure they only contain the intended data - perhaps only alphanumeric characters. This would generally make sense for something like a webpage form, where malformed input would prompt the user to do something like "Input a valid email address" which serves to both correct user input for accuracy as well as manage what sort of input is sent to the database. In your case, this may be simplest (though not necessarily best) solution if you know what the input CSV should look like and contain in all cases.

The generally better and more versatile solution involves handling this from the position of the data receiver, the SQL server itself. This means performing the same or similar validation as above, but instead as the SQL server receives and saves input. In the case of an SQL injection attempt, this should hopefully catch what looks like a query or malformed input and either discard it or treat it simply as text input - but most importantly, not execute it as a command.

The ways to validate input depend on what your input looks like and what you'd like to do with it in your own situation. OWASP also provides an excellent guide on this which I suggest you review.

It may be additionally useful to look at what SQL queries/injection attempts look like so you can see what sort of special characters and commands you will need to be able to handle if they may be a part of your input dataset.


Oracle Internet Directory (OID) hardening


General
SSL (and its successor, TLS) is a protocol that operates directly on top of TCP (although there are also implementations for datagram based protocols such as UDP). This way, protocols on higher layers (such as HTTP) can be left unchanged while still providing a secure connection. Underneath the SSL layer, HTTP is identical to HTTPS.
When using SSL/TLS correctly, all an attacker can see on the cable is which IP and port you are connected to, roughly how much data you are sending, and what encryption and compression are used. He can also terminate the connection, but both sides will know that the connection has been interrupted by a third party.
In typical use, the attacker will also be able to figure out which hostname you're connecting to (but not the rest of the URL): although HTTPS itself does not expose the hostname, your browser will usually need to make a DNS request first to find out what IP address to send the request to.
High-level description of the protocol
After building a TCP connection, the SSL handshake is started by the client. The client (which can be a browser as well as any other program such as Windows Update or PuTTY) sends a number of specifications:

which version of SSL/TLS it is running,
what ciphersuites it wants to use, and
what compression methods it wants to use.

The server identifies the highest SSL/TLS version supported by both it and the client, picks a ciphersuite from one of the client's options (if it supports one), and optionally picks a compression method.
After this the basic setup is done, the server sends its certificate. This certificate must be trusted by either the client itself or a party that the client trusts. For example, if the client trusts GeoTrust, then the client can trust the certificate from Google.com because GeoTrust cryptographically signed Google's certificate.
Having verified the certificate and being certain this server really is who he claims to be (and not a man in the middle), a key is exchanged. This can be a public key, a "PreMasterSecret" or simply nothing, depending on the chosen ciphersuite. Both the server and the client can now compute the key for the symmetric encryption whynot PKE?. The client tells the server that from now on, all communication will be encrypted, and sends an encrypted and authenticated message to the server.
The server verifies that the MAC (used for authentication) is correct and that the message can be correctly decrypted. It then returns a message, which the client verifies as well.
The handshake is now finished, and the two hosts can communicate securely. For more info, see technet.microsoft.com/en-us/library/cc785811 and en.wikipedia.org/wiki/Secure_Sockets_Layer.
To close the connection, a close_notify 'alert' is used. If an attacker tries to terminate the connection by finishing the TCP connection (injecting a FIN packet), both sides will know the connection was improperly terminated. The connection cannot be compromised by this though, merely interrupted.
Some more details
Why can you trust Google.com by trusting GeoTrust?
A website wants to communicate with you securely. In order to prove its identity and make sure that it is not an attacker, you must have the server's public key. However, you can hardly store all keys from all websites on earth, the database would be huge and updates would have to run every hour!
The solution to this is Certificate Authorities, or CA for short. When you installed your operating system or browser, a list of trusted CAs probably came with it. This list can be modified at will; you can remove whom you don't trust, add others, or even make your own CA (though you will be the only one trusting this CA, so it's not much use for public website). In this CA list, the CA's public key is also stored.
When Google's server sends you its certificate, it also mentions it is signed by GeoTrust. If you trust GeoTrust, you can verify (using GeoTrust's public key) that GeoTrust really did sign the server's certificate. To sign a certificate yourself, you need the private key, which is only known to GeoTrust. This way an attacker cannot sign a certificate himself and incorrectly claim to be Google.com. When the certificate has been modified by even one bit, the sign will be incorrect and the client will reject it.
So if I know the public key, the server can prove its identity?
Yes. Typically, the public key encrypts and the private key decrypts. Encrypt a message with the server's public key, send it, and if the server can repeat back the original message, it just proved that it got the private key without revealing the key.
This is why it is so important to be able to trust the public key: anyone can generate a private/public key pair, also an attacker. You don't want to end up using the public key of an attacker!
If one of the CAs that you trust is compromised, an attacker can use the stolen private key to sign a certificate for any website they like. When the attacker can send a forged certificate to your client, signed by himself with the private key from a CA that you trust, your client doesn't know that the public key is a forged one, signed with a stolen private key.
But a CA can make me trust any server they want!
Yes, and that is where the trust comes in. You have to trust the CA not to make certificates as they please. When organizations like Microsoft, Apple, and Mozilla trust a CA though, the CA must have audits; another organization checks on them periodically to make sure everything is still running according to the rules.
Issuing a certificate is done if, and only if, the registrant can prove they own the domain that the certificate is issued for.
What is this MAC for message authentication?
Every message is signed with a so-called Message Authentication Code, or MAC for short. If we agree on a key and hashing cipher, you can verify that my message comes from me, and I can verify that your message comes from you.
For example with the key "correct horse battery staple" and the message "example", I can compute the MAC "58393". When I send this message with the MAC to you (you already know the key), you can perform the same computation and match up the computed MAC with the MAC that I sent.
An attacker can modify the message but does not know the key. He cannot compute the correct MAC, and you will know the message is not authentic.
By including a sequence number when computing the MAC, you can eliminate replay attacks. SSL does this.
You said the client sends a key, which is then used to setup symmetric encryption. What prevents an attacker from using it?
The server's public key does. Since we have verified that the public key really belongs to the server and no one else, we can encrypt the key using the public key. When the server receives this, he can decrypt it with the private key. When anyone else receives it, they cannot decrypt it.
This is also why key size matters: The larger the public and private key, the harder it is to crack the key that the client sends to the server.
How to crack SSL
In summary:

Try if the user ignores certificate warnings;
The application may load data from an unencrypted channel (e.g. HTTP), which can be tampered with;
An unprotected login page that submits to HTTPS may be modified so that it submits to HTTP;
Unpatched applications may be vulnerable for exploits like BEAST and CRIME;
Resort to other methods such as a physical attack;
Exploit side channels like message length and the time taken to form the message;
Wait for quantum attacks.

See also: A scheme with many attack vectors against SSL by Ivan Ristic (png)
In detail:
There is no simple and straight-forward way; SSL is secure when done correctly. An attacker can try if the user ignores certificate warnings though, which would break the security instantly. When a user does this, the attacker doesn't need a private key from a CA to forge a certificate, he merely has to send a certificate of his own.
Another way would be by a flaw in the application (server- or client-side). An easy example is in websites: if one of the resources used by the website (such as an image or a script) is loaded over HTTP, the confidentiality cannot be guaranteed anymore. Even though browsers do not send the HTTP Referer header when requesting non-secure resources from a secure page (source), it is still possible for someone eavesdropping on traffic to guess where you're visiting from; for example, if they know images X, Y, and Z are used on one page, they can guess you are visiting that page when they see your browser request those three images at once. Additionally, when loading Javascript, the entire page can be compromised. An attacker can execute any script on the page, modifying for example to whom the bank transaction will go.
When this happens (a resource being loaded over HTTP), the browser gives a mixed-content warning: Chrome, Firefox, Internet Explorer 9
Another trick for HTTP is when the login page is not secured, and it submits to an https page. "Great," the developer probably thought, "now I save server load and the password is still sent encrypted!" The problem is sslstrip, a tool that modifies the insecure login page so that it submits somewhere so that the attacker can read it.
There have also been various attacks in the past few years, such as the TLS renegotiation vulnerability, sslsniff, BEAST, and very recently, CRIME. All common browsers are protected against all of these attacks though, so these vulnerabilities are no risk if you are running an up-to-date browser.
Last but not least, you can resort to other methods to obtain the info that SSL denies you to obtain. If you can already see and tamper with the user's connection, it might not be that hard to replace one of his/her .exe downloads with a keylogger, or simply to physically attack that person. Cryptography may be rather secure, but humans and human error is still a weak factor. According to this paper by Verizon, 10% of the data breaches involved physical attacks (see page 3), so it's certainly something to keep in mind.


What stops an attacker from tampering with data sent during the SSL/TLS handshake?

The cornerstone of the security against such tampering lies in the Finished messages. At the end of the handshake, client and server send to each other these messages, whose contents are a hash of the contents of all previously exchanged handshake messages. If an attacker alters anything in one of these messages, then the handshake messages, as seen by the client, won't match what the server saw, and the Finished message contents will differ. The attacker cannot reliably alter the contents of the Finished messages on the fly because they are sent after the switch to the newly negotiated cryptographic algorithm -- so they are encrypted and protected against alterations.

The only way for the attacker to pull off such an attack would be to force the client and server to use a cipher suite that is so weak that the attacker can totally break it right away, and thus alter the Finished messages to match his previous alterations. But decent SSL implementation don't support cipher suites which are that weak (there used to be "export cipher suites" limited to 40-bit keys, but they are no longer supported by existing libraries).

For more on SSL, read this.


How to prevent a prophecy from becoming self-fulfilling or self-defeating

Encrypt your "prophecy" with PGP using a new keypair. Publish your encrypted prophecy on the internet for everyone to download. Make sure people share it, so they won't accuse you of creating a hundred files with every possible scenario and then making all but one of them disappear before you go public (like this guy). After your prophecy became true, publish the key to decrypt it.

Someone who did this for other reasons is Wikileaks and their "Insurance Files". This is a bunch of large, encrypted files. There is no statement what they actually contain. Wikileaks threatens the US government that should something happen to them, the decryption key will be released. They might be bluffing and it's just garbage. It might be just a PR gag. But who knows?

Possible weakness of this method: People might accuse you that you secretly gave your unencrypted prophecy to the decision makers and they did it just because they knew about it. Unfortunately there is nothing you can do to disprove this, because one can not prove that one does not possess a certain information (a dilemma faced by any person in world history who ever got tortured for information they didn't actually knew).


Secure file deletion vs wiping free space

There is a possibility, that after deleting specific file and before wiping all disk, freed sectors will be assigned to some other file.

So it will be more secure to wipe a specific file. And then I suggest to wipe all disk in case there were any temporary copies of this file, created by eg. some editor.

Also note that on SSD drives it's not enough to wipe a file, since drive controller can write new data in another sectors or even memory chips, to extend drive life. You can google for TRIM keyword to get more details about this behaviour.


Can "Accept cookie" button in a website be malicious?

Technically, browsers do not have to ask the user a question in order to use cookies. Furthermore, they are not technically bound to the answer given by the user.

Legally, that is another matter. In the European Union, the websites are now required to ask the user for their consent before using tracking cookies or other means to collect personal data about the user. However, they do not have to ask for the consent of the user to use cookies necessary to provide their service (such as session cookies). Thus, if websites asks to allow cookies, it is in order to legally collect personal data about the user. This data can be considered private or sensitive, depending on the appreciation of the users.

The formulation “For better browsing experience” usually means “In order for us to provide you targeted advertisement, that will earn us more money to make better content.” or “In order for us to provide you targeted advertisement, so you will have (in theory) less irrelevant advertisements”.

A malicious website might not honor their legal obligations. They could ask for the consent and not honor the answer, or they could dispense with asking the question in the first place.

For more information on the law: GDPR on Wikipedia


Restrict access to a specific type of entity

Client SSL certificate authentication would be something you could consider. Instead of providing credentials, your server will request you to provide a certificate (which you can embed in your application).

A small overview I took from Wikipedia:

  The following full example shows a client being authenticated (in
  addition to the server like above) via TLS using certificates
  exchanged between both peers.

  Negotiation Phase:

  A client sends a ClientHello message specifying the highest TLS    protocol version it supports, a random number, a list of suggested
  cipher suites and compression methods.
  The server responds with a ServerHello message, containing the chosen    protocol version, a random number, cipher suite and
  compression    method from the choices offered by the client. The
  server may also    send a session id as part of the message to perform
  a resumed    handshake.
  The server sends its Certificate message (depending on the selected    cipher suite, this may be omitted by the server).
  The server requests a certificate from the client, so that the    connection can be mutually authenticated, using a CertificateRequest
  message.
  The server sends a ServerHelloDone message, indicating it is done    with handshake negotiation.
  The client responds with a Certificate message, which contains the    client's certificate.
  The client sends a ClientKeyExchange message, which may contain a    PreMasterSecret, public key, or nothing. (Again, this depends on the
  selected cipher.) This PreMasterSecret is encrypted using the public
  key of the server certificate.
  The client sends a CertificateVerify message, which is a signature    over the previous handshake messages using the client's certificate's
  private key. This signature can be verified by using the client's
  certificate's public key. This lets the server know that the client
  has access to the private key of the certificate and thus owns the
  certificate. The client and server then use the random numbers and
  PreMasterSecret to compute a common secret, called the "master
  secret". All other key data for this connection is derived from this
  master secret (and the client- and server-generated random values),
  which is passed through a carefully designed pseudorandom function.
  The client now sends a ChangeCipherSpec record, essentially telling    the server, "Everything I tell you from now on will be authenticated
  (and encrypted if encryption was negotiated). " The ChangeCipherSpec
  is itself a record-level protocol and has type 20 and not 22.
  Finally, the client sends an encrypted Finished message, containing a
  hash and MAC over the previous handshake messages.
  The server will attempt to decrypt the client's Finished message and    verify the hash and MAC. If the decryption or verification
  fails, the    handshake is considered to have failed and the
  connection should be    torn down.
  Finally, the server sends a ChangeCipherSpec, telling the client,    "Everything I tell you from now on will be authenticated (and
  encrypted if encryption was negotiated). " The server sends its own
  encrypted Finished message.
  The client performs the same decryption and verification.

  Application phase:

  At this point, the "handshake" is complete and the application    protocol is enabled, with content type of 23. Application messages
  exchanged between client and server will also be encrypted exactly
  like in their Finished message.


How do you properly setup Tor on Windows 7?

You should be able to to that with the Windows Firewall "with advanced functionality" (something like that), as this firewall knows about local processes: you can make per-program rules (a "program" here is actually just a file name, as for example C:\Window\explorer.exe).

So you should be able to:

block all outgoing packets (for all protocols, not just TCP or UDP)
allow everything only for the Tor program, defined by its file name (often C:\Program Files\Vidalia Bundle\Tor\tor.exe). For a working Tor relay, you must allow both outgoing (active open) and incoming (passive open) TCP connexions.
A Tor exit node needs to do DNS resolution. You might need to unblock the Windows DNS resolver if it is a standalone process - or is the resolution done by each program?

Note:

I have not tested this configuration.
Before changing any firewall rule, make sure you understand Windows firewall UI and what the rule means.
Before making a block all rule, make sure you know how to reset the firewall to normal state (without turning it off, unless it is usually off).
With Windows you can have different "profiles" with different firewall configurations. Make sure Windows 7 does not automatically change active profile without user confirmation (as Windows Vista sometimes does).


What happens if an attacker steals my phone's IMEI number?

IMHO the IMEI is a device identifier (International Mobile Station Equipment Identity). You can retrieve it from any device by dialling *#06#. So it´s not a real secret, and anyone borrowing your phone for a short moment can get hold of it. The IMEI is bound to the device, not your phone number or account. It could be used to track stolen phones, and to lock them out from networks (done in a few countries, but not across borders or carriers normally, they could not agree on a global DB). However, some phones apparently allow changing the IMEI, which is of course a bad idea (why hardware vendors allow such things BTW, is it too hard to burn in a number of bytes and then make them read-only?) and people could overwrite it easily.

If WhatsApp would use the IMEI for personal identity I could not change my phone anymore, if my old one breaks. The whole idea of GSM was and is that you are not bound to the phone, rather you are just bound to the SIM card, and that is what needs to be protected. The SIM is your key to your telephone number, that´s the reason why you got a PIN code and why it locks you out after 3 failed attempts...

I don´t believe there is any identity theft possible by knowing telephone number and IMEI. You need to get hold of the SIM card, somehow hack it and retrieve the IMSI. This is what identifies you against the mobile provider. Read this: https://www.quora.com/What-is-the-difference-between-ICCID-IMSI-and-IMEI-numbers

Even your telephone number does not need to be stored on the SIM. For example, my private datacard-only SIM displays an invalid phone number when asked, but on my invoice I can see a real one, which even accepts SMS.


What was so dangerous about PGP that its creator was charged in court for it?

PGP was considered dangerous because it could have allowed Soviet spies and military officers to plan the nuclear annihilation of the western world without the CIA realizing what's happening before it's too late.

Time for some history.

During World War II, the importance of cryptography for military use became apparent. Being able to crack enemy cryptography while also having cryptography systems for oneself which can not be cracked, proved to be an important military factor which could result in victory or defeat.

During the subsequent universal arms-race during the cold war, all sides were aware of this. Having the upper hand in cryptographic technology over the other side was considered a strategical factor which could turn the tide in another world-war. That meant that any knowledge-transfer of cryptography know-how from the Western to the Eastern world had to be prevented.

As a result of this doctrine, cryptographic technology was considered of military value and thus filed under Category XIII in the United States Munitions List. That meant any data storage medium which contained cryptographic software was legally considered like live ammunition when it came to moving it across borders.

From today's point of view it might seem absurd to try to contain knowledge through export restrictions designed for physical goods, but it fitted into the isolationist viewpoint of the military strategists of the cold war era. Also remember that this was the 70s, long before the internet age. This was decades before the time where you were able to obtain any software in the world via the internet through your favorite piracy website. Getting a piece of software from computer A to computer B usually meant to put it on a physical medium like a floppy disk, magnetic tape or (even earlier) punch-cards, and the movement of such physical media across borders seemed controllable (at least in theory).

Technology marched on. In the 80s, the first international computer networks emerged, and the hacker community began to flourish. The world became increasingly interconnected and soon it became apparent that containing knowledge within geographical borders was an exercise in futility. But as usual, politics and laws didn't keep up with technical innovation, so when PGP emerged in the 90s, it was still subject to cold war era laws regarding cryptography exporting. The algorithms it used were open secrets, available to anyone in the world capable of buying a modem and making long-distance phone calls. Hackers were tattooing them on their bodies to ridicule the cryptography export restrictions. But as a commercial company, PGP had to play along and find a loophole in the form of exporting their source code in printed form and re-transcribe it.

Although the restrictions on cryptographic technology have been relaxed in the past decades, some of them are still in place.


Is it possible to detect IDS name and version

Network IDS's tend to run passively, so they don't respond to network traffic: they just listen.

No way to get it to respond in such a way as to determine that it is running, what kind, or what version. You'd need to go a different route to glean that info.


Using Patator ssh_login module how can I get the output to show only on success

Is there a reason you're tied to patator? It looked like the --allow-ignore-failures may help but I just ran it and it didn't suppress failed attempts. I would use hydra as it's a lot simpler. This should work for you:

hydra -l <user> -P <password-list-file> ssh://target

(Hydra was quick answer -- hopefully I can play around with patator later and give an answer for that too...)


How can a PHP file be added over and over to my hacked site?

You might have some backdoor in the database as inline HTML or Javascript.

If you are sure that you have removed everything from the files, look into the database.

Also, make sure you upgrade both CMSes to latest versions and disable / remove all unused modules in both so that they won't hack you again in the same way.

Also look in the WWW server access and error logs if someone is really bombing you.


cross-site scripting vulnerability is handled and fixed in the code, will it mitigate cross-site forgery attack also?

In a CSRF attack the attacker from site A can use the browser of user U as a trampoline to trigger an authenticated request against site against site B, provided that user U is already authenticated against site B and B has no CSRF protection.

One example would be to include an image on site A like this:

 <img src=http://site-B/unwanted_action?some_parameters>

When including the image a request will be sent against site B which includes existing cookies and basic authentication information the user U has inside the browser for site B. Thus the request looks authenticated and site B will execute if no CSRF protection is in place. Thus all what is needed for the attack is that user U visits site A, either knowingly because the attacker might embed such a link into a public forum site, or unknowingly because such link is embedded into an advertisement. And since this is an image no action need to be done by the user and he will probably not even realize that something bad happened, like in How millions of DSL modems were hacked in Brazil, to pay for Rio prostitutes.

Given the above example it should be clear that no XSS is needed to execute a CSRF and that neither TLS nor protection of the session cookie against tampering will help against CSRF.


how can my bank have a wrong phone number entered with my personal account information?

Most probably, there was some human error upon entry, probably by an anonymous operator at the bank. If the number is also on a Web site associated with your wife's name, then the most plausible explanation is that the bank sold some of your personal information to third parties, as they are prone to do. Have you ever wondered how all the people who call you in the evening to sell you new windows, subscriptions to magazines, or eternal salvation, obtain your name and phone number ? Well, wonder no more: they simply buy personal information from companies and other institutions who have it. Information from banks will be especially well appreciated on that market, because it can come with some annotations such as "tends to use credit cards a lot" or "filthy rich".

Whether banks (and other institutions) are morally allowed to sell your information is an open debate; but legally speaking banks tend to be well-covered.

In the case of your wife, the error on the phone number should be fixed because, unfortunately, some banks use the phone number as an identification element. But as soon as the number is fixed, this particular vulnerability is removed (at least as much removed as it can be). Otherwise, look at your bank accounts to see if anything weird occurred; if nothing is wrong, then you can cease to worry.


tldr: The approach you outline fails do address the actual problem, use a separate application and a secure authentication scheme.

While you are right that keeping account credential information with the rest of the lot (i.e. whatever your application actually uses when it's not authenticating users) is a bad idea (tm), the approach to just have a second database falls short to solve this problem and here's why:

The threat you are trying to mitigate is either:

compromise of the database or
compromise of the application

If (1), depending on what information is inside the database and how it's used (i.e. what the trust level of the application regarding the db is), I am quite confident that (2) will be possible to achieve.

If (2), having a separate database your application connects to will be useless at this point; the attacker has access to the applications credentials and thus access to both databases and can dump and use them, effectively as if they were a single database.

So, from that point of view, your proposed sollution seems like overkill because the cost outweighs the benefits. Yet, there are viable ways to doing this:

Authentication is petty known task for applications to do. This is the reason software exists that takes care of only that task.

The idea would be to have an abstracted web service (or the like) that only processes authentication and responds with a token that the actual application accepts (because it trusts the service to authenticate users, that's it's job).

One example of such a scheme would be OAuth2; you have one service for authentication and another one to serve your actual business needs. Hence you can abstract from sensitive data where you do not need it, only using the user handle your authentication platform provides.

This is independent of using multi factor or not, by the way; even if you're just using username/password auth, you gain benefits (for example, you do not leak all your customers credentials when the application gets exploited).


exploiting CSRF in ajax request via XSS flaw

Yes,it will work. The CORS header will avoid external requests from perform actions(eg. a malicious link received by email and clicked by the user).

If you combine a stored XSS flaw and perform a request on the page load to execute some action,it will certainly work. The request comes from the application domain,so the application/browser will have no way to distinguish this request from a forged request.

The OWASP guide provides more information,take a look.

EDIT: I see now your edit. Let's see if I understand what you're trying to do.

Scenario: You have a non-sanitized input, which let you explore the XSS flaw. You put some dirty javascript to perform a action,like alerts or logs,and it works every time that the page is loaded. Fine.

On next step,you have elaborated a XHR to the same application domain,from the application domain. Are you still getting a CORS error?


Hardening Web Browsers - Detailed Guidance

Check out:

ISAE's Application Security - Browser Guidance

  The STIGs contain technical guidance to "lock down" information systems/software that might otherwise be vulnerable to a malicious computer attack.


OAuth implicit flow and confused deputy problem

I believe that the following example demonstrates the problem (based on the accepted answer from https://stackoverflow.com/questions/17241771/how-and-why-is-google-oauth-token-validation-performed)

All of this assumes the use of the OAuth Implicit Flow

Alice connects her browser to GoodApp.com
GoodApp.com obtains an OAuth access token authorized by Alice.

A) This access token is tied to Alice’s identity at the Authorization Server.

B) The access token is either used by GoodApp.com to authenticate Alice or to access
   some OAuth resource on behalf of Alice.
Alice connects her browser to BadApp.com (for whatever reason; let’s say that BadApp.com
"offers games that look kind of fun")
BadApp.com obtains an OAuth access token authorized by Alice.
BadGuy (who controls BadApp.com) then connect’s his browser to BadApp.com, and gets
BadApp.com to redirect BadGuy’s browser to GoodApp.com with a spoofed OAuth
authorization response that includes the access token that BadApp.com has for Alice.
If GoodApp.com accepts the spoofed response, then BadGuy can act as Alice as follows.

A) If the access token is used by GoodApp.com to authenticate Alice, then BadGuy can do
   anything Alice could do at GoodApp.com

B) If the access token is used by GoodApp.com to access some OAuth resource, then BadGuy
   can cause GoodApp.com to do anything within the “scope” of the access token, all on
   behalf of Alice.

Therefore, if GoodApp.com verifies that any received access token was indeed intended for itself, then it can avoid the bad things as described in the example above.

Note that I believe an OAuth Client's proper use of the "state" parameter for cross site request forgery can also mitigate this problem, independently from access token validation.


parsing the id-ce-keyUsage extension in X.509 certs

In ASN.1, there are two distinct types which are designated by BIT STRING.

If you have this:

Foo ::= BIT STRING

then Foo is a type for a generic string of bits, with an arbitrary length, and arbitrary values for each bit.

On the other hand, with this:

Bar ::= BIT STRING {
    x  (0),
    y  (1),
    z  (2)
}

then Bar is a type for a set of flags, and DER encoding rules state that these should be encoded as if it was a generic BIT STRING, but stopping at the last non-zero bit. Thus, if you want to encode a value of type Bar with the flags x and y set, but not z, then the encoding must be a BIT STRING of length exactly two bits, not three or more. That's what DER mandates; the generic BER rules allow for adding as many extra bits of value zero that you wish. Upon decoding, flags which are beyond the encoded code length are assumed to be cleared.

So, for your BIT STRING: 03 02 01 06 decodes as such:

03: a BIT STRING.
02: the value consists in the next two bytes.
01: first value byte; for a BIT STRING, it means that you shall ignore exactly 1 bit in the last value byte.
06: the bits themselves.

In binary, 06 is 00000110, but the first value byte says that we shall ignore the last bit, to the bytes really encode a string of exactly 7 bits: 0000011.

The last bit of that string is a 1, so this is compatible with the DER rules. When interpreting the bit string as so many individual flags, the two '1' state that flags numbered 5 and 6 are set (that's keyCertSign and cRLSign, respectively, which is typical of CA certificates), while all other flags are cleared, even if their numerical index is larger then the actual encoded bit string.

BER would allow you to encode that KeyUsage value as, for instance:

03 04 05 06 00 00

i.e. a string of 19 bits (three value bytes with bits in them, but the last 5 are ignored). This would still indicate that the keyCertSign and cRLSign flags are set, so the semantics would be identical. However, certificate contents should follow DER, which mandates encoding to the minimal length (trailing zeroes being removed).

This particularity of DER encoding is meant for compatibility with later versions: DER encoding of a set of flags depends on which flags are actually set, not on which flags could have been set -- hence, a later X.509 version could add new possible key usages, without making invalid (i.e. non-DER) certificates which use the previous version.

Really, this would have been much clearer if ASN.1 syntax had not used "BIT STRING" for two distinct purposes. The latter usage (set of flags) should have used an explicit distinct keyword, e.g. "FLAGS".


What does “PIN encrypted under LMK” mean?

In short, no, because the LMK is a single key.  The Hardware Security Module (HSM) has it's own master key called the LMK, and this is generally not dealt with in the clear.  Any keys you generate will be done so using that LMK.  The functions you mentioned are used to encrypt and decrypt to/from ciphertext from/to plaintext, both procedures of which use the LMK as a shared secret to either function.  The LMK is also a symmetric key, not asymmetric. This is a gross oversimplification, but if you would like to learn more about this, take a look at the following link:

http://jpos.org/w/index.php/HSM_basics

Hope this sets you on the right track.


AES, Serpent and Twofish are block ciphers, i.e. the basic building blocks of some cryptosystems relying on symmetric keys. AES is the standard, and there's no reason to pick anything else. All three are secure but AES has received more scrutiny to it may be considered safer. AES has better performance if your machine has hardware acceleration for it, which is the case of most high-end machines and many midrange Intel processors.

For the key size, 128 bits is fine for almost all use cases. (It's considered risky only if you want your data to resist for more than a decade.)

CBC and XTS are two block cipher mode. A mode of operation describes how the block cipher primitive is applied to data. Both CBC and XTS are fine from a security point of view. The difference is that CBC only provides confidentiality, whereas XTS provides both confidentiality and integrity. If you're only concerned about someone decrypting your data, CBC is good enough. With XTS, you'll know if someone (or something) corrupts the data on your disk: you'll get an error message instead of garbage data. Integrity verification is only useful if someone can modify your data, but you still trust the hardware afterwards, which is rarely the case. With XTS, there are two keys, which is why the key size figures are double those for CBC. aes-xts   256b uses two AES-128 keys, etc.

Finally PBKDF2 is a key stretching function, i.e. a way to compute a key from a password that slows down brute-force attempts. The second part is a hash function. PBKDF2 is actually a famility of key stretching functions: each choice of hash defines a choice of PBKDF2 mode. Here, all choices are ok, but SHA-1 is deprecated. Pick SHA-256 or SHA-512: they're the standard choice. Performance-wise, SHA-256 has a slight edge on 32-bit machines, SHA-512 on 64-bit machines. SHA-1 is deprecated (though not yet known to be broken, especially for in a key stretching context). SHA-256 or SHA-512 are fine.

Summary: pick PBKDF2-sha256 and aes-cbc unless you have a good reason.


Windows: Any method to enforce user confirmation before the browser opens a URL requested by an external desktop app?

Another solution is to build or modify a existing browser, to not allow any type of external URL typing. You could even have it to use a screen keyboard or such to prevent malicious programs from using SendKeys(); and you could have scrambling screen keyboard and much other security features, And user confirmation if the browser is called externally with a URL as argument. Then you simply only approve this browser in your firewall.


Resellers and web admins and email privacy

If you ask some company to create some domain for you and several e-mail account with that domain and forward that information to your gmail account...I do not really understand, ANY web developer can check all mails from any client, or Am I missing someting?

In a way your question is funny: you fear that the domain provider might intercept and read your mail when it gets forwarded to your gmail account but you don't fear that somebody is reading the mail at the forwarded account itself, i.e. the mails which are stored at google's servers outside of your control. The mail can be read in both cases and it will at least be done if these providers get a warrant because law enforcement needs to get access to information in thus mails.

If you make decisions to give somebody else such level of control over your data you have to ask yourself how much you trust this company. This is the same question you have to ask yourself with your telecom provider, because both land lines and mobile calls can be intercepted by the provider and this will be done if law enforcement requires it. And the same is true with your internet access.

Thus in your specific case you need to trust google to not read your mails or at least don't use any information in these mails against you. And you have to trust your domain provider to not read the mails when forwarding and also to set up the interface for forwarding in a way which can not be hacked by someone - because then the mail could get just be intercepted some yet another party. And there is probably more trust involved.

  How do you forbids that the developer company/reseller can check all your mails?

The only way to be sure that no third party is reading your mails is to encrypt them. This does not mean TLS which does only hop-by-hop encryption between mail servers but the mail is available in plain text at the mail server itself. Instead you need to use end-to-end encryption like PGP or S/MIME. But of course end-to-end only works if sender and recipient use this kind of encryption. And meta data like sender, recipient, time and size of the mail are still visible even if the mail content itself is encrypted.


What is the security purpose behind the "enable editing" of MS Word?

Well macro's would allow you to automatically start running scripts on the machine once the document was opened. Hence they get opened in a protected mode to prevent code execution from happening automatically (the user needs to aprove it explicitly).

Also from the MS website:

  Files from the Internet and from other potentially unsafe locations
  can contain viruses, worms, or other kinds of malware that can harm
  your computer. To help protect your computer, files from these
  potentially unsafe locations are opened in Protected View. By using
  Protected View, you can read a file and see its contents while
  reducing the risks.


Using HTTPS with localhost in production environment

Yes, because localhost traffic doesn't go over the network. There's a special loop back adapter in operating systems that handle requests to 127.0.0.1. Using TLS on localhost would simply add an extra layer of encryption on memory that doesn't ever leave the box.


Is this exploit on household appliances really as bad as it sounds?

Is it possible?  Yes.  Varying the electromagnetic noise of a device's circuits to transmit data has been used both in and out of laboratory settings.  (For example, somebody figured out how to modulate the Raspberry Pi's GPIO pins to turn it into an FM radio transmitter, with the side effect of trashing a wide band of the radio spectrum.)

Is it practical?  No.  Even the Pi, with its relatively high-powered unshielded electronics, didn't have a range of more than a hundred meters or so.


SMB/CIFS shares on HP-UX vulnerabilities

Make sure you are using the correct account for accessing the NULL share. This could be nobody or smbnull. (Check your smb.conf file.)

C:\> net use \\hostname\backup "" /USER:nobody

C:\> net use \\hostname\backup "" /USER:smbnull

Also try the backup share instead of IPC$ with your empty user:

C:\> net use \\hostname\backup "" /USER:""

  Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers?).

Yes, it will fix it for unauthenticated attackers. To fix it for all users, you should set wide links to no.


The difference between a httponly cookie and a non-httponly cookie is that the latter cannot be read or modified using JavaScript in the context of the website.

Having no XSS vulnerabilities implies that you cannot execute JavaScript in the context of the website you're attacking. Therefore, this solution is safe.


Allow only single aplication to access files on USB stick with Linux namespaces

Yes, other processes owned by the same user can access the files via /proc/<PID>/root.

This can be prevented by root creating a user namespace, mapping the unprivileged user, then switching to the user. These steps need to preformed by a single executable.


Can you construct a non-lossy steganographic filesystem

is it possible to implement a system with plausible denyability that is at least as strong as accepted cryptographic primitives (AES-CBC, SHA1-HMAC, e.t.c.) yet is not a lossy filesystem?

Yes, in a way. TrueCrypt and it's successor VeraCrypt support hidden volumes. They work by embedding a hidden encrypted container inside an encrypted container. You can protect the "inner" or "hidden" volume from being partly overwritten if you have access to it. But see Mark's comment for a gotcha. There are more; the TrueCrypt manual explains some of them.

This goes for StegFS, too. StegFS is only lossy if you don't provide it with the passwords to all the security levels you're using.

So you can easily construct a steganographic filesystem which doesn't lose your files - but in order for the filesystem to not overwrite them, it needs to know where they are, and this can only be achieved if you tell it the necessary passwords/passphrases before starting to work on the file system.

Have your cake and eat it, too

This is from your question in the comments:

  Basically my biggest question was whether you can derive the place to store the file given the password, and somehow there would be a function that would allow you to find a free spot, yet would not reveal used spots

Again, if you provide the system with all the relevant passwords, this is easy. A very simple way to come up with stable disk storage locations based on passwords is by using hash functions - hash a password, or any other combination of identifiers, and get a stable number, which you can use as a pointer to a disk storage block.

If you DON'T want to provide all the relevant passwords, then it becomes much, much harder, and file system efficiency will suffer greatly.

First, you'll have to agree on an important point: The file system storage space is limited. If you have, say, 1 TB of space, and you have 1 GB of hidden files stored in it, then no matter how good the system is, if you write 1 TB of files to the disk, your hidden files will get overwritten. This is impossible to avoid.

But there may be methods to make sure that the files only start to get overwritten after you copied the first 999 GB to the disk.

Consider the following block allocation scheme:Whenever your file system requests a free storage block, a counter gets incremented and the counter determines which block to allocate. This means that you won't ever allocate a block that's already used as long as there still are free blocks on the disk. So you don't need to worry about overwriting hidden files as long as there is still free space on the disk.

The idea comes with a number of problems. For example, in the presented form, this doesn't work so good because you can immediately see how many blocks were allocated. Then you could count the number of blocks currently assigned to visible files and if that differed greatly from what you came up with, you could infer that there are lots of blocks assigned to hidden files. The other explanation would be that these were blocks of files you had deleted, but that's another problem with this system: There's no easy way to claim blocks of deleted files - if you want to reclaim the space of deleted files, you'd have to run special defragmenter software that reorganized all the data on disk.

There's another idea that might work a little bit better: You can have the block allocator for visible files allocate free blocks by allocating blocks 1, 3, 5, 7, 9, ..., and eventually coming back in reverse to claim the even blocks ..., 10, 8, 6, 4, 2.

Then you could have the allocator of the first hidden level allocate blocks starting at 2, 6, 10, 14, ...

Then you could have the allocator for the second hidden level allocate blocks starting at 4, 12, 20, ...

and so on. Each level L would provide 1/2^L of the total available space before starting to mess with data stored in other levels. Depending on how much data you stored on the various levels, level 1 could get away with storing more than 50% of data before starting to overwrite data in all the other levels.

(BTW: This would have a side effect: In this system, if you wanted or needed to, you could prove that there were no more hidden levels beyond the last one by storing twice the number of blocks that were actually assigned to it in it. This would overwrite the data of all the lower hidden levels. E.g. If you wanted to prove that there were no more hidden levels beyond the first hidden level on a 1 TB disk, you'd just have to store 500 GB of data in it, and if you used the file system without any hidden levels, you could store the full 1 TB)

But does plausible deniability work in real life?

I'm very sceptical about whether plausible deniability works in real life (generally, not just with TrueCrypt/VeraCrypt/StegFS).

I imagine two cases in which you might be forced to give up your encryption keys / passphrases:

You're legally obligated to give them up because law enforcement in your country has the right to request them, and a judge can hold you in contempt if you don't give them up
You're facing some criminal who is willing to torture the keys out of you.

In both cases, I fail to see how saying "there really aren't any hidden files on my computer besides the ones I showed you" makes a practical difference from "I don't remember the password for the encrypted file you see right here, but I remember it is last year's tax return statement."

Both law enforcement and the criminal probably won't believe you either way (there is a reason why they're talking to you! they expect you to have some specific documents they haven't found yet, after all), and they'll use whatever methods they have at their disposal to make you give up the key/passphrase. You're better off with law enforcement, of course, because the methods they can use are much more limited in civilized states.

Just think about what it tells an attacker about you if you use StegFS: It means you're trying to hide files. So how many files do you have to reveal before you can plausibly explain there is nothing more to reveal? This might actually work against you: You can't plausibly show that you've revealed all your hidden files, so a court in a country where the law allows for it might hold you in contempt indefinitely because you can't prove your innocence...

If you do live in a country where a court has to prove your guilt instead, then what would most likely happen is that the police confiscated all your drives and sent them to be analysed by a forensic unit to see if they could find a way around your denials. They probably wouldn't be discussing your steganographic file system with you in order to find out how plausible it was that you kept hidden data on it. So in that case, again, it wouldn't matter whether you used a steganographic file system or simply encrypted your data.

Plausible deniability through steganography is a nice idea, but I seriously doubt it works in practice. https://xkcd.com/538/ is somewhat related to this - the real world doesn't always conform to what we're imagining it to work like.


This isn't really a security question, it's a low-level architecture one. But to get you started, I'd suggest looking in to what a Segmentation Fault actually represents.

Specifically, it happens on an attempt to read or write on a memory address to which the process does not access. The act of copying one register to another does not access memory, so it shouldn't be capable of triggering a segfault. Make sure you're actually performing the operation you think you are. Make sure that the issue isn't actually the previous or next instruction. Finally, another option is look at the location in memory of the EIP. It's probably not the problem, but it may be worth checking what memory is accessed as a side-effect of what's going on.


Best Security measures for non-IT pro to take when at risk of hackers?

Sounds like you need to do a bit more to reduce your attack surface. While you have already done a lot of things to improve your situation which is good, unfortunately you have absolutely no control of your physical network which is generally the source of most hacking attempts. This is compounded even further by the fact that that it is a shared network and you have no idea what is happening on that network. For all you know, someone sitting a few desks down could be Wiresharking (eavesdropping) all your network traffic.

So with that said and assuming you are not experiencing any problems on your home network, here are a few steps I would advise you to take to start with.

First off, back up all your data and personal files, VERY IMPORTANT to do this properly as you don't want to lose any data.
Do a fresh install of Windows 10. This is an important step because it may well be that you have some form of malware on your machine that you don't know of and your AV is not detecting it.
After doing a clean install of Windows, install the latest updates and drivers for your PC and then try using Bitdefender Total Security. Norton 360 has a very low detection score and I would strongly advise against using it. The firewall on your PC is the very last line of defense against hackers and malware/spyware/ransomware etc. You want to make sure you have the best level of protection available to you.
After installing your AV, go to your network adapter settings and change your DNS to 1.1.1.1 (Cloudflare) or 9.9.9.9 (Quad9). If you don't know how to do this, Google is your friend.
Download and run Shutup10 or something similar. It reduces Microsoft bloatware and improves the security on your PC by disabling a number of hacker friendly breach points.
Since you use Chrome, you should then install a few security extensions on it. The most popular ones are:

Cookie Autodelete
UBlock Origin
HTTPS Everywhere (EFF)
Privacy Badger (EFF)

Disable anything you can that involves IoT connections. Try not to use them at all. If you do have to use something over WiFi or Bluetooth, disable the adapters straight away after using them.
Grab an external USB drive, encrypt it with a strong password, and then install an offline password manager like KeePassX on it for all your passwords. It is a bit tedious to start with but once you have everything in it, it is very easy to manage and maintain. Then, when you need to provide usernames, passwords or anything sensitive, you will simply right-click, copy-paste them into the appropriate places when working online. Once this is done, get rid of all your Google passwords and turn all that kind of stuff off.
Add two step authentication for all your online accounts. If you use a mobile phone, grab something like FreeOTP and use it for everything you can.
Keep using your commercial VPN to connect to the outside world when you are in the WeShare office. Most VPN provider's also have an extension available for your web browser. If so, grab it and use it as well.
If you are interested in going down the path of setting up your own router, then grab something that has the capability of installing third party firewall firmware like DD-WRT, OpenWRT, or Tomato. If you are really keen, you could go all out and setup a PFsense box!

There are many other things that can be added to this list but this is a solid starting point.


You need to supply the proxy switch when using curl:

$ curl --proxy [PROTOCOL://]HOST[:PORT]

For system wide proxy usage:

System preferences -> Network -> Proxies

Please be aware that using Tor as a system wide proxy will most likely identify you as a person and is not a good idea if you want to be anonymous.

When for example you start your email client, it is known that you're using Tor by the end point (possibly your ISP or worse: GMail)


Can TLS provide integrity/authentication without confidentiality

There are a couple of cipher suites that provide integrity and server authentication but no encryption (e.g. TLS_RSA_WITH_NULL_SHA256). However, no browser supports them, precisely because they do not offer encryption, thus requiring some sort of user interface to let the user decide whether the site he wants to reach requires encryption or not. From a usability point of view, this would be inconvenient; also, users are notoriously bad at making informed security decisions.

For these reasons, browsers only support cipher suites with strong encryption. This is not a problem in practice, because the computational cost of encryption in that context is mostly negligible (even an anemic smartphone can encrypt data ten times faster than it can download it).


All the answers we could get would end up being guesswork of what could have been, since we don't have access to any of the server logs. This is not helpful to anyone.
What you should be doing now is to  contact a company doing incident response and forensics and have them figure out how it happened. In other words: It's time to call a professional.
Sure, it will be expensive, but most likely less expensive than yet another breach.

Full Disclosure: I work for a company which offers incident response and forensics. I offer you to contact professionals because it's good advice, not because I have any personal gain from it.


Can hackers compromise a VM to the point that they compromise your host OS?

There are cases where a VM can escape (to one degree or another) the virtualization environment and manipulate data outside of what it should be able to. This can mean that one guest VM can get code executed on a different guest, or even within the host OS itself.

These vulnerabilities are typically referred to as 'escape bugs', wikipedia has a list for some examples: https://en.wikipedia.org/wiki/Virtual_machine_escape

Also, it is pretty easy in most cases to find out that you are on a guest VM. Virtual hardware usually identifies itself as such and you can see that in things like device manager.

Running within a VM is more secure, as a lot of virus/malware isn't going to be trying to exploit guest escape bugs (unless everyone starts running as VM, then you'll probably see an uptick), but it's not a sure thing.