Can a criminal fake the use of a PIN in a chip and pin credit card transaction?

Is it possible?  Yes.  This article from 2015 describes one way:

[T]he fraudsters were able to perform a man-in-the-middle attack by programming a second hobbyist chip called a FUN card to accept any PIN entry, and soldering that chip onto the card’s original chip. This increased the thickness of the chip from 0.4mm to 0.7mm, "making insertion into a PoS somewhat uneasy but perfectly feasible,” the researchers write.
...
The researchers explain that a typical EMV transaction involves three steps: card authentication, cardholder verification, and then transaction authorization. During a transaction using one of the altered cards, the original chip was allowed to respond with the card authentication as normal. Then, during card holder authentication, the POS system would ask for a user’s PIN, the thief would respond with any PIN, and the FUN card would step in and send the POS the code indicating that it was ok to proceed with the transaction because the PIN checked out. During the final transaction authentication phase, the FUN card would relay the transaction data between the POS and the original chip, sending the issuing bank an authorization request cryptogram which the card issuer uses to tell the POS system whether to accept the transaction or not.

Effectively, there are two things that a card reader can do with your PIN when "you" enter it - it can encrypt it and send it to your bank to verify, or it can give it to the chip (either in an encrypted or unencrypted form, but it doesn't matter here) and ask the chip whether it's correct.  By intercepting that request and replying "correct" no matter what, the reader thinks that everything is good, even if the PIN was wrong.
Since then, the methods of tricking chip-and-pin have just gotten more sophisticated.
The bank should be able to tell you whether the PIN was "verified online" (sent to them) or "verified offline" (validated by the card).  If it was online PIN, then I really have no idea how it could have happened.
Side note:
I know you don't have the receipts from these transactions, but the next time you do use your PIN, look at the receipt for something called TVR or Tag 95 or something along those lines.  It should be a ten-character string.  If the 6th character is a 4, then the PIN was sent to your bank.  (See here for the rest of it, or here for a decoder).


When viewing my website from port 3306, I see some weird MySQL info

I see two options here:

Local Access Only

Configure MySQL Server to only listen on TCP port 3306 on 127.0.0.1 (localhost). This way an internal web server can still communicate with the database server.

Directly connecting to the database is server is no longer available but can be solved by SSH tunneling (as described in mk444's answer)

This can be achieved by editing the my.cnf file. Search for "listen", most likely it is set to something like:

  listen 0.0.0.0:3306

This should be changed to:

  listen 127.0.0.1:3306

Don't forget to restart the MySQL server before changes take effect.

Restricted Remote Access

Another option is to keep the configuration the way it is and use iptables to block all incoming connections to TCP port 3306 with the exception of your (home) IP address.

Both options will work, however, from  experience I know that often iptables-persistent is not used. Meaning that if you web / database server reboots the iptables rule set gets lost and TCP port 3306 is widely open for the outside world again.


Why would home routers accept incoming DNS traffic?

SoHo routers generally provide IP masquerading (NAT). This means that they need to provide a DHCP service and (because DNS uses UDP, and hence cannot be used across IP masquerading) also need to provide a DNS server.

(OK that's a simplification, and these are requirements arising primarily from usability which could be solved by more elaborate technical solutions - but end-users don't like technical stuff)

So given that these devices need to provide these services, the question then becomes why are these services exposed on the internet side? The short answer is that it takes additional effort to restrict the services to the inside network. While adding such a restriction to, say, a Linux or Cisco box is trivial, a lot of these devices use proprietary operating systems written without any consideraton of the security implications (hence we end up with devices containing hard-coded admin backdoors and other such horrors).

Even where adding the restriction is trivial, it still means an extra R&D cost. If you're used to configuring network devices you may scoff at this - but one step above the manufacturers you might consider simply incompetent are those who will only implement features which they have thoroughly tested - and done properly those costs can escalate rather quickly.

The great buying public are starting to become aware of security as a desirable property in computer equipment, but in the absence of an effective, cheap and well published standard for device security, they have no basis for making an informed decision about the quality of a device. Hence it's a market for lemons.

While I agree with Jeff that cost is a major factor in the chain of causality, I would not say it is the root cause of the problem here.


Connecting via SPNEGO/Kerberos out from domain

Strictly speaking, both situations are not possible because they violate the trust semantics of Kerberos.  By definition, the first scenario has a TGT into domain B and domain A doesn't trust it. Your second scenario is similar, except you may not even have a TGT because its local-only. (My statement assumes we are speaking about the use of Kerberos tickets as authentication and not a situation where you're passing plaintext credentials to a server to then present to the KDC for verification).

In both cases, the client application will not have a TGT or service ticket which is valid in domain A for the HTTP service to validate with the KDC.

That said, there is a way to do this in your second case ... but it assumes that you CAN login into domain A, even if not initially.  This is done by running your client app (Firefox, IE, etc) with a RunAs that authenticates into a network account in domain A. See the /netonly flag of runas cmd (https://technet.microsoft.com/en-us/library/cc771525.aspx).  This works by establishing another login context and runs the application as that context. Windows uses the application's user context to initialize its APIs when making Kerberos related calls and therefore will have a TGT into domain A to carry on its session.


Hotspot SSL issues, MtTM like exceptions

This question is a little convoluted, but you seem to have conflated network authentication methodologies with SSL (TLS).

WPA2/ Radius is not a proxy, so MiTM is not applicable.
SSL / TLS provides end-to-end encryption for data content. How those packets are routed in terms of WiFi is irrelevant.

Think of it this way: you have encased a letter in an 800 pound safe. You can move the safe from point A to point B using a train (ethernet) or you can do it via an airplane (WiFi).

In both cases, the mode of transportation is irrelevent to the message (the letter) it's protection (the safe) and its delivery.

Your radius server simply acts as a registry of allowed train depots and airports from which the letter in the safe can be dispatched.

If you're concerned about the "burden" of users having to remember their password to access your network, then you're going to be sadly disappointed in man-kind. It seems to be a prerequisite for users to complain about their passwords and the inconvenience of having security. Security and ease-of-use are diametrically opposed. So, you have to compromise between having great security (encasing your wifi in concrete and sinking it to the bottom of the ocean) and having usable wifi (open, unencrypted, click to connect house of internet disease).

If you're willing to front-load your efforts, you can make it "easier" to connect to your wifi by implementing radius that uses RSA or other key encryption. To the user, that's "click to connect" easy because all the authentication is done behind the scenes.

If you can't (or are unwilling) to do this, then you need to tell your users they are going to have to remember their passwords. If the users are employees, then it's their tough luck that they have to put "effort" into their job. If the users are customers, then you have to make a judgment call on how much security they are willing to put up with in order to access network resources and where your liability is. Users probably won't let you setup RSA, nor will they want to type in d892la0as9jfm10-9svnm as their password.

In either case, RADIUS does not a proxy make, and therefore, MiTM worries are baseless.


Whatsapp is adding passwords: what is the threat model that they want to protect their users from?

This would mitigate carrier breaches, rogue employees, law enforcement, etc. Mobile carriers have complete control over the user's texts, and can easily take over a Whatsapp account by trying to set up the account on another phone and intercepting the verification text. An additional authentication factor the carrier can't get access to (like e-mail or a password) prevents this.


TrueCrypt works with Linux, it just doesn't support full disk encryption by itself.

Within Linux, you can mount a TrueCrypt volume that features plausible deniability, and then simply chroot it.

Or if you feel fancy, have the volume contain a Docker image, and "Dock" it.


HMAC + AES to guarantee secrecy and integrity?

How many iterations of PBKDF2 are you using?

I don't think there is an issue with deriving the encryption and signing key from the same user-provided secret key. As you said, if the hash function is solid and you use a separate salts and enough iterations of PBKDF2 it will be secure.

Using PKCS#7 padding should be fine and if you check the HMAC prior to decryption you're not vulnerable to padding oracle attacks. I must ask though, why HMAC-MD5? While HMAC-MD5 is currently not broken because there are no practical preimage attacks against MD5, but nevertheless MD5 already failed part of it's security requirements due to it's weak Collision Resistence. So why not use a more secure hash function? Attacks on crypto only get better, not worse. I'd strongly recommend you use SHA-2 or SHA-3.


Where would I go to use a reliably secure encrypted internet connection?

Unless you've installed extra root certs, your connection to the bank's site should be encrypted (though it's not a bad idea to explicitly type https://[yourbank].com to avoid the potential for an sslstrip attack).

Even if you go to the http:// page and someone does an sslstrip attack, most modern browsers will warn you when you try to type your password on an unencrypted page. It's possible sslstrip could be combined with a redirect to a homograph domain that the attacker has a certificate for, so it would be encrypted and could potentially fool you, but all of these problems are avoided if you go to the HTTPS site and carefully check the URL before logging in.

For the average person these days, the security of the device they use for online banking is much more of a concern than the connection to the banking site. If you have malware on the device you use for online banking, there's always the possibility that it can log your username and password.


Is there a difference in terminology between the words "cryptogram" and "ciphertext"?

They're grammatically different for sure, because cryptogram is exclusively a count noun, while ciphertext can be either a count or a mass noun.

Also, I can document that the term cryptogram is sometimes used in senses where it's definitely not synonymous with ciphertext.  For example, in the v2.2 specification of the Keyak cipher (a candidate in the ongoing CAESAR competition), p. 3:

  The mode Motorist supports the authenticated encryption of sequences of messages in sessions. During a session, it processes messages and cryptograms. A message consists of a plaintext and possible associated data (called metadata in the remainder of this document).  For each message, it wraps it by enciphering the plaintext into a ciphertext and computing a tag over the full sequence of messages. A cryptogram consists of a ciphertext, possible metadata and a tag. For each cryptogram, it unwraps it by deciphering the ciphertext into a plaintext, verifying the tag, and returning the plaintext if the tag is valid. A message can also consist of metadata alone and the corresponding cryptogram does not have any ciphertext.

Clearly the authors here use ciphertext and cryptogram in different senses.  The last sentence tells us that in their usage, there is such a thing as a cryptogram without any ciphertext.

I certainly don't mean to imply that this is by any means an universally accepted usage, however.  In many fields, different authors often use slightly different definitions of the same terms.  The best advice is to always try to discern the authors' meaning in the context they use the terms, and not to try to impose some external definition they might not be heeding.

So perhaps counterintuitively, the answer is "yes" to both of your questions:

  Is there any meaningful difference between those terms? Or can they be used interchangeably?

There are many contexts, perhaps even most, where the choice between those two words doesn't matter.  And a few contexts where it does, like the Keyak specification.


Multiple "rundll32.exe mhunk.dme" instances. Is my PC Infected with Something?

Multiple copies of rundll32 running strangely named files does look like a classic malware infection to me, although as the article you linked to states there could be benign reasons, and gives steps to possibly determine what these files are. You could also use this link's suggestions to try and recover your system.

Using a malware removal tool may tell you what you've been infected with. Realistically though even if a malware removal tool seems to work you cannot be sure it's been successful - some malware is incredibly persistent and you can sink a lot of time trying to clean it off a system with no success. This is why the general advice on this site is to save your data, wipe your system, and restore your data and programs.

Also, keep your system updated in the future. The majority of malware out there uses well known security holes that have been patched for weeks or months, and uses flaws on not just the OS but Java, Adobe Flash, and such-like. So keep all your software up to date, not just Windows.


The process you are talking about is a form of passive scanning. Frankly, you don't even need Wireshark to do exactly what you want and without a database: you just need to manage the pcaps.

There are tons of tools that can query pcaps for data, Wireshark is only one of them.

If you are wanting to use Wireshark, in the "Analysis" and "Statistics" portion of Wireshark, there is a summary of the hosts, and even the ports that are used. As far as I can tell, that's what you are looking for.


Credit card store first four and last four which PCI SAQ?

Unfortunately for you, because the card data crosses your server (regardless of what you're storing), you're subject to the full SAQ D.  This document provides a good overview of the various levels and their requirements.

Both SAQ A and SAQ A-EP require:

  Your company does not electronically store, process, or transmit any cardholder data on your
  systems or premises, but relies entirely on a third party(s) to handle all these functions

Posting the card data to your backend server which then sends it on to the service provider means that you do "process [and] transmit cardholder data on your systems".  If your server gets compromised in any way (such as Heartbleed), the attacker would then have access to that card data.  Thus the higher SAQ level, and all the extra precautions that go with it.

Ideally, you would be able to rewrite your system to post directly from the web page to the service provider, without anything coming back to your server.  They ought to be able to provide you with a masked card number in their response, for you to store, but you can also probably just post the masked data back to your server along with their response.  You just need to make sure the full data doesn't come back, if you want to qualify for A-EP.


Double Submit Cookie: Can the attacker set the cookie as a separate header?

I think you're asking the wrong question.  Here is my question for you:

What's the point in creating an HTTP-only cookie if you're also storing the cookie contents outside of the secure cookie?

The whole point of making a cookie HTTP-only is that it secures the cookie contents from theft.  In the event of an XSS attack, an attacker can make requests on behalf of the user, but they can't outright steal the credentials - limiting the scope and timescale of the attack (in particular, the attacker will likely lose access as soon as the user navigates to a different page).

If you also are sending your cookie contents down to the app to store in a separate way, then the HTTP-only flag on your cookie is now pointless because in the event of an XSS attack, the attacker can steal the user's access credentials in from wherever else you are storing it, since only HTTP-only cookies provide any protection against credential theft in an XSS attack.

There are many effective methods to stop CSRF attacks.  As a result, if you are considering a method that also weakens another layer of security, then the answer is, quite simply, you're doing it the wrong way.

Is there a reason you aren't considering CSRF tokens or custom headers?  The former are the norm and are perfectly secure, so unless you have a compelling reason not to use them, then just do it that way.  If for some reason that isn't possible for you then you can fall back on custom headers, although that isn't ideal.


Why don't websites provide a checksum of their downloadable files?

You mention CCleaner, so it is relevant to link to Would a digital signature have prevented the CCleaner compromise? The short answer is that it would not have prevented this particular compromise.

This gives us our first problem with providing hashes: Who are we trusting to sign the build, and what are we trusting them to check? Does the signature simply represent the official build server, which could be compromised? Or does it represent an actual security audit by some pre-trusted party?

However, there are other attacks that such a hash would guard against - for instance, a compromised or fraudulent mirror offering a tampered build. In this case, it would be enough for the primary project page to publish a hash, which could be verified against the download offered by any mirror.

However, this leads us to the second problem, which is one of the hard problems of cryptography: key distribution (or, in this case, signature distribution).

For an unsigned hash, you are simply trusting the page that displays that hash not to have been tampered with. A signed hash at first sight seems better, but you still have to download the public key from somewhere, so you are still trusting the source of that key. If an attacker can direct a user to a fake download page, they can add a link to a public key of their choosing, and the user will get a false sense of security by verifying the hash of a compromised download.

The alternative is to have some central authority that you trust for multiple different applications - this is the principle behind Windows driver signing, Linux package managers, and phone app stores (and also behind the certificates used for HTTPS websites). Now you have a new problem: why do you trust those central authorities? Are they directly auditing the source code and build processes of the files you're downloading? Or are they delegating the trust, via a counter-signed certificate, based on some assurance from the party actually producing the software? Plus, you still need to acquire the root public key somehow - presumably it was included in some trusted installation media when you installed the OS / app store / package manager.

In the end, publishing a hash will be most useful for large projects, where:

the same user is likely to download and verify multiple versions, or different applications, with the same public key;
and, the source of the public key is likely to be different from the server offering the download (a different server, or some physical medium)

But even then, it cannot fix all exploits, as CCleaner demonstrated; and there is a danger in giving users a false sense of security.


WPA2, this works at hardware level, but if the hotspot network doesn't provide it then I cannot choose to use it, WPA or WEP.

WPA2 is better encryption than WEP. WEP is trivial to crack -- not much more work than solving the "encryption" puzzle in the Sunday paper.

  VPN This would allow me to make a tunnel from my machine to a VPN server (or proxy server?) on the internet, tunnel my traffic through without being read.

Yes.

  IPSec is this used to create a VPN?? I understand it works at the machine level, rather than application level (like SSL) so does this make it less secure? I presume only less secure from rootkits?

IPsec could be used to create a VPN, but it's just one option.

  SSL is this used to create a VPN?? I also assume this is what implements "https"

SSL could be used to create a VPN, but it's just one option.

  TLS is this used to create a VPN?? I also assume this is what implements "https". I think I saw somewhere that TLS is the successor to SSL?

This is correct -- you can think of TLS as a "new and improved" SSL.

  SSH, yet again, is this used to create a VPN?

SSH could be used to create a VPN, but it's just one option.

  DNSSEC part of my operating system (say on windows 7 or server 2008) which can help prevent DNS caching attacks?

DNSSEC would help protect you from DNS attacks, but a lack of widespread deployment limits its usefulness.

  So if I created a VPN, rented out a VPN server/proxy server outside the internet, used my vpn tunnelling (by which of the above protocols?) to connect to my vpn server and put my internet traffic through the public wifi, via this server, instead of the normal access point, I could get secure access?

In my opinion, the easiest way to solve your problem would be to rent a VPS and run only an SSH server there. Connect to the server via SSH from your laptop then run a SOCKS 5 proxy over the SSH tunnel. After purchasing your wifi access, switch your browser's proxy to the local end of the tunnel, and your web traffic will be encrypted between your laptop and the VPS. (Keep in mind that if you are visiting http (not https), your traffic won't be encrypted after it leaves your VPS, but at the very least it's not sniffable on your local wifi.)

There may be "canned" services out there that offer this setup for people like you. (A quick search reveals, for example, Guardster -- though for $20/month you could get a VPS at Linode with 200GB of transfer and 20GB of storage.)


should giving salt to unauthenticated users be a problem

There are two issues here:

Firstly, you need to avoid providing an oracle for "does this user exist in the system".  That means you need to provide a value whether the user exists or not.  Furthermore, this value must be consistent for a given userid (otherwise the attacker asks multiple times, and if they get the same answer every time, they know the user exists).  On the other hand, it must not be possible for the attacker to calculate the fake salt given the user id.  This means you need to generate a secret key for each installation, and the fake salt is generated by encrypting the userid with the key (or calculating the HMAC, or similar).  As noted in a comment, you also need to make sure that returning a real salt or a fake salt take the same length of time (otherwise the time taken can provide an oracle to tell whether the user exists or not).

Secondly, this is a cheap request for the attacker to issue, whereas the server is going to need to go to the database to see if the user exists, and if not, encrypt a value.  You will need some mechanisms in place to avoid this being a potential DoS vector.

Final thought:  I presume you are doing this, in order to offload the computational effort of hashing the password onto the client.  This is fine, and in the right situations, sensible.  However:

You must make sure you are using the browser to calculate the hash in native code, rather than javascript.  If you don't, the attacker with a leaked database (who is probably doing the hashing in native code on multiple GPUs) just has too big a performance advantage.

In addition, you need to make sure that you do one more round of hashing on the server and then compare the result with what is in the database.  If you don't, and the database ever leaks, the attacker will be able to log in as the user just by replaying the value from the DB.


Better safety: Webmail or POP3/IMAP clent?

I can't see difference if we are talking just about data transfer. If HTTPS, POP3S, IMAPS and SMTPS protocols are in use of course. Always use secured versions of protocols.

If we are talking about software - browser or the client, thats the same. Use patched software, all the time. The hole can be in both, web browser and mail client too.

Never opening attachments can't make the email more secure. It will make it useless. If you would state: never opening suspicious attachments it would sound better.

What I can see as a problem is user behavior. While POP3/IMAP client will be probably used only in user's device, it is highly probable that the web mail will be used from anywhere, even from a non-trusted PC. There is no possibility to guarantee "security" in this case. Traffic analyzers, key loggers, or whatever so can be installed there.

Edit:
for somebody the added value of thick email client would be it is possible to install some kind of antivirus/antimalware plugin there. But in reality, this can't increase protection against malicious software so much.


Effective Free and Anonymous Web Form Encryption

What you want is not possible, because there is no established trust relation between client and server and plain HTTP can not provide a secure way to establish this trust. Only HTTPS provides thus trust by checking the servers certificate against local trust anchors at the client, that is it infers the new trust from trust settings already built into the browser.

Without such trust between client and server you are open to man-in-the-middle attacks, where the attacker claims to be the server against the client and claims to be the client against the original server. In this case the encryption will be done between your client and the attacker, which then can decrypt the data, manipulate the data and forward the data encrypted to the real server. Such man-in-the-middle attacks are easily done in lot of networks (like public WLAN and most smaller LANs too).

While you might try to use a pre-shared secret to use instead of certificates it has the same problem: the secret somehow needs transferred between client and server and as long as this connection is open to manipulation (plain HTTP) the attacker can get and manipulate the shared secret. Even anonymous key exchange methods like Diffie-Hellmann can not protect against this.


SSH: Best practice for PublicKey Authentication from multiple Devices

You should have a different private key for each device. Here's the reason that i can think of :

This keys are for authentication so if you share them, you won't be able to discrimate the different users/devices connecting to your server. Should a problem happens you'll probably want to know the device involved.
The security of Public key authentication is based on the secret of private keys. The more a secret is duplicated the more difficult it is to keep it secret.
If you have a security breach on one device (or the device is stolen), it won't compromise the security of the other devices and you'll have the opportunity to ban this specific device.

Security often comes with a cost. Money, time, skills, comfort of use.
If the cost of having multiple passphrases is to high, you could use a password manager to store and remind them.


Using Proxy Server, can gateway know which URL i am trying to open

So my gateway or firewall will know which URL I am trying to open? - More or less, yes, but not "directly" per se. It will not know what your IP address is, hence the anonymity. A proxy is simply another computer that exists between your computer and the internet. For example, if you type in www.google.com in your browser while your device is connected to a proxy, this is what will occur:

The browser will make a TCP packet with an HTTP GET www.google.com request (with sender address as your IP address) and sends it to the proxy server. The proxy application running on the server looks the packet and sees that it is addressed to google. It forwards the packet to google.com, changing the sender address in the TCP packet to its own. From here google does not know that it was you who is using their service, they only see the proxy server using it.

Google receives this packet from the proxy and sends the contents of its website in another series of packets to the proxy. The proxy accepts this packet and forwards it back to you. Boom.

Visually:

Browser -> Proxy -> example.com

So, your gateway is under the impression that it is sending an HTTP request to the Proxy server, NOT example.com. Therefore, if you have example.com 'blocked' on your gateway, the connection will still be allowed to the proxy.

:update - since this appears to be a UltraSurf specific question.

Ultrasurf does not use a DNS. It takes your typical DNS queries and routes them to a static IP, instead of asking for one (much like modifying your HOSTS file or equivalent). That way you are connecting to port 80 on the unblocked IP address 74.125.224.160 (youtube.com), instead of making a disallowed DNS query.


What is a safe way to exit a user's shell?

Do not drop to a lesser user using su or sudo from a shell.

While what you propose is a valid risk, there is another, much bigger risk when dropping to a lesser user and then exiting, called the TTY pushback attack, using the TIOCSTI IOCTL. This allows arbitrary data to be sent to the calling shell from the child.

From http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/:

  When su -s /bin/bash [user] is called from interactive shell, the input queue data pushed back as the target user will be executed by the interactive shell calling su.


As can be seen from Can a RootCA be revoked? there is no mechanism inside a PKI that a root CA gets removed. This means a mechanism outside the PKI is needed. This consists usually of an update of the trust store through update of the browser or the system which removes this certificate from the trust store or mark it as untrusted.

Such events happened in the past for example with DigiNotar. This case was handled by updates to the Firefox and Chrome browsers, updates of  Microsoft Windows and of iOS and Mac OS X.


SSL Certificate Management and Expiration Notification

They are lot of utilities available to notify the expiry date of the SSL certificate and most of them depends upon the application specific. For simplicity, you can write your own script or code and you can customize the things more simpler. even  you can do with openssl or keytool to run in a cron job to send a mail or sms automatically.


Do the firewall hardware specifications have to be better than the network it protects?

You say:

  If I need a bodyguard I'll have to hire someone whose muscles are
  much tougher than mine

This mean that if you need a bodyguard, you will need someone with very specific capacities allowing him to protect you effectively. He will not need to have the same study background as you, he will not need to be able to administrate servers, he will not need to beat you at chess or whatever.

In other words, the bodyguard does not need to be "better" than you, he needs to be dedicated to his job.

The same apply for a firewall: he will need reliable network cards, low latency bus. But he will not have to handle all the bell and whistles required by a full fledged web server running HTTP daemons, proxies, databases, application servers, and the list could go on endlessly and the longer the list is, the more you will need RAM and CPU. But, when talking about firewall just handling small TCP/UDP packets to decide to let them pass or block them, RAM and CPU power becomes  of less importance.

Recently I went on an interesting article dealing on this kind of subject, do not hesitate to check it.


To scan arbitrary HTTPS traffic, you have to do one of the following:

You add a hook in the client SSL library so that you get the outgoing data right before it gets encrypted, and the incoming data just after it has been decrypted.
You know the server's private key (and the server does not use a "DHE" cipher suite).
You run a MitM, which implies generating a fake server certificate on-the-fly, by a CA that you control and that has been installed in the "trusted CA" store of the client.

The second solution is not feasible in general (you can do that when you control the servers, but not for all servers on the Internet). The third solution is what you do in corporations and big organizations where maintaining client-side SSL hooks is cumbersome and a huge logistics problem, while doing a one-time insert of an extra root CA is easy.

A locally installed antivirus has the choice. The "hook" option is cleaner, but is specific to a given SSL library; typically, IE and Firefox do not use the same SSL implementation at all, so if Avast uses the hook method then it must hook into both implementations. The MitM method is easier to apply system-wide, and is more resilient to software updates, but it can break some functionalities (e.g. client certificates). To know which method was applied, try to connect to various HTTPS sites, and have a look at their certificate chain; if all the chains go back to a single CA that looks Avastish, then that's the MitM method. If the chains go back to various existing root CA, then that's the hook method.


This is a recurring question, and it comes with a bunch of caveats.

Threat level is a factor. If this is government classified data the official answer is "Destroy the Drives!"

That said, in the commercial world there is a lot more tolerance.

Running DBAN or dd with zeroes against the entire drive will sufficiently wipe it. You should of course VERIFY that the wipe actually took place by looking at the drive contents and confirming zeroes. Zeroes are easier to confirm than random.

You don't need to perform multiple wipe passes to defend against magnetic force microscope attacks. This was a laboratory curiosity more than two decades ago against MFM disk drives that are no longer used and against drives that measured in MEGAbytes. Even then, they could only extract a handful of bytes. A single pass of zeroes will defeat any Earth based forensic facility.

True, bad sectors and hidden disk overlays won't be wiped. If this is a realistic concern for you, fall back to the DoD standard of destruction.

Trotting out wear leveling for solid state drives is also a bugaboo of little reality. Yes, it's technically possible to perform chip-off removal, bypass the on-chip wear processing and find data that survived wiping. However this data is tiny discontinuous snippets and bits that are nearly impossible to reconstruct context from. This is beyond all standard forensics labs and would cost millions of dollars in the specialty labs to even attempt it and would likely yield little to nothing for the effort.

Again, if this is a realistic concern for you, fall back to the DoD standard of destruction.

The drive costs are likely no more than a couple/few $100 bucks, act accordingly.


How to scan a website using Nessus with login credentials

Nessus has the information posted on their page with a full walk through. http://www.tenable.com/tips/how-to-enable-credentialed-checks-on-windows


What are the main sources to collect Threat Intelligence Information especially from Dark Web

The best one I've come across for non-Darkweb OSINT gathering so far is the tool named "Harpoon" written in python3. As you pointed out, there are multiple ways to gather OSINT data but aggregating them is a herculean task for the analysts. Harpoon makes it easier with API integrations to grab different types of OSINT information and it's pretty easy to setup.

Follow the link https://www.randhome.io/blog/2018/02/23/harpoon-an-osint-/-threat-intelligence-tool/ for more information on how to Install and use Harpoon!

With regards to Darkweb, I found this tool really helpful but it's still kind of work in progress and is again written in python3. This tool makes use of Tor and is one of the requirements for it's onion crawler to function.
More at https://github.com/DedSecInside/TorBot

Hope it helps!


According to the manual page, you can use -n or --include with either the index or the shortname for the given entropy source specified in -l to enable it. In your case, you would run the following:

rngd -n 4

However, in the same manual page, there is a warning about enabling this source:

  Entropy gathered from the NIST network entropy beacon.  Note that this entropy source is disabled by default as it should never be used for cryptographic purposes, or any use case in which random data should be known only by a single entity.

The problem is that the NIST entropy beacon sends the random data to everyone over the network. It is not intended to be used for secret keys (the ouput isn't secret), but for getting unpredictable randomness. In fact, it allows anyone to see a list of previous random outputs! From their FAQ:

  The Beacon is designed to provide unpredictability, autonomy, and consistency. Unpredictability means that users cannot algorithmically predict bits before they are made available by the source. Autonomy means that the source is resistant to attempts by outside parties to alter the distribution of the random bits. Consistency means that a set of users can access the source in such a way that they are confident they all receive the same random string.

Bold emphasis mine. This means that everyone gets the same output, so it is not secret after it has been released! In fact, the beacon only releases a new 512-bit output to everyone every 60 seconds, and the previous output is stored and available for anyone to see. Now, while rng-tools will only mix the data with the random pool in order to prevent any sources from reducing security, using the NIST entropy beacon to supplement your kernel random pool is unnecessary and won't really provide you with any cryptographic benefits, anymore than mixing in the previous winning lottery numbers would.


Courses on "Secure Software Development"

For Reverse Engineering: The University of Helsinki in collaboration with F-Secure offer a course titled Malware Analysis and Antivirus Technologies which has the curriculum available online.
For Secure Coding: CERT is always a good reference, especially for C & C++. They have a Secure Coding in C and C++ course at SEI @ CMU.


What is the benefit of combining different web log files with different formats?

What you are describing in your question is often called Informationfusion. By being able to connect different sources of logs you can more easily increase knowledge of the context of the requests and help to determine its interpretation.

The more logs you can put in context with other logs and information the more valuable they become.

For example say your webservers are all sent to a central logging device where their format is unified. Once your logs now are unified you can quite easily use commands like:

cat weblogs.tz | cut $ip > ip.txt
netcat whois.cymru.org 43 < ip.txt > result.txt

And your now sitting on your users ASN, IP-address, Nettrange, country and other nice stuff from all your webservers. Taking this a step further you now look for suspicious clients who are visiting your servers in patterns that is not normal, maybe looking for a focused attack.

Now with all your webserver logs you could also look more into any patterns that is seen on all or just some of your webservers much easier. Like this list from zeltser.com/log-management/security-incident-log-review-checklist:

Excessive access attempts to non-existent files
Code (SQL, HTML) seen as part of the URL
Access to extensions you have not implemented
Web service stopped/started/failed messages
Access to “risky” pages that accept user input
Look at logs on all servers in the load balancer pool
Error code 200 on files that are not yours
Failed user authentication    Error code 401, 403
Invalid request   Error code 400
Internal server error   Error code 500


Security of SSL certificates bought via resellers

It's not any less secure than going directly through a CA. CA's can be compromised just like anyone else. Even if the CA required revalidation, the reseller could just claim to have done it.


Which part is the longest when gerating RSA key pairs?

This looks weird. An anemic laptop from 2005 generates 4096-bit RSA keys (i.e. huge, overkill keys) in less than 10 seconds. "Several minutes" would indicate that there is something wrong in your system. Or that you are aiming for ridiculously large RSA keys (2048 bits are very fine; 3072 bits are understandable if you have paranoiac managers or must comply with some equally paranoiac regulations; 4096 bits are over-the-top exaggerated; beyond is just plain stupid, and will also incur interoperability issues).

In any case, RSA key pair generation mostly consists in producing two random prime numbers of about half the target modulus size. Generating a prime number boils down to, mostly, trying random odd integers until a prime one is found. This is amenable to high parallelism, although it rarely matters.

One must say that generating RSA keys securely requires some good knowledge of mathematics and cryptography. There are many RSA keys out there, which were produced from poor PRNG and are, therefore, highly breakable -- and it cannot be tested. I therefore strongly urge you to reconsider fiddling with such code.

Finding out why it takes several minutes on your machine is more important.


Cellular encryption algorithms currently in use globally

You have the other comments already. As a minor point, the list isn't quite correct in two areas:

A5/4 isn't Snow 3G - it is a full length 128-bit key version of A5/3 using the Kasumi algorithm.  See 3GPP TS 55.226.  The Kasumi algorithm applied to GSM uses a 64 bit key bulked out to 128 bits for algorithm input.  A5/4 extended that to using the full 128 bits
LTE confidentiality algorithms.  Yes, EEA-1 with a 128 bit key, based on SNOW 3G is available, but 128-bit AES EEA-2 is also available. More recently, EEA-3 has become available, based on the ZUC stream cipher. See, for instance
[1] ETSI/SAGE Specification, Specification of the 3GPP Confidentiality and Integrity Algorithms 128-EEA3 & 128-EIA3. Document 1: 128-EEA3 and 128-EIA3 Specification; Version: 1.6, (2011).
[2] ETSI/SAGE Specification, Specification of the 3GPP Confidentiality and Integrity Algorithms 128-EEA3 & 128-EIA3. Document 2: ZUC Specification, Version: 1.6, (2011)


Does an Embedded Content Security Policy (CSP) Enforcement ruin a "regular" CSP?

Not at all.

Let's say I build my website supersite.com with a lot of JS, so I want it to be able to run scripts, but I also want to put some adds, but I don't want it to be dynamic and thus doesn't execute script.

The problem is that usually, my add provider do include script. To avoid this, I explically tell him that I do not want script, I'll then set the following iframe:

<iframe src="http://addprovider.com/?site=mywebsite" csp="script-src 'none'"></iframe>

While sending the GET request to addprovider.com, the following header will be set :

Embedding-CSP: script-src 'none'

From there, addprovider.com knows that if it puts script, supersite.com will refused to execute the script and thus decide to put some fancy images instead. While sending back the answer, addprovider.com shows that it accepts the given policy by setting the following header:

Content-Security-Policy: script-src 'none'

If addprovider.com try to cheat and send back that its answer is csp complient but doesn't, supersite.com the response will be blocked.
If addprovider doesn't return csp or return a csp that doesn't match or enforce the given csp, the response will be blocked too.

How is it usefull ? This are the 2 alternatives atm :

Set a CSP on supersite.com, with header or meta tag : <meta http-equiv="Content-Security-Policy" content="script-src 'self'">. Howewer, this CSP will not apply to the embedded addprovider.com !
Use sandbox attributes. Howewer, this it too broad. You can only block all script or none. You can't specify different locations while you can do with CSP


How exactly can an infected Samsung TV record private conversations in a room?

A partial answer:

  Which models are safe

All models which don't have any microphones built-in.

  How this bug exactly works

The how is easy. If your TV has a microphone (for example your remote might have one to enable you to control the TV via voice recognition),
an attacker can turn on the microphone, record everything that it picks up and send it to a server on the internet where it can be picked up by an attacker. This is the same kind of attack that can be done on smart phones, except that there an attacker can also turn on the camera without your knowledge. This is why some people put a tape over the front camera of their smartphone and the builtin webcams of their laptops.

While André's suggestion not to connect the TV to a network might not be practicable, it's really the only way to be sure that your TV doesn't spy on you (the microphone recording is the biggest problem, but the TV can also spy on you by recording what you watch and when you watch it). I'm pretty sure netflix does this as a normal part of their business.

Another solution, if you're not afraid of operating on your TV set, would be to physically disconnect the microphone.


Is the image of the signature considered PII?

PII by definition is

  any information that can be used on its own or with other information
  to identify, contact, or locate a single person, or to identify an
  individual in context.

And to answer your question, image of signature is a sensitive PII as it can be used to identify a person. As base64 encoding only obfuscate the data, that also shall be considered sensitive and nearly as unsafe as having the cleartext counterpart. You should treat the data as a sensitive PII irrespective of the type of encoding and filename.


DRY API Authentication Design Between Services

Who are you trying to protect? the user? the front-end web? or the API?

I see one problem in that the API secret is stored on the front-end, which is more likely to be exposed to the outside world. If the front-end is compromised, then anybody can access the backend impersonating the user. It is a likely point to intercept in order to gain access to those secrets, otherwise only known to two parties.

I'm not sure I understood the point of the user providing the api secret, or whether it was stored on the front-end, and the access was granted by e.g. a username/password.

Otherwise, it sounds like you can benefit from using OAUTH to sign requests. OAUTH has a (oddly not very known it seems) two-legged mode, where you can easily exchange signed messages between two entities with a shared key.

All and all, looks like either a bit of a confused/confusing design, or perhaps it's hard to explain without giving more context. Best advice is to try not to reinvent the wheel and use existing algorithms/solutions/architectures as much as possible.


location of msfconsole generated executable in Kali linux

You're going to want to give the -f flag a fully qualified path
generate -t exe -f /root/shell.exe
should drop it in your root directory
You can read more about Generating Payloads on the Offensive Security Website
Here is an example they give
generate -b '\x00' -e x86/shikata_ga_nai -f /root/msfu/filename.txt


Does Facebook store plain-text passwords?

Let's hope and assume that Facebook stores only hashes of current password (and potentially previous passwords).

Here is what they can do:

user sets first password to "first" and fb stores hash("first").
later on, users resets password and is asked to provide new password "First2"
Facebook can generate bunch of passwords (similar to the new one): ["First2", "fIrst2", "firSt2", ... "first2", ... "first", ... ] and and then compare hash of each with the stored hash.

This is the only solution that comes to my mind. Any other?


Folders with .js files that I didnt create are in my pictures directory windows 10, virus?

These are files for saved webpages. I can almost completely guarantee that you've accidentally hit Ctrl+S in your browser and saved a page to your Pictures directory.

If you go up one folder, you'll almost certainly find a pair of HTML files that correspond to the folder names. The _files directories are where the resources (images, scripts, etc.) are saved for those saved HTML pages.


Yes, there's a PAM module for just about everything. You pick your auth token, there's a PAM module for it. SecurID, Yubikey, Text Message, you name it. And yes, also TOTP (e.g. Google Authenticator, Microsoft Authenticator, etc)

If you're looking for doing authentication somewhere other than PAM, then perhaps you should re-evaluate your goals. They call it Pluggable Authentication Modules for a reason. That's exactly where authentication should happen.


Developing Small Business Information Security Standards

to start I suggest you to refer to the SANS top 20 critical controls that every year are released and updated. They are about policies, appliances and best practices that must be applied to reduce the risk of possible incoming threats.

Here you can find an intro about them: https://www.sans.org/critical-security-controls

But I strongly suggest to download the posters. Here the one of 2014:

https://www.sans.org/media/critical-security-controls/Poster_Fall_2014_CSCs_WEB.PDF

Once you become familiar with those, you can easily understand the most common standards that are used in industry depending on the country and the scope, like:

NIST
ISO 27002
PCI

SANS actually maps its TOP20CSC to those standard (look for it in the posters)


Is it safe to use Java Bouncycastle cryptography in production environment over standard Java crypt?

Given the wide use of Bouncy Castle and a security record which is no worse than other TLS implementations it is probably not a security problem to use it instead of the standard Java libraries in production. This means I would not argue that it is 100% safe but it is probably not less safe than the standard Java libraries.


Check if DVWA application is set up correctly. For instance, call http://localhost/index.php or http://localhost/about.php. If the application is set up correctly, you will see corresponding text from PHP. Otherwise you will see errors like 500 or 502. The reasons can be for instance incorrect integration of web server with PHP, or incorrect connection of DVWA to database.
In case application is set up incorrectly, the response will not contain the expected error message. Hydra will consider this as success, no matter what passwords you will provide.


Are some privacy add-ons superfluous when using Tor browser?

First of all, NoScript and HTTPS-Everywhere are included in the bundle by default (see "What is Tor browser").

Other than that, it boils down to your personal list of pros and cons. You will alter the browser's fingerprint by customizing it with add-ons which may result in your instance being more unique/trackable. This goes against recommendations and warnings to keep the bundle as default as possible to be indistinguishable from other Tor browsers on the net. This applies to actions like installing/removing add-ons, resizing the window, enabling/disabling title bar/menu bar etc.

The best way to stay anonymous is most likely to use Tor via Tails which will - by design - take care of things like cookies, and leave everything to default. Just make sure that JavaScript is disabled. That way, most of the tracking functionalities will be disabled and you'll be near-indistinguishable from other Tor browsers.

Additionally, you may want to check out Michael Hampton's thorough and in-depth answer regarding other Tor best practices (although he recommends installing Self-Destructing Cookies).


I can promise you it's marketing ...

What I can read from their buzzword-filled infos, and some third-party sources, it means that:

Data is not only encrypted in sensitive phases of some process (eg. the TLS encryption between me and stackexchange here), but pretty much everywhere else too (eg. in the backend database of stackexchange). If it needs to be processed, it's decrypted right before processing, and encrypted again right after it.

That's all.

The two problems with that are

It needs more powerful computers (IBM will gladly sell their mainframes to you, which are the reason for this "pervasive" marketing anyways), and
the server with the database, or anything else that is doing some processing, will need the key too; and if someone can get the database then the chances of getting the key are not bad either. Of course IBM has no solution for this basic problem, that was/is the reason that no one is doing this in the first place.
(Yes, with hardware support it doesn't have to be a (huge) problem, and it is done too, but IBM is not changing anything from the current state)


Mass account lockout prevention using CSRF tokens

I personally never saw something like this implemented, but why don't you set up a time increasing failed login ?

For example, after three unsuccessful login, you block the login for this account for, say, 30 seconds. After the 30s, if the 4th login is still unsuccessful, you stop it for 1min, then 5min, and you increase more and more.

This won't affect your real users (you generally don't fail 3 times if you remember your password, and if you don't, you go to the "Lost my password" process), and robots will fail using a brute force attack.

Now, the CSRF idea is interesting for forcing your user to get the token, but if I build a robot, I still can simulate a GET request to the login page, parse the HTML and get the token, to then use it for a POST combined with the credentials. The only limitation you suggest here, is the wait between the generated token and the submitted form (and this could hurt your users that are fast writers).


TCP reset attack, number of Reset Packets

What are the capabilities of your attacker? Usually TCP resets are performed by someone with visibility of the network. For example, Comcast got sued (and lost) for killing BitTorrent communications with TCP resets, but since they were inspecting the packets, they knew the sequence numbers to use.

Also, realize that 32 bits is only 4 billion-ish possibilities, and you can divide that by the size of the window you estimate. You can also expect to have to try only half of those on average before hitting the right one. Any TCP implementations whose sequence numbers start at 0 are easy to brute force, and it's only a few GB of traffic to kill even a connection with randomly initialized sequence numbers.


What are the security implications of connecting to Tor through an SSH SOCKS proxy?

The specific details for your proxy setup are irrelevant. It doesn't matter if it's done through SSH port forwarding or OpenVPN or IPSec or GRE. What matters is whether or not someone who can monitor the connection between your local Tor process and the Tor network can glean any useful information. The answer is no, they really can't get much. The connection is encrypted so the plaintext contents of the communication, in addition to the destination, are all opaque to the proxy. Yes, it is possible to analyze packet sizes and timing, but it is difficult and largely a theoretical risk. It is made more difficult due to some basic padding done by Tor (all transmissions occur in chunks of 514 bytes, never less). The two primary types of attacks are traffic correlation attacks and website fingerprinting attacks:

Traffic correlation attacks involve a malicious ISP, guard, or proxy that you are using to connect to the Tor network collaborating with a malicious or monitored website or exit node. In theory, the packet timings can reveal that you have connected to the website. This is not so easy in practice because there are a huge number of people using the Tor network, so it becomes difficult to tell whether or not a correlation of packet timings is just coincidence. An adversary who is able to passively monitor all connections globally may be able to mount this attack.

Website fingerprinting attacks exploit he fact that websites do not all behave identically in terms of amount of data sent. If YouTube and Stack Exchange were the only websites in the world, then it would be trivial to tell, based on packet sizes alone, which of the websites you visited even if the connection is encrypted. However there are more than two websites, and determining which website you visited amongst billions of websites and hundreds or thousands of pages per website is quite impractical. Even still, Tor Project is working on solutions to that.


No, no additional validation is needed to prevent SQL injection.  This pattern is safe.   When you're dealing with a stored procedure that simply uses the parameter values as predicate values in the SQL statement (WHERE p = @p)  SQL Server knows that the value of the parameter is data, not an executable statement.   Executing the contents of the parameter is not possible.

The only time you really need to be concerned about the value of parameter that you're passing into a stored procedure is when you're explicitly executing it inside the proc, using EXEC, EXECUTE, or sp_executesql.


Dealing with OpenSSH CVE-2019-6109, CVE-2019-6110 & CVE-2019-6111 on CentOS 6

We found https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt which has a few patches in the mitigation section. I used these against a fresh download of openssh-7.9p1. I had to do a minor edit to scp.c around hunk #9 for the patch as it looked like a partial hunk of this patch was already in place. I also had to ignore whitespace.

wget https://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.9p1.tar.gz
wget https://sintonen.fi/advisories/scp-name-validator.patch
tar zxvf openssh-7.9p1.tar.gz
cd openssh-7.9p1
vim scp.c
patch -p1 --ignore-whitespace < scp-name-validator.patch

My change to scp.c removed line 1108 and replaced it with this. You can see why in the patch file at line 271. The Patch will replace this with the desired line.

if (*cp == '\0' || strchr(cp, '/') != NULL ||
  strcmp(cp, ".") == 0 || strcmp(cp, "..") == 0) {

Then ./configure --with-pam, make, make install or whatever you would usually do to upgrade you OpenSSH running version.


Are deleted offline calendar events in Android actually deleted?

Maybe not an answer to the question, but useful info for those who find this question while having this problem:

For people who use offline/local calendars, and notice their .ics export contains deleted events (even recurring events, and events from years ago):

It seems that indeed, deleted events are only "marked for deletion", meaning they still appear in exports. (This problem seems to be fixed in newer Android versions, and may have only been a problem for users of offline/local calendars.)

You can observe this problem by using the Calendar Import-Export app on Android systems which are affected by this problem. Look at the event counter, it stays the same when deleting an event via your calendar app. On newer Android versions, the counter does decrease.

Edit:

I've updated the answer. It seems the problem occurs regardless of which calendar app you're using (like Etar or S Planner). I'm guessing the problem is caused by the com.android.providers.calendar system app instead (which stores the calendar events).

The problem seems to be fixed on newer Android versions.

The problem was reproducible both with Etar and S Planner on Android 6.0.1. The problem was NOT reproducible with Etar on Android 9.0, but that's probably because of the newer com.android.providers.calendar system app, and has nothing to do with what calendar app you're using.

Related quote from the developer docs for CalendarContract.Events at android.com:

  There are two versions of delete: as an app and as a sync adapter. An
  app delete will set the deleted column on an event and remove all
  instances of that event. A sync adapter delete will remove the event
  from the database and all associated data.

Related resources:

https://softwarerecs.stackexchange.com/questions/28142/offline-calendar-for-android-with-at-least-basic-functionality
https://stackoverflow.com/questions/37429313/does-com-android-providers-calendar-remove-deleted-events-or-just-flag-them-as-d
Local calendars: Remove events from database, not just mark them deleted #624 (github.com/Etar-Group)


How secure is redirecting user from http://normal.bank.com to https://secure.bank.com?

Is this is still vulnerable to MIM attack?

Yes, it is, because you'd probably go with session-cookies that might be sniffed through a browser-plugin like firesheep or man-in-the-middle'd easily.

  What are the precautions?

Best practice nowadays is to have your whole application run over HTTPS because:

secure cookies don't work in a mixed environment
MITM-attacks do work in a mixed environment
ensuring the authenticity of your website to its users doesn't work in a mixed environment
no need to think about HTTP-resources in a HTTPS-page and ugly browser-alerts

To ensure HTTPS throughout the whole site:

create 2 virtualhost-configs, one for http: and one for https:
in your http config, use a redirect from http://site/resource to https://site/resource as the only pattern in this config, so if someone types in http://site/somepath it will always get redirected to the secure site
in your https config, use a HTST header to help ensure (browser-based) that your user visits your site always via HTTPS

Everything else, like login-page-encryption-only is out-of-date; search for "firesheep"


The following signatures were invalid: EXPKEYSIG 6494C6D6997C215E Google Inc despite correct signing key

"This is the protection you are getting from these checks. You don't want to update your software right now while something is messed up on Google's end. Wait until they fix it. Don't try to override by reinstalling keys until some official word comes out that a new key is the solution."

Original link - Source


mov can be replaced by push and pop. So eg this:

mov    $0x3c,%eax

Can become this:

push $0x3c
pop %eax

Which would give you this null byte free code:

   0:   31 ff                   xor    %edi,%edi
   2:   6a 3c                   push   $0x3c
   4:   58                      pop    %eax
   5:   0f 05                   syscall


How to know an Apache web server mod_cgi module is enabled?

The first place to look is the server header. Depending on the server configuration it may report all enabled modules. Alternately you can use a specially formulated request which will provide a less reliable detection. The AddHandler directive allows a script to answer with a non 501 response to incorrect HTTP verbs. I'm using this technique in my Apache profiling script (aprof) from my lbmap project: https://github.com/wireghoul/lbmap


What is a root method and how is it achieved?

Most older Android "root methods" are using kernel exploits or exploits for drivers or applications running as root. More hardened phones are often attacked by booting an purpose crafted image without security measures in place.
Goal of both methods is to place a su binary on the device that allows the user to give access when needed, without any further checks (it might trigger a dialog to confirm root access or be totally silent). If a device ships with a su binary already it is replaced as the original binary will not grant root access to the user.


WMI can be secured to be safe for internal networks following some configuration steps:
https://msdn.microsoft.com/en-us/library/aa393266(v=vs.85).aspx

Confidentiality

The most immediate issue (to me) is requiring encryption in transit to mitigate snooping (excerpt of above):

  An administrator or a MOF file can configure a WMI namespace so that no data is returned unless you use packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY or PktPrivacy as a moniker in a script) in a connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Requiring an Encrypted Connection to a Namespace.

Least Privilege

The next most important thing is least privilege via RBAC.  You should limit the asset management product's account to read-only WMI operations and if possible limit what it can read to what is needed.  This is achieved via Namespace Security and is described further here:
https://msdn.microsoft.com/en-us/library/aa393613(v=vs.85).aspx

You may need to allow certain write privileged if the asset management software also performs actions on the endpoints rather than just auditing.  Press the vendor for a least privilege configuration.

Strong Authentication

Once you have that you should generate high entropy random values (using all the characters and maximum length the asset management tool will work with) for both the username and password.  These credentials should be stored in a secure password management system like Thycotic Secret Server or a local secure password manager such as KeePass for which you maintain backups.  You can probably use a non-random username, but that does increase risk somewhat if it's easily guessed and using a random username given how infrequently you need to manage it gives you a free security boost.

Network Security

After all that you should set Windows Firewall with Advanced Security to allow the DCOM connections needed for WMI only on the port it is running on and only from the host (or hosts if you are doing HA) running the asset management software.  This is the final layer of the defense in depth here and makes it harder for attackers to exploit even of they have the credentials.

Single Purpose Single Server/VM

The asset management software should be run on its own on a dedicated server or VM.  The firewall whitelist is far less useful if it's on a misc app server with all the other junk a network needs.  Running it with other software or services also exposes it and the credentials to unnecessary local attack risks.

You may be able to bake those steps into a GPO.

Alternative solution: PowerShell

An alternative (though incompatible with you asset management product) is PowerShell Remoting.  It uses TLS and GSSAPI authentication integrated with AD so I'm very comfortable with it.  We use it in production.

Once you have PowerShell remoting you can log into a system remotely with Enter-PSSession %MachineName%.  You can also use Invoke-Command with -ScriptBlock to run a command remotely and get results centrally for coordination.  Your WMI commands could be run that way.

Here's a guide on enabling PowerShell Remoting:
http://blogs.technet.com/b/heyscriptingguy/archive/2012/07/24/an-introduction-to-powershell-remoting-part-two-configuring-powershell-remoting.aspx

Conclusion

The challenge with either of these is transitive trust and lateral movement.  Be careful that the accounts allowed to make this jump between machines have very strong passwords.  We use per-person 100 character full ASCII random generated passwords for this that we rotate every 90 days.  We use KeePass to autotype these as they aren't practical to type by hand.


THE strongest is perhaps not well determined. But Chrome wants to see something like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, i.e. the cipher suite has to use DHE or ECDHE and AES in Galois Counter Mode.

Alternatively you can use CHACHA20_POLY1305 as the symmetric algorithm.


Displaying a video through the web whilst hiding the location

This is impossible.  You could use a streaming server to send it over RTMP or even put some DRM on it to make it harder to play outside of a secured player, but the stream can always be ripped if it goes to a client's computer and DRM is just a small hurdle to be overcome by a determined attacker.

You seem to be aware that it is impossible though, so the recommendations still hold.  Using RTMP (or similar) would make it so that someone would have to use a stream ripper rather than a simple progressive download.  DRM on top of that would put a further barrier, however both of these impose on the client side options as well.


What you are describing, are very similar to what I have read in a recent news article.

It is about a bug in the Great Firewall of China, where it has supposedly been upgraded, where it can blast random sites with requests that it should have blocked.

Read the article here if you are interested.


Yes it is totally possible. Common Crypto Libs like OpenSSL and Bouncycastle will do exactly that for you. You provide a list of trusted (root) certificates, a list of chain certificates, and you provide them the certificate that you want to check. It will use just those certificates needed between all you provided to chain up to a trusted root and validate the certificate. You may also get the chain if needed, as described here: http://www.nakov.com/blog/2009/12/01/x509-certificate-validation-in-java-build-and-verify-chain-and-verify-clr-with-bouncy-castle/

However, since the main topic here is security, not how to use a lib, except you are just doing it to study or by any reason you really want to get the chain (ex for displaying it), just verify using the standard verify methods, do not try to reimplement RFC5280 by yourself. There are many things to get wrong there.


How to know if an RFI/LFI attack was successful?

Is the content-length header can tell us something ?

It may depend on the particular server and application. In many cases, the HTTP response will contain the contents of the requested file itself, or the output of executing it. So usually, you'd just confirm that a file was returned.
If the content length for an invalid file is 0, and a valid file is > 0, then that could work. I don't know if it would be that cut and dry, however, but maybe you can identify a baseline value vs a valid file hit. But maybe instead the particular application instead returns an HTTP 500 code if the file is invalid. It's probably good to try files that you know exist, so you can calibrate the expected response based on how the server responds.

If RFI/LFI does not work on one (valid) file, does that mean there is no chance of this attack at all?

Depends how you define "valid". If the file exists but you do not have permission to read it, then you will probably get a negative response. There also may be path filtering or a forced file extension; in these cases you may only be able to view certain files.


Number 2 Is more secure because it is simple, and the most common method of implementing a CSRF synchronization token.  Complexity is the enemy of security.   To be honest I cannot identify a single attack being prevented by measure in #1,  it seems very superstitious, "cargo cult security".  This security measure doesn't prevent an interception proxy like BURP from accessing the PHP file, and further more no security system should rely upon this measure.  XSS is still a  major problem that could undermine this application (and CSRF sync tokens in general).

I recommend reading the browser security handbook,  and A Tangled Web to help understated the Same-Origin Policy and ways that it is abused by attackers.


Doing IT security properly implies grasping the fine details of how a computer operates; if you have that knowledge, then learning a programming language would be a matter of a few days at most. It is not, theoretically, strictly necessary to know any programming language to "do IT security", but potentially knowing them all is basically a requirement.

There is a lot more to software development than simply "knowing the language", and we are not talking here about being able to design a big application, structure it, implement it, and being able to understand the code three months later. We are simply talking about the ability to write a 100 lines of code in order to experiment something. Every decent IT security specialist ought to be able to do that.

(Conversely, I have met some IT security "specialist" who could not, and decency prevents me from expressing in accurate terms what I think of their competence.)

Specific programming language, generally speaking, does not matter. They are all more or less the same -- I mean the programming, not the language. Ideally, learn three or four languages; then you will know them all. Potentially. Which is the important point.

There are specific situations, though, which require a bit more programming knowledge. If doing pentesting on Web applications, you should have at least rudimentary knowledge of PHP, Javascript, SQL and C#/VB (for ASP.NET).

To be taken seriously, be competent. To be competent, spend time on it. Computers in general, IT security in particular, are a field where practitioners spend a lot of time trying out things at home, on their own computers.

Certifications are great when you want to be hired, because most people who will hire an IT security specialist are not IT security specialists themselves. For them, a certification is a kind of "proof of competence". In fact, a certification is a signal: it demonstrates that you were serious enough in your craft that you deemed it worth the effort to obtain the certification (learning the skills for the certification exam, spending the money on the certification, and, biggest effort of all, navigating the administrative task of actually obtaining the paper).

Don't become an IT security specialist if your idea of fun does not include spending five hours reading through log files and network transcripts.


Since applications can continue to execute in the background, the disk encryption key has to exist somewhere in memory.

There are differences among various Android versions in how the encryption key is derived from a passphrase or PIN, but all versions use the dm-crypt block-level disk encryption service of the Linux kernel. (Unlike iOS, Android doesn't use file-level encryption or multiple encryption key levels; on iOS, some keys are dropped as soon as the screen is locked, rendering some files inaccessible.)

This means that the files on disk are always encrypted, but the kernel will transparently decrypt them for any application that has sufficient file system privileges to read them.

Basically, the security of a device in such a state (locked screen, disk encryption key loaded in kernel memory) depends on the presence or absence of any security bugs in the Android lock screen or any installed application that can be remotely or locally exploited by an attacker; in that respect, there is no difference to an unencrypted device.

However, encryption protects against all attacks that require rebooting the device: As soon as the power is cycled, the encryption key is wiped from memory.

As commenters have noted, it should be added that an attacker with physical access to the device has more opportunities to gain access to the key material in memory than just exploiting kernel or application bugs: They could physically or logically extract the DRAM contents (which contain the Kernel memory and thus also the key) or gain access to debugging facilities of the system (assuming that they are not disabled).


How to bypass htmlentities() function in PHP to get an XSS?

From the context you provided, this filter appears safe.

Your output is in the data state (outside of any tags or attribute values). Therefore an attacker would need to inject at least an opening angle bracket (<) to introduce new HTML code.

Since htmlentities() converts all opening angle brackets to their HTML entity representation (&lt;), there is no obvious way to bypass the filter.


Can canvas hash be used to track me and ruin my anonymity?

Canvas Fingerprinting
The technique you are referring to is Canvas Fingerprinting.  It is one of many possible methods available for website operators to try to identify and track users without cookies.  The reason for this, of course, is because cookies can be cleared, or even "tricked" by things as simple as switching to a private (aka incognito) window.  The idea here is that the website uses javascript to try to look at something more permanent than cookies.
For a very short summary, Canvas Fingerprinting asks your browser to draw a standard picture, and then takes a hash of the results.  Different operating systems, browsers, hardware, etc... will result in slightly different images. As a result the hope is that one particular user will always have the same hash (even if, for instance, switching to an incognito window) while different users will have slightly different hashes, allowing the website to continue to track users even if they clear all their cookies.
Can you be tracked?
In practice canvas fingerprinting isn't perfect, and there probably aren't enough different combinations of "things" to uniquely identify users based on canvas fingerprinting alone.  However, canvas fingerprinting is only one possible avenue to uniquely identify users, and more intelligent browser fingerprinting can be very successful in identifying users.  Here is a website that actually measures how "unique" your browser configuration is, and therefore whether or not you can be tracked without cookies: https://amiunique.org/fp.  You'll notice that canvas fingerprinting is something they check, but it is only one of literally dozens of data points they use to determine uniqueness.
In all likelihood you can be reliably identified and tracked without cookies.  This doesn't mean that YouTube knows who you are just because Amazon does.  However, (to use them as an example), it does mean that if YouTube wanted to, they could continue to track you even if you log out, clear your cookies, and switch to Incognito Mode.  Note that I only use this as an example: I have no idea if YouTube or any particular service provider attempts to perform such tracking.
VPNs
Finally it's worth a mention that a VPN has little bearing on this conversation.  A VPN just changes your IP address, which isn't something that is typically used for tracking anyway - for many users an IP address changes frequently.  Also, switching to a VPN doesn't provide you any anonymity for services you were already using, since they can continue to track you easily if you don't clear your cookies.


Getting the uploaded file path without knowing the uploading destination

The destination a file is saved to is completely dependent on the application. Even if you could guarantee that a file you uploaded was executed, the file could be stored in a chroot environment and not know its actual location.  That said, you may be able to determine the path for a particular application.

The server will often tell you the path it uploaded to. For example, if you upload an image, find a webpage that contains that new image and find its url. It may be RESTful and not a direct file reference, but its a good place to start.
Look at the source code of the application. If you are looking at an open source application, go look up its source code to see where it stores files. For example, wordpress typically stores files in ./wp-includes/uploads/<date>/file. Determining this for one wordpress site can tip you off too multiple sites.
Try to create error messages. If you can crash the app and force an error message, you may be given information about where files are stored. Some things to help with this would be to include filenames either too long or contain invalid characters for a particular filesystem.
Attempt directory traversal attacks. If you can find a base reference to a known file such as /etc/passwd, you can start guessing other filenames and paths. This is made very easy if the application allows globs for filenames.
Check the robots.txt file. Some applications tend to restrict robots from crawling user uploaded content, so be sure to check the /robots.txt file for unusual entries.
Try a program like dirbuster. Note: dirbuster is super noisy and process intensive for the server.
Reference an image on a webserver you control, and check referrer headers. This can leak the URL of the page being executed. Note: for HTTPS sites, you'll need a HTTPS website.


Can you extract the encryption key of a computer with full disk encryption via malware?

is it possible to extract the encryption key remotely via malware out off the ram memory, and if possible, how come that the law enforcement does not use this method instead of a cold boot attack?

Of course it is possible. The malware requires to achieve privilege elevation ad access the encryption driver's memory; both things can be made difficult, but are by no means impossible.

Why law enforcement doesn't use this method (which actually does not require stealing any key: usually when the FDE is unlocked, the disk is accessible by any process, malware included, so the problem is just how to exfiltrate the purloined information): who says they don't? Where I live we got a nice scandal not too long ago, whereby a software firm got hacked that worked for various governments. They developed what was, for all intents and purposes, targeted malware.

Cold boot attacks and malware aren't mutually exclusive - you may have both at your disposal, and employ whatever best suits the specific case at hand.

From a legislatory point of view I believe that cold boot attacks are considered equivalent to a seizure, while malware installation is more of a gray area: it is somewhat equivalent to an ambush or check point, but it also entails altering the targeted system, which in some cases may render any evidence gathered utterly unusable - the equivalent of forcing open a suspect's door lock. Yes, law enforcement can enter at any moment, but so could theoretically anyone else, making any evidence questionable at last.

For example, if the malware allowed remote control of the targeted system, care should be exercised to ensure that no unauthorized access to the malware is then possible by parties unknown, for purposes of planting the very evidence the malware might then turn out.

Finally, the malware might be detected and even subverted, making it less desirable from a law enforcement's point of view.


Any reason to use bcrypt, pbkdf2, scrpt for other things than passwords?

The password-hashing functions (and password-based key derivation functions, in the case of PBKDF2) are designed to cope with the low entropy of passwords: they start from a bad situation (initial secret is vulnerable to a practical exhaustive search) and apply salts and slowness (to prevent parallel/precomputation attacks, and to make exhaustive search slower) so that this badness can be tolerated to some extent.

If your initial secret has sufficient entropy to withstand exhaustive search, then using a password-hashing function is unnecessary. If you have a secret 256-bit key which was generated properly, then bcrypt or scrypt or whatever will not do any additional good. On the other hand, if your initial secret has low entropy even if it is not a "password" per se (e.g. some biometrics-derived value, assuming you could find one that is somewhat secret and can be turned reliably in a value which won't move too much for a given individual), then "password"-hashing functions will be an appropriate tool.

The core functionality of password-processing functions like bcrypt is to convert a low-entropy input value in a non-regular format into a nice hash value (for verification) or symmetric key (for symmetric cryptography) in a way which improves practical resistance to exhaustive search (which is feasible due to the low entropy). "Passwords" are just a very common case of "low entropy secret with a non-regular format".


Which would be the best "keyfile" for KeepassXC and/or Veracrypt?

to be honest, there is no Best one.
Its all about keeping the file safe, and keeping access to it.
I recommend using a flash-drive with a few (strategically dispersed) copies.
as for the entropy of the file it self, size beats all. but does cost more memory to decrypt. the algorithm that uses the key-file will hash-up the source data anyway so do not worry to much about the entropy of the file itself. just do not make it predictable what file it is, and ensure you can not just lode said file.
and a file is only 1 Factor for decrypting, you are better to add another (something you know or something you are).
the key file represents something you have (together with the database/encrypted file itself)


Warning message about Git on IE 11: "a website wants to open web content using this program on your computer"

As it often happens IE does not fare well with certificates of other authorities. Basically your IE does not recognize "The Git Development Community" as a valid issuer of certificates.

If you are still unsure, you could do a research on the community, or try to upload the screen shot the same way you did it earlier.

Using an already proven and working way to do something is always preferred, but I would not worry too much over this particular instance.


How can 2FA be bypassed if I set a number which is unknown to everybody?

As long as you use a different secret phone number for each site the risk is probably low since only you and the site know the phone number. But both might leak it anyway: the past has shown that even if a site claims that it uses the phone number only for 2FA it might actually use it for different purposes and might share it with others.

If you have more sites you would need a different phone number for each site though because otherwise the risk of leaking the secret number will greatly increase. Obviously this does not scale since the phone system and the phones are not designed for this.


What is the best way to go about generating a “token” for user authentication

Short version:
Tokens should be either completely random, or cryptographically signed data (either asymmetric signature algorithm such as RSA or ECDSA, or message authentication code such as HMAC) using a key only the server knows. In the latter case, everything except the signature can be whatever you want (including simple human-readable text), but there are standard formats with existing libraries and I recommend you use them.
If you want to go the "random data" route, it's sometimes a good idea to store a hash of the token server-side, and hash the user-submitted token before validation (this is an easy way to avoid timing attacks on the check).

It sounds like you're trying to re-invent the "access token + refresh token" model. Leaving aside the probably-irrelevant stuff (why do you have a Node server sitting between your users and a PHP back-end?), it sounds like you're trying to develop some sort of long-term access token.
In theory, this is trivial; just generate a securely random string of bytes - 16 bytes out of /dev/urandom is fine - and then hex- or base64-encode that and use it as the access token (provided to the client, and the client transmits it with every request). The server maintains a dictionary in memory of user sessions and, upon receiving the token, looks it up in the session dictionary to retrieve the user info. The sessions have an expiration (possibly known to the client, but enforced by the server after which the user needs to actually log in again, but the expiration can be years or decades away if you really want it to. The server should also support invalidating a token (logging out) on demand, before it expires.
In practice, the trivial approach doesn't scale. First, anything that requires storing state on the server gets expensive when you have lots of users, especially if the sessions are long-lived. Second, this breaks down when you switch from a single back-end server to a cluster, because now you either need to cache sessions across the whole cluster and keep them in sync, or you need to route each request to the correct back-end server in the cluster (the one that has the relevant session). Both approaches are possible but both kind of suck.
The common solution, then, is to put as much state as possible on the client rather than the server, but sign it with a key known only to the server so a malicious user can't modify their session state (for example, to impersonate another user). This is typically done using a JSON Web Token, abbreviate JWT; these are a standardized three-part format for tokens that encompasses metadata (issuer, expiration, etc.), session data (user identity, permissions, anything else you want), and a signature over the other two parts (to prevent modification). The great thing about JWTs is that they require no server-side session state or DB lookups at all - if the token is within its validity period and the signature checks out, you can trust all the data in the JWT - so they are great for scaling. The problem with JWTs is that there's no good way to revoke them or dynamically lower their privileges; because the server stores no session state, it can't tell when you want to modify a session or end it prematurely.
The solution to that last problem is to make the JWTs very short-lived - typically a few minutes - and add "refresh tokens" (which is basically the random string mentioned above, stored in the DB on the server side). The refresh token is only used when a JWT is expired, or possibly just when it will expire soon, and serves as a long-term token that can be used to retrieve an updated JWT. While the JWT can be validated without needing a DB lookup, refresh tokens can't; they are stored in the DB along with any other relevant information. However, a user might make hundreds of requests that use the JWT in the time before needing to refresh it, so the load on the DB is still very low compared to a session lookup on every request, and you still avoid the state synchronization issue.
The total process looks like this:

User visits login page, provides credentials.
Server validates credentials, generates a refresh token and an access token (probably a JWT) back to the client.
Client includes the JWT with every request for a few minutes, allowing the server to keep track of session state without needing to store that state between requests.
Client periodically uses the refresh token to request a new JWT, which will be valid for a few minutes more.
If the client goes away without logging out, the JWT will expire but the refresh token will remain valid, so the user can resume their session without needing to log in again just by using the refresh token (as in #4).
If the client logs out (or the session is otherwise terminated for some reason), the refresh token is deleted from the DB. The user could in theory continue using the access token (JWT) for a brief time, but can't refresh it any more and would need to log in again.

With all that said... you should seriously consider using some existing authentication and session management library, rather than trying to build your own. Not all of them are good, but some of them are... and most (though not all) are written by people who didn't need to ask this question. For example, "salted and hashed" is not sufficient for password storage. You need a slow hash function, ideally one explicitly designed for password hashing. Using a well-reviewed open-source library will save you from needing to know all this stuff, and avoid common pitfalls, while also saving you development time.
At the very least, if you do use JWTs, use a library for them. Generating and checking random tokens isn't too hard to do securely (though ideally you do want to avoid things like timing attacks in the string comparison), but more complex token types with digital signatures and so on should be handled by library code. Honestly, though, if you have to ask "completely random" vs. "a combination of letters+numbers", you should let other people handle this.


IP Addresses not showing up in Facebook login history

Let me split your question into three different questions.

  Is there a way they can hide their IP address?

Yes it's possible to hide your real address from other people or companies. You just need to use a VPN and switch to your desired location. It's that simple. If you want to read more about VPNs I got an interesting article here

  Does Facebook only show most used IP addresses?

No, Facebook lists all logins chronologically. You just need to login and navigate into the settings. After that go to "Your Facebook Information" > "Access your information" > "Security and Login Information" > "Logins and Logouts" now you can navigate down and on the last entry you will see a list of all logins. Maybe this helps you.

Note: I think you can't find the full log because you are only at Security and Login but there is only a list of currently logged in devices!

  How can we find out for sure?

If you find different IP addresses and login timestamps in this log you will know that you didn't log yourself in. Maybe you could look up these IP addresses and see that it's not even in your country, but don't trust it. As mentioned before it's possible to use a VPN to make it look like the IP is from your location.


I was planning on user AES256 to ensure the client can't change the value of the cookie.

Encryption provides confidentiality, it does not provide authentication.

If you do not want users to see a session data value, then you should encrypt then authenticate the value. This prevents a bit flipping attack from changing the value inside of the encrypted token because the keyed hash will no longer match if any bits are swapped.

If confidentiality is not required, then you can simply authenticate. For example, you could use a HMAC over SHA-256. This will show the end user what the value is in cleartext, however they will not be able to change the value because they will not be able to recalculate the keyed hash value without the key.

e.g. Your cookie would be set as follows:

Set-Cookie: Session=Username=admin&expires=20150809104100&hash=7C2CD7DB7DF4055E782E3A5F70487FEB9A5CABEED3FB70F5D8772586FD8B2759

Expires prevents a user from saving their cookie offline for later use when they are not an admin because the hash is calculated over expiry too:

Username=admin&expires=20150809104100

You can use this site to verify this (key used was stackexchange, however you should use a cryptographically secure pseudo randomly generated 128 bit key).

However, there is an internet standard technology for doing this already called JSON Web Tokens. The HS256 algorithm will generate the client-side token value calculated by HMAC over SHA-256.

If you want encryption as well choose A128GCM - note that a 128 bit key is sufficient for your data - a 256 bit key using AES-256 is slower and unnecessary. It may even be less secure as there are significant differences how AES processes a 128 and 256 bit key.

As JSON Web Encryption only supports authenticated encryption algorithms, this would also prevent bit-flipping.


Recovery plan in case of lost Android smartphone with Google Authenticator?

First make sure nobody can abuse your codes. This may be even more harmfull than you not being able to login for a short time. So encrypt your phone and your external SD card if data is stored there. This requires that you use a PIN or password to use the phone. So nobody can use Authenticator without knowing that PIN. Don't use 0000 or 1234 but something complicated and easy to type that is long enough to make it impossible to break by hand.

Use backup codes, and you can use a backup phone number for Google login, possibly for other logins as well.

Root your phone, use Titanium Backup to backup your phone, including apps like Google Authenticator, including user settings and data. When you restore this - like in a VM - you can keep using your 2FA like normal. Backup to a local computer, and backup to an encrypted drive if you need the security. Keep multiple backups at different locations if necessary.

Create an Android VM, install Google Authenticator on it. Make new syncs. If you want to protect this VM, install the virtualbox disks on an encrypted disk.

Update

Lately I use the Authy app, which makes it possible to make backups and which can be used as a Chrome app.