Remotely fingerprint AV software on LAN machines?

There are two ways to detect this, Passive or Active.

Passive

This is what Iszi was referring to. If you can get yourself in the data stream you can glean lots of information. Using flow analysis you can watch for machines making connections to known update servers. So look around at some AV products, get a list of IP addresses from which they serve their updates, and then filter on some of the common data transfer ports. For AV this tends to be either HTTP, both 80 or 443 or FTP.

If you have access to the data stream directly, whether through a tap or span port, you can do some deeper analysis. Here, you can actually troll through the communications channel to look for signature bundle downloads. Depending on the vendor you may even be able to get exact product and/or version numbers from the UserAgent or filename of the signature bundles.

Additionally, if you have an IDS/IDP in place, you could likely construct your own signatures to look for this kind of behavior. Or, better yet, your vendor may even provide some. For example, Sourcefire ships a very large contingent of "Policy" signatures that allow you to look for corporate policy violations such as browsing job search websites, performing Google Images searches with SafeSearch disabled, or using Skype. You may be able to find application signatures for AV in a package like this.

Active

This is what you really want, to log into the systems themselves and check the software inventory. Being able to do this is highly dependent on your organization and how how much control you have over the client machines. If you have administrative access to the systems, you can remotely log in and pull whatever information you want. Nessus, for example, given Administrator privileges will perform a full software inventory. Or, the same information can be gathered through SCCM. You can always resort to writing a WMI a script to remotely poll, but there are so many better tools out there now, that you shouldn't have to.

If you're lucky enough to have a NAC system in place, you could also perform this polling as part of your pre-authentication posture assessment. Of course, if you're lucky enough to have a fully functional NAC in place, then you're probably lucky enough to have some of the other methods available as well.


Storing private keys for updates to remote device

I need to check if the new software has been generated by a "trusted"
source, ie me.

This means you need a single key - your key. You embed your public key into each device. When later on you upload an update to each device, you sign the upload package with your private key. Each device verifies your signature using your public key that you have embedded into the device.

If my private key is lost for whatever reason, I lose the ability to
update any of these devices.

Correct. I would suggest you to proceed like CAs do. Often the end-consumer certificates are issued not by the "top level" CA, but by some "intermediate" CA.
So you can create a "top level" key pair and corresponding certificate, and embed public key (or certificate) into each device. You should keep this private key in a very secure place.
Then let say every 3 months you do following: You generate a new intermediate key pair, create a certificate which expires in 3 months. You sign this certificate with the top level key. You use this intermediate private key to sign any updates in the next 3 months.
Since you want to sign 1M units, it may happen that you lose the private key. In such case you just generate a new intermediate key pair (without waiting 3 months), sign it with the top level key, and use this new intermediate key to sign updates from now on.
Each device should verify the packages as follows:

Check if signature matches the certificate attached to the update.

Check that certificate is issued by the top level key, which is embedded into device.

Check certificate expiration date.

Of course, if you lose the top level key, you will be blocked. But since the top level key will be used rarely and kept much more securely than a key used for 1M signatures, the chance to lose it essentially lower.
I'd suggest that you consider also revocation of the keys. It can be needed if a key used to sign updates is stolen, or if you just suppose it is stolen. You may want to prevent the attacker from uploading malicious updates signed with your stolen private key. In such case you can have a CRL (certificate revocation list) on each device. In case you want to declare some key as untrusted, you generate certificate revocation info for the compromised key and push to all devices. Then generate a new intermediate key pair. In case the device obtains a package signed by a stolen key and finds this key in its CRL list, it should not trust such signature and should reject such update package.


Advice if safe from mail header injection PHP

The mail() function uses an additional_headers parameter, which could be used to set other headers. You just have to separate them by a newline character.

Here is what you have to check:
Let's say, that you  have got an input which allows you to type To: e-mail. You type there eg. mymail@stackexchange.com and the e-mail is sent to that address. Try to inject another header, let's say Bcc::

mymail@stackexchange.com%0aBcc:anothermail@stackexchange.com
mymail@stackexchange.com%0d%0aBcc:anothermail@stackexchange.com

You shoudn't forget to check if you code isn't vulnerable to SMTP Injection. Let's say that your script generate SMTP commands:

MAIL FROM: first_email@stackexchange.com
RCPT TO: second_email@stackexchange.com
DATA
From: first_email@stackexchange.com
To: second_email@stackexchange.com
Subject: Important e-mail
text

.

This commands could be generated by request: ?from=first_email@stackexchange.com&Subject=Important+e-mail&message=text.

However you could try to inject another commands into Subject parameter as follows: ?from=first_email@stackexchange.com&Subject=Important+e-mail%0d%0a%2e%0d%0aMAIL+FROM:+attacker@stackexchange.com%0d%0aRCPT+TO:+victim@stackexchange.com%0d%0aDATA%0d%0aFrom:+attacker@stackexchange.com%0d%0aTo:+victim@stackexchange.com%0d%0aSubject:+Bum%0d%0ainjected%0d%0a%2e%0d%0a&message=text
If your webapp is vulnerable, then it'll generate two different e-mail messages:

MAIL FROM: first_email@stackexchange.com
RCPT TO: second_email@stackexchange.com
DATA
From: first_email@stackexchange.com
To: second_email@stackexchange.com
Subject: Important e-mail
text

.
MAIL FROM: attacker@stackexchange.com
RCPT TO: victim@stackexchange.com
DATA
From: attacker@stackexchange.com
To: victim@stackexchange.com
Subject: Bum
injected

.


How to prevent spam message sending to my Android web services

As answers to this question explains, your two main options are rate limiting and captchas. You say you dont want to use these, because rate limiting can be circumvented by creating multiple accounts and captchas are bad for the user experience.

To get around these problems, how about this:

Rate limit posts per account
Require successfull captcha to register a new account
Develop routines to easily block accounts that are found to spam (e.g. by letting users flag spam posts)

The captcha on account creation shouldn't be to intrusive since a user only has to complete it once, and it makes it harder to circument the rate limiting by creating new accounts. If you need stricter measures, require a captcha on each post until a user has provided some non spammy (unflagged) posts.


Bypassing file upload restrictions on php server

To execute injected php code it should be possible to call targeted file directly and its extension must be in the list that server may handle for. By default it is *.php
It is possible to include any file into other php script on the server in case LFI vulnerability is exploitable in the code.


How much of your web browsing behavior is VISIBLE to the administrators when you're behind HTTPS or VPN?

A firewall is a device that sits between the Local Area Network (LAN) and Wide Area Network (WAN).  I stole this picture from the Firewall wiki page.

Rules are setup on the firewall based on IP and port numbers.  You can restrict subnets of IPs from using certain ports.  Rules for both incoming and outgoing communication is generally necessary.  There can also be deep packet inspection where the firewall goes deeper into the networking layers for a more fine grain filter.  But this is all a firewall is, a filter.  No requests to the firewall happen.  Packets just get sent through, and some (normally most) will be blocked.

The thing about HTTPS is that the domain name is still visible to the firewall in a couple ways.  DNS requests for the domain are visible.  A firewall can block DNS requests to specific domains.  The URL is also visible in certain SSL/TLS extensions, and the server certificate.  A firewall could inspect this application data, and block based on the domain provided by the server's certificate.

You're correct.  Attempting to use a proxy or VPN might be blocked by the firewall if the rules are setup to block them.
I'm not really sure what the question is here.  But yes a VPN must be allowed by the firewall in both directions.

If you're using email protocols (IMAP, POP3, SMTP) then those rules must be allowed by the firewall.  If you're checking Gmail, then again the domain can be blocked by the firewall.


I'm going to say no. While SMS is a generally accepted 2nd factor, there have been a number of cases where an attacker has used social engineering to break into a user's carrier account and pick up the verification code and use it. So to answer your question, is it 100% secure aside from guessing, no.

EDIT: To add to this information, even NIST is removing SMS as a valid 2nd factor from their standards for security.


What does "Server Temp Key" mean in an openssl output?

The ephemeral (= temporary) key used for Diffie Hellman key exchange.

You should configure it to be as strong as the key for the certificate.

DHE with 2048 bits provides 112 "bits of security". ECDHE with 256 bits provides 128 "bits of security". So ECDHE over P-256 is more secure than 2048 bit DHE. There are also fewer bad implementations of ECDHE and TLS allows to negotiate its strength (the curve), which is why Google Chrome removed support for DHE so you should switch to ECDHE (i.e. make the server support and prefer ECDHE).


One of the iOS projects I’ve been working on required communication with printers over SMB. As it turns out, iOS has absolutely no support for SMB. There are solutions for Linux, and Android, but porting any of these to iOS appeared to be quite an ordeal. After multiple attempts at that, I ended up implementing SMB myself. Then I extracted that code as a separate project (smb4ios). Here is some documentation from it, in case you’re interested in how SMB works.

First of all, what’s SMB. Initially (like in 1980’s) it was a protocol to access file shares. Since then, file shares evolved a lot, SMB however didn’t. Why is it still relevant then, you ask? Because it’s an integral part of Windows. There’s no “SMB standard”, there’s only “the way SMB works on Windows”. So, when we speak of SMB, we are interested not only in SMB itself (file system layer), but also in NetBIOS (transport layer), NTLM (authentication), and RPC. They all are kind of grown into each other by now, forming a monstrous layered ancient onion creature. So, from implementation perspective, you’ll have to deal with all of them simultaneously.

Let’s start with TCP. TCP is a low-level network protocol. When you want to send some data to network and other computers, you create a TCP socket, connect it to an address, and jam the data there. The socket takes care of packaging and delivery.

SMB is a transport protocol, kinda like HTTP. You should know that HTTP is basically when we send some extra information over TCP to describe what kind of content will be exchanged. SMB is the same, but over NetBIOS.

NetBIOS is basically a really old version of TCP. OSX and iOS do not have an implementation for it. Fortunately, it’s simple and can be implemented over TCP. So, this code is SMB over NetBIOS over TCP (aka NBT).

SMB was also called CIFS on some point, they are the same thing. There’s also SMB 2, which doesn’t work on Windows XP, so is irrelevant to me.

Now, first thing we need is to find the SMB servers in our network. That’s done by NetBIOS name queries. Basically it sends an UDP broadcast to a broadcast address (such as 255.255.255.255) and asks “who has this name?”. Then someone in the network may answer with his IP. There’s a main guy in NetBIOS network with a pre-defined name “master browser”, we ask for his IP first. Then we can ask him who else he knows, and that’s how we get domains and groups and server IPs.

Now that we have an IP, we can connect a TCP socket to it and run SMB messages.

First thing the server will want is for us to login under some user. You do the login by sending NTLM packets within SMB Session messages.

NTLM is when you use extremely complicated cryptography to encode and decode username, password etc. I used a 3rd-party library for that (see link below).

After login, you have basically opened a remote session with a Windows machine, and can run Windows API functions just like you normally would, if you were a Windows C++ application. You do that by sending RPC commands within SMB Transaction messages.

In short: RPC is a Windows API function code plus parameter buffer, which you wrap in SMB message. You can call functions like EnumAll, OpenPrinter, etc.

More details: Normally, to call a function with certain parameters, you need to push these parameters to stack. Which logically means all the neat C structures and variables you, the human, work with, are packed into a memory buffer and then that buffer is unpacked into the same pattern of structures and stuff inside the function (not what really happens). In RPC, you just provide the function code and the buffer. Which for some people means you should replicate the C structures and then pack them the same way. But in my opinion, nothing stops you from just dumping your data straight into bytes, as long as the end binary result is the same.

And that’s how it works: you find IP with NetBIOS, connect via SMB, send NTLM authentication, then run RPC commands. Use Wireshark, it’s a huge help, and I would be nowhere without it.

References:

SMB: [MS-SMB] at http://msdn.microsoft.com/en-us/library/cc246231.aspx
RAP: [MS-RAP] at http://msdn.microsoft.com/en-us/library/cc240190.aspx
DCE-RPC: http://pubs.opengroup.org/onlinepubs/9629399/chap12.htm
NetBIOS: RFC 1001 and 1002 (I dare you to actually read it and not go insane), http://www.ubiqx.org/cifs/NetBIOS.html
NTLM: http://www.nongnu.org/libntlm (the library I used)


Is it possible to transfer malware/viruses through a KVM Switch, from one computer to others?

Theres 3 ways a USB KVM switch could infects its "neighbour":

1: Either, if the KVM switch supports firmware upgrade over USB without any physical button press to put it in "upgrade mode".
Then a BadUSB style of attack could be used to reprogram the KVM switch to send commands or similiar.

2: If the KVM switch's USB host accepts anything, including USB drives, and you have connected a USB drive to it. If the "bad" computer infects the drive, and you then push the button to switchover, the infected USB could also infect the "clean" computer.

3: If any device behind the KVM is vulnerable, for example a keyboard or mouse, to BadUSB, and then the device is "infected", and you switchover.

However, a KVM switch that uses PS/2 output, I would say is 100% safe. Even if it's console input is USB.
Eg, the following 2 types of KVM switches are safe:

2 USB ports + 1 VGA/DVI/HDMI port --> 2 VGA/DVI/HDMI ports and 2 purple PS/2 and 2 green PS/2
1 purple PS/2 and 1 green PS/2 + 1 VGA/DVI/HDMI port --> 2 VGA/DVI/HDMI ports and 2 purple PS/2 and 2 green PS/2

These types of KVM switches are safe, even if you use a PS/2 to USB adapter, and/or a USB to PS/2 adapter to connect to it, as the PS/2 lines cannot transfer malicious data, thus no malicious data could be transferred over at button-press.

Yes, the PS/2 to USB adapter connected at the "bad" host end, could of course be infected with "BadUSB" malware, but then the infection would be contained to that host, as the "clean" computer has its own adapter, and the transfer to the KVM switch from host are PS/2.

PS/2 devices that are firmware-upgradeable over the PS/2 line without having to switch to USB mode or similiar - i would say, you can count them on one hand.

Image ports, like VGA, DVI and HDMI, are fully safe, as they cannot mount or send commands to the computer. They can send identification strings to the computer, like the manufacturer name of the screen and its supported rates and resolutions, but to actually compromise anything, the device would then need to take advantage of a exploit in the host computer like a buffer overflow or similiar AND the monitor must be firmware-upgradeable over the image port, so the malicious payload can be installed.

Pretty unlikeably that the computer monitor would be firmware-upgradeable via its picture input AND you get a malware in the "bad" computer that supports infecting the monitor AND the "clean" computer is vulnerable (Buffer overflow or similiar) to bad strings sent via the image port.


Certificate authority has changed for personal website - but I haven't changed anything?

What does this mean?

The certificate changed, as shown by the different SHA1 hashes. The MD5 hash field is no longer relevant as Firefox deprecated them.

  Can I trust the certificate?

No, if it changed without the admin (ie. your) intervention, you should be highly suspicious.

  How can I check that my certificate is still valid, created by me, not changed by someone or something else?

You should compare the new certificate with the copy/hash you kept locally when creating it. Because you wrote it down, right?

  Should I recreate it?

Not necessarily. If your certificate were compromised, it wouldn't have been detectable. OTOH, if you're not sure which certificate you created, generating a new one would be appropiate.

.

Although this shows that there was a man-in-the-middle attack on you/your website, probably the new (forged) certificate was generated by a captive portal or even your router, and not someone targetting you at the network level.


Java vulnerability: What about OpenJDK + IcedTea?

Java 7 and OpenJDK share a lot of common code, so, as a general rule, security issues in Java 7 also apply to OpenJDK. In that specific case, it seems that the vulnerability was reported in the Debian OpenJDK package, so yes, they are vulnerable. See this question on another stackexchange site. Since Oracle seems to have fixed their JDK, chances are that the same fix will appear in OpenJDK in a few hours or days.

On the bright side, if you use OpenJDK and IcedTea, then chances are that you use Linux. Malware authors rarely target Linux systems, because there are not that many people who browse the Web from a Linux machine, and there are a lot of different "Linux systems" which make it difficult to write a piece of binary code (such as malware) which will run on most of them (the Linux ecosystem relies on source code distribution and per-distribution packaging, rather than real binary compatibility). Therefore, malware authors usually deem Linux "not worth the effort". This goes a long way towards explaining the scarcity of malware on Linux.

My gut feeling is that the fix will be available on the normal update channels way before any Linux machine is actually attacked in the wild (but you do not have to trust my guts -- personally, I don't).


Be careful, you should not confuse keys used for encryption/decryption and keys used for signature, since there usage is different. So the key couple A-pub/A-priv is used for signature only, while the key couple B-pub/B-priv is used for encryption only. Be also careful that you should sign the ciphertext and not the plaintext, otherwise having the hash of the plaintext send along with the ciphertext is pretty bad. Likewise, having B deciphering the message before being able to check the signature is bad.

Thus:

Alice should hash the ciphertext, not the plaintext, and sign with her private key (A-priv) the hash of the ciphertext
Bob will first use Alice public key (A-pub) to verify the signature of the message by comparing it with the hash of the ciphertext. If the signature is valid, Bob will then use his own private key (B-priv) to decipher the message.

(you also have a typo at you point 4)


The sauce is not an extra hoop. The attacker doesn't gain any benefit from knowing the sauce in advance. The salt prevents him from making useful precomputations anyway.

The optimal iteration count is determined from a compromise between your available computing power and the computing power available to a typical attacker. Sure, it's hard to quantify it precisely, but nonetheless randomization can only make the resulting value less optimal.

If the attacker wants to get a foothold into the organization and doesn't care much which account he breaches, the accounts with the lowest sauce are likely to fall first (though password complexity will have more influence). The randomization hurts more than it helps in this scenario, since it makes the weakest link weaker without a commensurate compensation by gained processing time.

Your random sauce is extra complexity, even if i's only a little bit. Complexity is the enemy of security, it's one more thing you might accidentally get wrong (e.g. a too-low minimal sauce).

In conclusion, I recommend a fixed iteration count, changing from time to time as processors get more powerful.


As Steve and Avi have asked, you are either referring to passwords for users of a website/web application or passwords for the system. Typical protection for the two options:

Passwords for web application / web site:

Stored in a database which is separated from the web DMZ by a firewall, not on the web server (which is in the web DMZ.) Access control is both on the firewall, and in encrypting the database or hashing the passwords in the database

System passwords:

Passwords hashed in /etc/passwd or /etc/shadow or SAM file or equivalent, and password file has access controls limiting access to root or system accounts only.

There are other options, but these are by far the most common.


How to crack a list of hashed passwords given their possibilities

What you want is called a rainbow table and it's exactly that; a pre-calculated map of keys and their corresponding hash values. It's also really huge. Being said, if you've got a spare machine with the disk space, or are willing to pare down your example cases, you can generate this data rather easily on the fly with any language's hash function. Just generate your strings, hash them, and store them as a key-value pair or in a simple db.


Get info of computer (logged in username) secretly using USB drive

As you probably know,

  The SET Infectious Media Generator creates an autorun.inf file and a Metasploit payload Source.

Since you don't want to use the Metasploit payload, you can simply create an autorun file and a Powershell script for information gathering. There are different types of information you may want to collect, from the logged on user to the MAC address and so on.

A more sophisticated attack (which would probably require additional permissions) would involve dumping the RAM of the targeted user and looking for particular strings, such as password. I'm not an expert in this topic, but this might be done by using tools which are typically used in live forensics.


How far should I go in protecting a user's SMBIOS UUID?

You can at least add application specific salt (hard-coded in the app), so building a rainbow table just for your small database is not worth it.
You can use a slower hash function (pre-compute the hash only once per app start).
Adding more entropy if possible for your application would help greatly.
If at all possible, do not associate the hashes with identifiable information, or make the association hard, for example requiring the user password to decrypt his UID hash. (for more suggestions, we would need to know more about what you need it for)

Shortening the hash may help in some cases but could be detrimental in other. IMHO it would not do much in a situation where the UID is associated with other information such as IP, or Name/Company.


If the connection is originating from your computer, you should investigate why

Determining which process is attempting the connection

There are several tools in the [Sysinternals Suite] that can help you understand what program is making the connection. The TCPView program may show you the attempted connection, but as I understand it, it is basically just a GUI on netstat, so you might miss the connection.

The process monitor (ProcMon) tool will capture many different kinds of events concerning network connections, the file system and the registry (and much more). This page has details about how to use ProcMon to trace network connections to the responsible process.

Additionally, you can use the new sysmon tool. This page has some details on how to setup and use sysmon.

Once you determine the process that is sending the connection, you can use Process Explorer to submit the program to Virus Total. Virus Total will scan the sample across a few dozen AV products. A non-finding of a malicious signature doesn't necessarily mean it is benign, but its a good start. Launch procexp.exe as Administrator, locate the process via it's PID and right click to select "Check VirusTotal".

Determining what the process is trying to send

Using a program like wireshark, you may be able to determine what the program is trying to send. If McAfee is blocking the connection then, then nothing may be sent because connection is blocked. However, if you can determine what DNS entry is being used (if one is being used at all), then you can edit your hosts file to your local host. You can then set up a temporary webserver, (I like using python's python -m SimpleHTTPServer 80) to allow the connection to be established.

Follow Traditional Malware Investigatory Practices

If you can't track down the network connection, follow traditional approaches to determining if your computer is infected with malware. This post has many areas to investigate. Further, you can use tools like volatility to investigate your computers memory. Volatility can be especially helpful if a rootkit has been utilized to hide processes.


What would you call an attack where authenticated user modifies other users information on web app?

...sounds to me like Improper Access Control.

From CWE-284:

  Description Summary The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

  Extended Description Access control involves the use of several protection mechanisms such as authentication (proving the identity of
  an actor) authorization (ensuring that a given actor can access a
  resource), and accountability (tracking of activities that were
  performed). When any mechanism is not applied or otherwise fails,
  attackers can compromise the security of the software by gaining
  privileges, reading sensitive information, executing commands, evading
  detection, etc. There are two distinct behaviors that can introduce
  access control weaknesses:

  Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for
  example, setting a password file to be world-writable, or giving
  administrator capabilities to a guest user). This action could be
  performed by the program or the administrator.
  Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g.,
  allowing the user to specify their own privileges, or allowing a
  syntactically-incorrect ACL to produce insecure settings). This
  problem occurs within the program itself, in that it does not actually
  enforce the intended security policy that the administrator specifies.

However, you don't mention how the actor is carrying out their attack - so I can only guess they are using GET parameter manipulation to impersonate another user.

In this case the actual attack would be "Parameter Manipulation" or "Parameter Tampering".


What SSD maker has implemented Secure Erase to spec?

Who are you defending against?

No, really, because remember, with SSD, there are sectors that go bad that are no longer writable.  With ATA Secure Erase, the drive is also supposed to erase the mapped-out bad blocks, but if the blocks are actually no longer writable, it cannot succeed.  You can't blame a vendor for not doing the impossible.

A custom firmware may be able to read back those sectors that have gone bad.  But your typical adversary does not have such a firmware, so again from who are you defending against?  And how much data will they actually be getting?

If you really need to make sure that your data is secure after you dispose of it, then never let unencrypted data touch the drive.  Encrypt your volume, and when you're done, just zero the drive and never look back.


Are there any disadvantages to encrypting the password hash?

First of all, every stored password should be hashed with a different pseudo-random salt.  Second, SHA-256 is not appropriate for storing passwords; instead, you want to use a key stretching algorithm, as has already been mentioned.  There is a lot more detail at Crackstation.

An encrypted hash is also called a keyed hash, and the key is sometimes called a "pepper."  There need not be a separate encryption step.  Instead, the secret key is part of the input to the hash function.  That can improve security somewhat.  There are two ways attackers can get a copy of your password hashes.  One is to compromise the storage mechanism, as with SQL injection.  In that case, a keyed hash can make it effectively impossible to retrieve plaintext passwords from the hashes because the key can be compiled in to a program or otherwise kept outside the password storage mechanism.  The other way is to compromise the OS itself.  In that case, the key is compromised, and is no longer an impediment against attempts to attack the passwords.

So, the short answer is yes, but you have to do the underlying work right, first.


If you are e-commerce and the user's card data touches your server (in memory or on disk) then you are SAQ-D.

You can reduce your scope to SAQ-A-EP if the payment form on your site does a post directly to the payment processor's API, but if the card data touches your server - even though it isn't stored- you are SAQ-D.

Remember that if you are level 1 or level 2 (based on transaction numbers) your QSA will have to sign this off and their interpretation is the only one that counts.


What bits of data is revoked in a CRL? Is it the hash(CSR) or hash(CSR + PKI signature)

Based on this answer from Thomas Pornin:

  Revocation is on per-certificate basis. What is revoked is the certificate (i.e. the binding between your key and your identity), not the key. Of course, if several CA have issued certificates that bind your key to your name, and your key gets stolen, then you would like all these certificates to be revoked. However, if one CA revokes your certificate for some other reason (e.g. you failed to pay a yearly "certificate maintenance" fee), then this has no impact on the revocation status of certificates issued by other CA, even if they contain the same name (yours) and the same public key (also yours) as the revoked certificate.


If you require your SQL Server (TCP 1433) to be accessible via the public internet and you do not know the IP addresses of your clients, then there is unlikely to be much you can do about this other than to:
- ensure that all accounts that have access to the SQL server have very strong passwords
- ensure you are installing the latest security patches for SQL Server and for your OS

However, if you require your SQL Server to be accessible, and you know the IP addresses of your clients (say your web host, or a third party that's sending you data) then you can use the built-in windows Firewall to allow access to the TCP 1433 to only the IPs you specifically allow.

A third alternative might be to move the port to something other than the default, but this is not security - only obscurity.


Why practical risk analysis tutorials do not exists?

Indeed, your point about publishing public risks on critical assets of an enterprise is probably the main reason why the practical side of risk management is not as visible compared to offensive security for example.
However, if you are interested in that particular subject, there are multiple resources that you can refer to in order to gain experience. For example, the book Security Risk Management is a great reference to actually start a risk management program for a company from scratch, it has a lot of real-life examples and concepts that can be directly applied.
You can also get certifications or courses from experienced instructors (for example CRISC) this kind of training will put you in very similar risk assessments situations so that you can gain tangible experience in information security risk management.


Quick question regarding suspicious disk space use:

This doesn't seem suspicious at all. As raz pointed out, Windows makes rapid estimates of space and then replaces that number with the real number after finishing calculations.

Also, all disks need to reserve space, but again, as raz mentioned, 32Mb is not unreasonable.


I need to generate a CSR on my HSM with a critical key usage of Non Repudation?

Each tool should be used for what it does the best. The HSM is great to protect a private key by allowing to use it without leaking it out the the hardware module.

But IMHO, the CSR generation and validation should be done before submitting a validated CSR to the HSM for signature only.


Does creation of dump data would be considered as vulnerablity?

... the attacker can dump your database through a simple csrf form,

A CSRF request alone will only cause the execution of some server side code in the context of a logged in user. The attacker itself is not able to access the results of this request, i.e. is cannot read the response. To get access to the server response you need attacks like Cross-Site-Scripting.

What you often can do with CSRF is to create a new user and then the attacker could log in as this user and access the database directly.


Covert channel algorithms is most commonly used as a name given to a set of algorithms used in IDS/IPS (Intrusion Detection/Prevention Systems) to detect, analyze and identify covert channels in TCP/IP networks, for example by probabilistic statistical analysis by e.g. using the Markov model TCP packet analysis, Bayesian inference and other algorithms, deterministic by static traffic analysis, rule set matching, or by several other techniques / algorithms that might be in place with various intrusion detection systems.

Suggested further reading:

Network Covert Channels: Design, Analysis, Detection, and Elimination (Serdar Cabuk, Purdue University - PDF)
Covert channels analysis in TCP/IP networks (Pierre Allix, IFIPS School of Engineering
University of Paris-Sud XI, Orsay, France - PDF)
A Covert Channel Detection Algorithm Based on TCP Markov Model (Jiangtao Zhai ; Sch. of Autom., Nanjing Univ. of Sci. & Technol., Nanjing, China ; Guangjie Liu ; Yuewei Dai)
A Robust Network Covert Channel Algorithm Based on Spread Coding (NIU Xiaopeng*, LI Qingbao, WANG Zuo)
An Approach to Analyze Covert Channel Based on Finite State Machine (Xiong Liu ; Dept. of Comput. Sci. & Technol., Tsinghua Univ., Beijing, China ; Jian-guo Hao ; Yi-qi Dai)


Elastix Asterisk CLI flooded with chan_sip.c / sip_xmit warnings

It appears that the system is doing a DNS lookup of the Trunk name possibly.


Is blacklisting IP addresses a waste of time?

Blocking a couple thousands of IP addresses will not incur significant load on your webserver. If you are using iptables, the overhead is pretty negligible.

I have implemented fail2ban on my server, and it blacklists everybody trying a bruteforce on my server. Portscanning gets the ban hammer too. It gives a temporary ban (I configured it to 6 hours), so I don't have an enormous list of blacklisted addresses, and the attacker gives up on my server way before the ban expires.

You can use fail2ban to protect Wordpress too, and Apache. If anyone gets too much HTTP-404 errors in a timeframe, ban them. If they send spam, ban them.

As the vast majority of the attacks today are not directed attacks, a blacklist will make the attacker (or bot) leave your server and attack the next on the list. It's not to make your server unbeatable, but to make it less interesting than the next on the list.


Every computer with a public IP gets this kind of attention permanently. There's nothing you can do to stop it (I once tried to complain to the provider owning the offender's IP, never got a reply and gave up). What you can do is to make sure you're well protected against a possible attack (this bot seemed to look for WordPress, but there are others looking for Apache, SSH, you name  it). A few rules:

Expose as few services as possible. If you don't need SSH, FTP, etc.,  disable it.
For the services you expose (the web server in your case) make sure you install security patches regularly.
If your service has some form of authentication (like WordPress admin page), be sure to pick a strong random password. Online bots usually check for default passwords and extremely weak combinations like root/r00t, but I wouldn't risk using any dictionary word, or anything shorter than 12-16 characters.
If you want to stop wasting resources on people who try to guess your password (assuming you have a good password) you can install Fail2Ban which bans an IP address for 10 minutes after 6 failed login attempts, rendering password guessing scripts impractically slow. Of course, you can configure the ban delay and the number of attempts to your liking.
For services which are intended for a specific group of users (you, your company etc), you can also use other techniques like port knocking and limiting access to IP ranges you are likely to use to access your services (your country only, your ISP, your work ISP etc.).


Corporate IT monitoring and access to user private data (keylogging? https data transmission?)

Ultimately if you are using a computer controlled by someone other than you (in this case your employer) they can get access to anything you process on that computer, including e-mails, passwords and pretty much anything else.

Whether they do or not is a different question. Depending on your location there may be legislation limiting what they can legally do (e.g the Data Protection Act and Regulation of Investigatory Powers Act in the United Kingdom).

Generally speaking I would say it would be unusual for a company to put key-stroke logging on their staff machines, unless perhaps that staff member is under investigation for something, even then the legality of that could be dubious.

On the Internet interception, it's possible (e.g. using something like bluecoat) for them to see inside SSL connections, but that doesn't mean they're looking at the content of your mails for anything other than malware...

I'd say that if you're not sure that you trust them to have this access the best option would be to only make use of your own computing devices for your personal activities.


Forced to install certificate on my laptop when using company WiFi. Risk?

In your use-case, there are many missing variables such as: what are they enforcing today? if your machine is domain-joined, are you able to work remotely and whether that is permitted by the company.
But in any case allow me to try and explain their side of things and than summarize the impact it may have on you:

Why they have requested you to install a certificate

Even in an BYOD model (or especially in BYOD model), the organization would need to validate that your machine is able to:

Access the internal services provided by the organization
Access to the VPN services from external locations

Assuming that they are publishing the internal "corporate" environment through Wi-Fi, it would be in their interest to validate that only authorized machines have access to the network. while user/password may work for authentication, it exposes them to brute-force attacks which are highly reduced while installing a non-exportable certificate.

Furthermore, some organizations that choose BYOD model still want to enforce some restrictions on machines (e.g. installation of an AV, machine compliance etc.) and if a machine is able to access the network without a certificate, there is no guarantee an employee will go, buy a new machine or have another machine from home that might be infected and connect it to the network with a user/password.

Also, in terms of MITM for internet browsing, as your machine may hold highly sensitive company data (as you noted not everything is made through citrix) they may want to validate no sensitive data is being sent using a Data Leak Prevention mechanism or validate no malware is downloaded to your machine.

  Will this give them any additional ways to monitor my machine over the old situation?

Yes. In case you are surfing through the company proxy, they will be able to intercept HTTPS sessions and inspect them. The difference is that for you the session will still look "secure" (the lock icon in your chrome).

You are still able to know if they have intercepted your traffic or not by clicking on the lock and seeing the certificate chain

  Will they for example be able to inspect end-to-end encrypted messages?

Depending you what you call "end-to-end" if you encrypt a file on your machine, and then send it away they will not be able to see the encrypted content. same applies to any GPG signed content or binaries.

  Is it a good idea to accept this kind of a certificate given the fact that I am a contractor and work for multiple clients?

I'm not sure how many options you have, but I would argue it's not a big deal as long as you spend your time with that customer doing only what they are asking of you, and making sure you don't surf the internet through their proxy while not working on their projects.

My suggestion would be to ask for some elaboration on the reasoning for the request and what they are aiming to achieve. In all countries under the EU, several states in the US (CA in example) and other countries around the globe this could fall under your right for privacy and they need to elaborate what is the business need for you to install the certificate.


What personally identifying data does does command line Git send?

This is really easy to test out.  GIT uses CURL for the clone and push/pull operations, and it uses one environment variable that will make it tell us everything what it is doing, so first let's do:

export GIT_TRACE_CURL=1

(That is the *nix way of doing it, but it works in the git shell that comes on windows as well)

The only problem with that configuration is that pretty much all free public git repositories (github, bitbucket, gitlab) require you to use HTTPS, which is a little hard to debug.  To avoid an extra proxy I simply created my own git server on localhost (that's not hard at all, even the official git documentation has examples of doing it).

git clone

I have cloned a repository that I call rc and got the following output (thanks to the exported variable above):

git clone http://localhost/git/rc > log 2>&1

The content of the log is:

Cloning into 'rc'...
21:30:48.175889 http.c:558              == Info: Couldn't find host localhost in the .netrc file; using defaults
21:30:48.177516 http.c:558              == Info:   Trying ::1...
21:30:48.177542 http.c:558              == Info: TCP_NODELAY set
21:30:48.177698 http.c:558              == Info: connect to ::1 port 80 failed: Connection refused
21:30:48.177722 http.c:558              == Info:   Trying 127.0.0.1...
21:30:48.177732 http.c:558              == Info: TCP_NODELAY set
21:30:48.178015 http.c:558              == Info: Connected to localhost (127.0.0.1) port 80 (#0)
21:30:48.178266 http.c:505              => Send header, 0000000186 bytes (0x000000ba)
21:30:48.178316 http.c:517              => Send header: GET /git/rc/info/refs?service=git-upload-pack HTTP/1.1
21:30:48.178327 http.c:517              => Send header: Host: localhost
21:30:48.178335 http.c:517              => Send header: User-Agent: git/2.10.0
21:30:48.178342 http.c:517              => Send header: Accept: */*
21:30:48.178349 http.c:517              => Send header: Accept-Encoding: gzip
21:30:48.178356 http.c:517              => Send header: Accept-Language: en-GB, *;q=0.9
21:30:48.178364 http.c:517              => Send header: Pragma: no-cache
21:30:48.178371 http.c:517              => Send header:
21:30:48.196881 http.c:505              <= Recv header, 0000000017 bytes (0x00000011)
21:30:48.196914 http.c:517              <= Recv header: HTTP/1.1 200 OK
21:30:48.196928 http.c:505              <= Recv header, 0000000022 bytes (0x00000016)
21:30:48.196936 http.c:517              <= Recv header: Server: nginx/1.10.1
21:30:48.196946 http.c:505              <= Recv header, 0000000037 bytes (0x00000025)
21:30:48.196954 http.c:517              <= Recv header: Date: Sun, 16 Oct 2016 20:30:48 GMT
21:30:48.196964 http.c:505              <= Recv header, 0000000059 bytes (0x0000003b)
21:30:48.196972 http.c:517              <= Recv header: Content-Type: application/x-git-upload-pack-advertisement
21:30:48.196982 http.c:505              <= Recv header, 0000000028 bytes (0x0000001c)
21:30:48.196990 http.c:517              <= Recv header: Transfer-Encoding: chunked
21:30:48.197000 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:30:48.197008 http.c:517              <= Recv header: Connection: keep-alive
21:30:48.197016 http.c:505              <= Recv header, 0000000040 bytes (0x00000028)
21:30:48.197024 http.c:517              <= Recv header: Expires: Fri, 01 Jan 1980 00:00:00 GMT
21:30:48.197033 http.c:505              <= Recv header, 0000000018 bytes (0x00000012)
21:30:48.197041 http.c:517              <= Recv header: Pragma: no-cache
21:30:48.197050 http.c:505              <= Recv header, 0000000053 bytes (0x00000035)
21:30:48.197057 http.c:517              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
21:30:48.197067 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:30:48.197075 http.c:517              <= Recv header:
21:30:48.197085 http.c:531              <= Recv data, 0000000323 bytes (0x00000143)
21:30:48.197093 http.c:546              <= Recv data: 137..001e# service=git-upload-pack.000000d2af75078c1b6bb5ff6
21:30:48.197100 http.c:546              <= Recv data: 30e0acf2f9e94d934a025aa HEAD.multi_ack thin-pack side-band s
21:30:48.197108 http.c:546              <= Recv data: ide-band-64k ofs-delta shallow no-progress include-tag multi
21:30:48.197115 http.c:546              <= Recv data: _ack_detailed no-done symref=HEAD:refs/heads/master agent=gi
21:30:48.197123 http.c:546              <= Recv data: t/2.10.0.003faf75078c1b6bb5ff630e0acf2f9e94d934a025aa refs/h
21:30:48.197130 http.c:546              <= Recv data: eads/master.0000..0....
21:30:48.197166 http.c:558              == Info: Curl_http_done: called premature == 0
21:30:48.197182 http.c:558              == Info: Connection #0 to host localhost left intact
21:30:48.207536 http.c:558              == Info: Couldn't find host localhost in the .netrc file; using defaults
21:30:48.207600 http.c:558              == Info: Found bundle for host localhost: 0x1c7db00 [can pipeline]
21:30:48.207650 http.c:558              == Info: Re-using existing connection! (#0) with host localhost
21:30:48.207677 http.c:558              == Info: Connected to localhost (127.0.0.1) port 80 (#0)
21:30:48.216731 http.c:505              => Send header, 0000000225 bytes (0x000000e1)
21:30:48.216789 http.c:517              => Send header: POST /git/rc/git-upload-pack HTTP/1.1
21:30:48.216798 http.c:517              => Send header: Host: localhost
21:30:48.216805 http.c:517              => Send header: User-Agent: git/2.10.0
21:30:48.216813 http.c:517              => Send header: Accept-Encoding: gzip
21:30:48.216820 http.c:517              => Send header: Content-Type: application/x-git-upload-pack-request
21:30:48.216827 http.c:517              => Send header: Accept: application/x-git-upload-pack-result
21:30:48.216835 http.c:517              => Send header: Content-Length: 153
21:30:48.216841 http.c:517              => Send header:
21:30:48.216853 http.c:531              => Send data, 0000000153 bytes (0x00000099)
21:30:48.216861 http.c:546              => Send data: 008cwant af75078c1b6bb5ff630e0acf2f9e94d934a025aa multi_ack_
21:30:48.216868 http.c:546              => Send data: detailed no-done side-band-64k thin-pack no-progress ofs-del
21:30:48.216876 http.c:546              => Send data: ta agent=git/2.10.0.00000009done.
21:30:48.216899 http.c:558              == Info: upload completely sent off: 153 out of 153 bytes
21:30:48.235637 http.c:505              <= Recv header, 0000000017 bytes (0x00000011)
21:30:48.235702 http.c:517              <= Recv header: HTTP/1.1 200 OK
21:30:48.235719 http.c:505              <= Recv header, 0000000022 bytes (0x00000016)
21:30:48.235726 http.c:517              <= Recv header: Server: nginx/1.10.1
21:30:48.235736 http.c:505              <= Recv header, 0000000037 bytes (0x00000025)
21:30:48.235745 http.c:517              <= Recv header: Date: Sun, 16 Oct 2016 20:30:48 GMT
21:30:48.235755 http.c:505              <= Recv header, 0000000052 bytes (0x00000034)
21:30:48.235763 http.c:517              <= Recv header: Content-Type: application/x-git-upload-pack-result
21:30:48.235774 http.c:505              <= Recv header, 0000000028 bytes (0x0000001c)
21:30:48.235781 http.c:517              <= Recv header: Transfer-Encoding: chunked
21:30:48.235791 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:30:48.235799 http.c:517              <= Recv header: Connection: keep-alive
21:30:48.235808 http.c:505              <= Recv header, 0000000040 bytes (0x00000028)
21:30:48.235817 http.c:517              <= Recv header: Expires: Fri, 01 Jan 1980 00:00:00 GMT
21:30:48.235826 http.c:505              <= Recv header, 0000000018 bytes (0x00000012)
21:30:48.235833 http.c:517              <= Recv header: Pragma: no-cache
21:30:48.235843 http.c:505              <= Recv header, 0000000053 bytes (0x00000035)
21:30:48.235850 http.c:517              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
21:30:48.235861 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:30:48.235869 http.c:517              <= Recv header:
21:30:48.235879 http.c:531              <= Recv data, 0000008027 bytes (0x00001f5b)
21:30:48.235888 http.c:546              <= Recv data: 1f53..0008NAK.2004.PACK..........x...I..0...zE............#

#### And the rest is simply gzipped repo files

The interesting part of all that output is that we can see that GIT is performing one HTTP GET and one HTTP POST to achieve the clone operation:

GET /git/rc/info/refs?service=git-upload-pack HTTP/1.1
Host: localhost
User-Agent: git/2.10.0
Accept: */*
Accept-Encoding: gzip
Accept-Language: en-GB, *;q=0.9
Pragma: no-cache

POST /git/rc/git-upload-pack HTTP/1.1
Host: localhost
User-Agent: git/2.10.0
Accept-Encoding: gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 153

008cwant af75078c1b6bb5ff630e0acf2f9e94d934a025aa multi_ack_
detailed no-done side-band-64k thin-pack no-progress ofs-del
ta agent=git/2.10.0.00000009done.

Nothing particularly worrying here.  That hex string comes from what GIT got in the body returned by GET, and so are all the other options.

git commit

Well, this is a local operation.  Nothing is transferred over the network here.

Still, the commit operation, submits some data (GIT objects) into the repository (.git directory) which is synced to all other copies of the repo with push/pull operations.  See the extra notes at the end for some files in the commit that are relevant to information disclosure.

git push

Here things are a little different.  I only tested this until the point where I saw the start of the PUT (on the server side) but it does give us good info.

I changed a file, added it, committed, and now I'm going to push it back to the origin.  I configured use.name and user.email to ensure they appear in the logs (see below):

$ git config user.name grochmal
$ git config user.email grochmal@example.com
$ git commit -m 'yay'
$ git push origin master > log2 2>&1
Username for 'http://localhost': grochmal
Password for 'http://grochmal@localhost':

For GIT to allow me to push over HTTP I needed to configure basic authentication on the server, since (by default) it only allows for a push if the server performs authentication.  Anyhow, the output:

21:53:54.779437 http.c:558              == Info: Couldn't find host localhost in the .netrc file; using defaults
21:53:54.781338 http.c:558              == Info:   Trying ::1...
21:53:54.781423 http.c:558              == Info: TCP_NODELAY set
21:53:54.781618 http.c:558              == Info: connect to ::1 port 80 failed: Connection refused
21:53:54.781643 http.c:558              == Info:   Trying 127.0.0.1...
21:53:54.781654 http.c:558              == Info: TCP_NODELAY set
21:53:54.781851 http.c:558              == Info: Connected to localhost (127.0.0.1) port 80 (#0)
21:53:54.781998 http.c:505              => Send header, 0000000187 bytes (0x000000bb)
21:53:54.782028 http.c:517              => Send header: GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
21:53:54.782038 http.c:517              => Send header: Host: localhost
21:53:54.782047 http.c:517              => Send header: User-Agent: git/2.10.0
21:53:54.782056 http.c:517              => Send header: Accept: */*
21:53:54.782065 http.c:517              => Send header: Accept-Encoding: gzip
21:53:54.782073 http.c:517              => Send header: Accept-Language: en-GB, *;q=0.9
21:53:54.782082 http.c:517              => Send header: Pragma: no-cache
21:53:54.782090 http.c:517              => Send header:
21:53:54.782555 http.c:505              <= Recv header, 0000000027 bytes (0x0000001b)
21:53:54.782569 http.c:517              <= Recv header: HTTP/1.1 401 Unauthorized
21:53:54.782586 http.c:505              <= Recv header, 0000000022 bytes (0x00000016)
21:53:54.782595 http.c:517              <= Recv header: Server: nginx/1.10.1
21:53:54.782605 http.c:505              <= Recv header, 0000000037 bytes (0x00000025)
21:53:54.782613 http.c:517              <= Recv header: Date: Sun, 16 Oct 2016 20:53:54 GMT
21:53:54.782623 http.c:505              <= Recv header, 0000000025 bytes (0x00000019)
21:53:54.782632 http.c:517              <= Recv header: Content-Type: text/html
21:53:54.782645 http.c:505              <= Recv header, 0000000021 bytes (0x00000015)
21:53:54.782654 http.c:517              <= Recv header: Content-Length: 195
21:53:54.782664 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:53:54.782673 http.c:517              <= Recv header: Connection: keep-alive
21:53:54.782685 http.c:505              <= Recv header, 0000000044 bytes (0x0000002c)
21:53:54.782693 http.c:517              <= Recv header: WWW-Authenticate: Basic realm="Restricted"
21:53:54.782704 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:53:54.782713 http.c:517              <= Recv header:
21:53:54.782723 http.c:531              <= Recv data, 0000000195 bytes (0x000000c3)
21:53:54.782732 http.c:546              <= Recv data: ..<title>401 Authorization Required</title></hea
21:53:54.782740 http.c:546              <= Recv data: d>....
401 Authorization Re
21:53:54.782748 http.c:546              <= Recv data: quired
..
nginx/1.10.1..</b
21:53:54.782756 http.c:546              <= Recv data: ody>....
21:53:54.782778 http.c:558              == Info: Curl_http_done: called premature == 0
21:53:54.782848 http.c:558              == Info: Connection #0 to host localhost left intact
21:53:59.617614 http.c:558              == Info: Couldn't find host localhost in the .netrc file; using defaults
21:53:59.617755 http.c:558              == Info: Found bundle for host localhost: 0x136d680 [can pipeline]
21:53:59.617806 http.c:558              == Info: Hostname localhost was found in DNS cache
21:53:59.617870 http.c:558              == Info:   Trying ::1...
21:53:59.617894 http.c:558              == Info: TCP_NODELAY set
21:53:59.618064 http.c:558              == Info: connect to ::1 port 80 failed: Connection refused
21:53:59.618102 http.c:558              == Info:   Trying 127.0.0.1...
21:53:59.618122 http.c:558              == Info: TCP_NODELAY set
21:53:59.618332 http.c:558              == Info: Connected to localhost (127.0.0.1) port 80 (#1)
21:53:59.618453 http.c:505              => Send header, 0000000187 bytes (0x000000bb)
21:53:59.618559 http.c:517              => Send header: GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
21:53:59.618575 http.c:517              => Send header: Host: localhost
21:53:59.618591 http.c:517              => Send header: User-Agent: git/2.10.0
21:53:59.618607 http.c:517              => Send header: Accept: */*
21:53:59.618621 http.c:517              => Send header: Accept-Encoding: gzip
21:53:59.618637 http.c:517              => Send header: Accept-Language: en-GB, *;q=0.9
21:53:59.618652 http.c:517              => Send header: Pragma: no-cache
21:53:59.618667 http.c:517              => Send header:
21:53:59.618731 http.c:505              <= Recv header, 0000000027 bytes (0x0000001b)
21:53:59.618750 http.c:517              <= Recv header: HTTP/1.1 401 Unauthorized
21:53:59.618772 http.c:505              <= Recv header, 0000000022 bytes (0x00000016)
21:53:59.618788 http.c:517              <= Recv header: Server: nginx/1.10.1
21:53:59.618807 http.c:505              <= Recv header, 0000000037 bytes (0x00000025)
21:53:59.618822 http.c:517              <= Recv header: Date: Sun, 16 Oct 2016 20:53:59 GMT
21:53:59.618841 http.c:505              <= Recv header, 0000000025 bytes (0x00000019)
21:53:59.618857 http.c:517              <= Recv header: Content-Type: text/html
21:53:59.618876 http.c:505              <= Recv header, 0000000021 bytes (0x00000015)
21:53:59.618892 http.c:517              <= Recv header: Content-Length: 195
21:53:59.618912 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:53:59.618927 http.c:517              <= Recv header: Connection: keep-alive
21:53:59.618949 http.c:505              <= Recv header, 0000000044 bytes (0x0000002c)
21:53:59.618965 http.c:517              <= Recv header: WWW-Authenticate: Basic realm="Restricted"
21:53:59.618986 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:53:59.619001 http.c:517              <= Recv header:
21:53:59.619017 http.c:558              == Info: Ignoring the response-body
21:53:59.619037 http.c:531              <= Recv data, 0000000195 bytes (0x000000c3)
21:53:59.619052 http.c:546              <= Recv data: ..<title>401 Authorization Required</title></hea
21:53:59.619068 http.c:546              <= Recv data: d>....
401 Authorization Re
21:53:59.619083 http.c:546              <= Recv data: quired
..
nginx/1.10.1..</b
21:53:59.619098 http.c:546              <= Recv data: ody>....
21:53:59.619127 http.c:558              == Info: Curl_http_done: called premature == 0
21:53:59.619150 http.c:558              == Info: Connection #1 to host localhost left intact
21:53:59.619178 http.c:558              == Info: Issue another request to this URL: 'http://localhost/git/rc/info/refs?service
=git-receive-pack'
21:53:59.619289 http.c:558              == Info: Couldn't find host localhost in the .netrc file; using defaults
21:53:59.619322 http.c:558              == Info: Found bundle for host localhost: 0x136d680 [can pipeline]
21:53:59.619351 http.c:558              == Info: Re-using existing connection! (#1) with host localhost
21:53:59.619387 http.c:558              == Info: Connected to localhost (127.0.0.1) port 80 (#1)
21:53:59.619426 http.c:558              == Info: Server auth using Basic with user 'grochmal'
21:53:59.619600 http.c:505              => Send header, 0000000226 bytes (0x000000e2)
21:53:59.619631 http.c:517              => Send header: GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
21:53:59.619646 http.c:517              => Send header: Host: localhost
21:53:59.619661 http.c:517              => Send header: Authorization: Basic <redacted>
21:53:59.619677 http.c:517              => Send header: User-Agent: git/2.10.0
21:53:59.619691 http.c:517              => Send header: Accept: */*
21:53:59.619706 http.c:517              => Send header: Accept-Encoding: gzip
21:53:59.619720 http.c:517              => Send header: Accept-Language: en-GB, *;q=0.9
21:53:59.619753 http.c:517              => Send header: Pragma: no-cache
21:53:59.619768 http.c:517              => Send header:
21:53:59.633633 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:53:59.633669 http.c:517              <= Recv header: HTTP/1.1 403 Forbidden
21:53:59.633683 http.c:505              <= Recv header, 0000000022 bytes (0x00000016)
21:53:59.633692 http.c:517              <= Recv header: Server: nginx/1.10.1
21:53:59.633702 http.c:505              <= Recv header, 0000000037 bytes (0x00000025)
21:53:59.633711 http.c:517              <= Recv header: Date: Sun, 16 Oct 2016 20:53:59 GMT
21:53:59.633722 http.c:505              <= Recv header, 0000000028 bytes (0x0000001c)
21:53:59.633730 http.c:517              <= Recv header: Transfer-Encoding: chunked
21:53:59.633740 http.c:505              <= Recv header, 0000000024 bytes (0x00000018)
21:53:59.633749 http.c:517              <= Recv header: Connection: keep-alive
21:53:59.633758 http.c:505              <= Recv header, 0000000040 bytes (0x00000028)
21:53:59.633767 http.c:517              <= Recv header: Expires: Fri, 01 Jan 1980 00:00:00 GMT
21:53:59.633776 http.c:505              <= Recv header, 0000000018 bytes (0x00000012)
21:53:59.633785 http.c:517              <= Recv header: Pragma: no-cache
21:53:59.633795 http.c:505              <= Recv header, 0000000053 bytes (0x00000035)
21:53:59.633803 http.c:517              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
21:53:59.633813 http.c:505              <= Recv header, 0000000040 bytes (0x00000028)
21:53:59.633822 http.c:517              <= Recv header: Expires: Fri, 01 Jan 1980 00:00:00 GMT
21:53:59.633831 http.c:505              <= Recv header, 0000000018 bytes (0x00000012)
21:53:59.633840 http.c:517              <= Recv header: Pragma: no-cache
21:53:59.633849 http.c:505              <= Recv header, 0000000053 bytes (0x00000035)
21:53:59.633858 http.c:517              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
21:53:59.633868 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:53:59.633858 http.c:517              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
21:53:59.633868 http.c:505              <= Recv header, 0000000002 bytes (0x00000002)
21:53:59.633876 http.c:517              <= Recv header:
21:53:59.633887 http.c:531              <= Recv data, 0000000005 bytes (0x00000005)
21:53:59.633895 http.c:546              <= Recv data: 0....
21:53:59.633923 http.c:558              == Info: Curl_http_done: called premature == 0
21:53:59.633940 http.c:558              == Info: Connection #1 to host localhost left intact
fatal: unable to access 'http://localhost/git/rc/': The requested URL returned error: 403

HTTP 403!  Oh well, I could not be arsed to configure a proper htpaswd file.  But this gives us already enough info about what GIT does on a push, the interesting parts are:

GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
Host: localhost
User-Agent: git/2.10.0
Accept: */*
Accept-Encoding: gzip
Accept-Language: en-GB, *;q=0.9
Pragma: no-cache

GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
Host: localhost
User-Agent: git/2.10.0
Accept: */*
Accept-Encoding: gzip
Accept-Language: en-GB, *;q=0.9
Pragma: no-cache

These two GETs are the ones that trigger the user prompt and the password prompt, all fine until now.  Forward:

GET /git/rc/info/refs?service=git-receive-pack HTTP/1.1
Host: localhost
Authorization: Basic <redacted>
User-Agent: git/2.10.0
Accept: */*
Accept-Encoding: gzip
Accept-Language: en-GB, *;q=0.9
Pragma: no-cache

Ouch!  That <redacted> part (CURL redacts it even in trace mode!) is a Basic Authentication header, and its content is equivalent to:

echo -n username:password | base64

In essence, the password is sent in (almost) clear text.  That's expected since GIT wants the server to perform the authentication and an HTTP server will perform simple HTTP authentication.

It is really a very good thing that pretty much all repositories available through the internet use HTTPS.  Don't use an HTTP authenticated repository over plain HTTP over the internet, anything can be spoofed and you password is compromised straight away.

Extra note

But wait, where the hell those user.name and user.email configuration options ended?  Answer: in the log:

$ git log
commit 4aa5546090030c4d9196b6a4a2547b77a8c5a394
Author: grochmal <grochmal@example.com>
Date:   Sun Oct 16 21:52:22 2016 +0100

    yay

commit af75078c1b6bb5ff630e0acf2f9e94d934a025aa
Author: grochmal <grochmal@somewhere.org>
Date:   Mon Oct 27 00:39:41 2014 +0000

    some simple configs plus dummy email configuration

commit 421b7dce992a67940422e5a0612f0d2d253d1a55
Author: Michal Grochmal <grochmal@fuji.bluepenguin>
Date:   Sun Feb 17 01:01:12 2013 +0000

    remove stuff

commit 3e2d568bb260d12a31b76141c782a655e44eef64
Author: Michal Grochmal <grochmal@fuji.bluepenguin>
Date:   Fri Feb 15 22:36:30 2013 +0000

    create depot

These come form the files in .git/logs combined with files in .git/objects, and contain whatever was configured as the email and username at the time.  This is an old repo, older than GIT 2, which started frowning upon commits without the two parameters.  During that time the username was takes as the system username and the email as the host.

And since the log files are in every clone (or sync) of a repo, these files are actually the biggest information disclosure vectors.  One file may look for example as (.git/objects/42/1b7dce992a67940422e5a0612f0d2d253d1a55):

$ git cat-file -p 421b7dce992a67940422e5a0612f0d2d253d1a55
tree 222cb8fbbddc6d6d79d9ec6a83bd95228994a46c
parent 3e2d568bb260d12a31b76141c782a655e44eef64
author Michal Grochmal <grochmal@fuji.bluepenguin> 1361062872 +0000
committer Michal Grochmal <grochmal@fuji.bluepenguin> 1361062872 +0000

remove stuff

Which discloses the system username and hostname, because I did not configure user.name or user.email before commit+push.

New GIT versions (notably all 2.x ones) solve the disclosure by giving up on commits that do not have a properly configured repo.  Yet, there are still systems using old GIT binaries out there.


The most secure solution is to have SSH keys encrypted with a passphrase and managed with a key agent (e.g. ssh-agent). However,

  if your system reboots, it requires human intervention to reload the
  keys, making it inappropriate for some uses where automatic system
  recovery is needed. If you find yourself trying to think of ways to
  automatically load the keys into the agent, then you don't really want
  to use the agent.

(from the O'Reilly definitive guide to SSH at http://www.snailbook.com/faq/no-passphrase.auto.html)

If you must use a key without a passphrase, the guide says to be sure the key resides on a local disk (the SD card in this case), and you should also use restrictions on the public key such as "from=" and "command=" so that theft of the key (or the SD card on which it resides) can be mitigated.


Encryption on Mobile Devices - Multiparty Encryption - Key Management

You can use the same way as WhatsApp group messaging does.

Heavily oversimplifying it, this is what you can do:

Each member generates their own symmetric key called Sender key.
Every member shares their sender key with each other through one-to-one encryption scheme. In your case, you can share this key by encrypting it with their public keys. So if there are n members, each member sends their sender key n-1 times encrypted with individual's public key. Total number of key exchange will be n(n-1).

  Participants' public key can be obtained from B acting as key distribution server.

If A wants to send a message to other members, A encrypts his message with his own sender key and sends it to B.
B creates copies of A's message equal to the number of recepients and forwards this it to them. This is called server side-fanout.
As recepient's already knows A's sender key, they can decrypt A's message.
When someone joins, he generates his own sender key and shares it with others the same way. Other members also share their keys with him like before. Total number of key exchange will be 2(n-1) for n members including the new one.
If someone leaves, every member clears their old sender key, generates a new one and shares their key again. Total number of key exchange will be n(n-1) for n existing members in the group.
To prevent a malicious member impersonating as some other member, each member signs their message using their private key. The public component to verify the signature can be obtained from B.

How you implement one to one messaging, this can be used to share sender keys to initialise multiparty encryption. You can also use Diffie-Hellman to share sender keys but it also has to be done n-1 times if there are n members.

Here's a good article on reducing the distribution of keys for multiparty encryption: Better Encrypted Group Chat


compare sha-256 fingerpirnt of certificate with google transparency report


From a brief look - both descriptions are essentially correct as 802.11 is talking via the router (think of it as a switch in this context) to reach your box. From a higher layer perspective (the border between L2 and L3 - which ARP essentially is) your model is correct. (Victim > Attacker > Router)

From a lower layer possibly the border between L1 and L2, both devices are speaking to the router, so (Victim -> AP -> Attacker -> AP -> Router -> Internet)

So the victim device addresses a packet to the attacker, and in the process encapsulates that in an 802.11 packet addressed to the Access Point. The Access Point decapsulates and decrypts that packet, encrypts and encapsulates that packet addressed to the attacker.

To answer your other question, if it works, then yes it does circumvent the transient key (bearing in mind you already know the password to access the network).

The OSI model isn't great in practice but it's still how I think of things...

As an aside every WiFi router I've tried in the past few years (only a handful) has detected the ARP spoofing and either blocked, or repoisoned the victim with the correct address, as it realises it something is amiss. I doubt that is so common with AP's because the router is a separate device which the AP isn't so aware of. I rarely try it as in most cases its just easier to deauth the target, then capture the transient key on reconnection.


Android client side data encoding/encryption bypass

I assume that there must be a file at client side which might be encrypting/encoding data from my end:
Yes if an extra layer of encryption is used apart from Transport Layer Protections(TLS/SSL) then encryption is done at client side.

No matter how many input fields are there in any single form, only two parameters pass through my end to the server those are as follows:
Maybe all the parameters are sent in Cipher Text as key value pairs seperated by some delimitters.

Kindly suggest me how to bypass this mechanism in order to tamper data through the Burp Suite:
You can reverse engineer the application and get the application source code(JADx, dex2jar&JD-GUI). Then through source code analysis, you can identify the classes that may be used for encryption.
For Ex: You can search manually for the instantiations of javax.crypto.Cipher class that can be used for encryption.
You can even use automated tools like MobSF that will make the task much easier for you.

Source code is obfuscated:
Obfuscated source code only created a hurdle for analyst/attacker it can still be read and understood.


Is the separation of data from different applications via Oracle schemas considered secure?

It is a common concept to create specific Database-Users for each application.
These users should have the minimum privileges needed to do their job.

Lets apply this to your example:

ApplicationA uses DataBaseUserA which has the privileges to Read/Insert/Update/Delete TableA in SchemaA.
ApplicationB uses DataBaseUserB which has the privileges to Read TableB in SchemaB.
Of course you also got at least one DBA account.

Now consider ApplicationB is vulnerable to SQL-injection:

select * from SchemaA.TableA gets injected and executed by DataBaseUserB.
The DataBase response would be ORA-00942: table or view does not exist

At most use-cases i would consider this behaviour to be secure enought. Of course a completey different DataBase-instance would add another layer of security in case of some unknown security critical issue in Oracle DB.


Can real end-to-end SSL encryption be made?

This practice is sometimes described as "institutional man-in-the-middle attack". It can be done by either modifying the client code (so that it allows such proxying), or adding a special CA in the trust store of the client; in the latter case, the proxy intercepts the connection, generates a fake certificate for the server (issued by the special CA -- it is "special" in that the private key is controlled by the proxy), and runs a true MitM "attack".

This is done by big organizational content filters (e.g. Bluecoat's ProxySG) and by "Internet accelerators" like the one you observe (by accessing the raw data contents, the MitM proxy can apply some strategies for "speeding things up", namely caching and enforced data compression).

Accelerators often rely on client code modification, which allows for more "speeding up strategies" than the basic interception with a fake server certificate. This is probably your case; it will be browser specific. It is a security concern since it defeats one of the key points of SSL, i.e. to bring end-to-end confidentiality and integrity. I know some banks who are really unhappy about that, because it makes it much more difficult to apply some legal value to SSL-based Internet banking. As a user, you can defend against this practice (which is indeed widespread) by using an alternate browser (e.g. Firefox seems to be available for some Nokia phones) and verifying that the alternate browser trusts only "trustworthy" root CA.

(Note: it occurs to me that since these "Internet accelerators" tend to use indiscriminate data compression on the link between the phone and the MitM proxy, they are possibly vulnerable to the CRIME attack. This might be worth some investigation and publicity.)

Edit: while MitM of SSL connections seems to occur with Nokia's browser (e.g. see this article), the corresponding feature in Opera / OperaMini, called turbo, claims not to do it for SSL, only for plain HTTP:

  Even while using Opera Turbo, secured connections do not go through Opera's servers. This means that when you are using your bank or transmitting sensitive data, you are talking directly with the website.


According to the NCC group's Jackson Deserialization Vulnerabilities:

  Jackson does not perform typing by default (including collection generic
  types) and does not allow the specification of arbitrary types

Besides the link you gave, OWASP has a page on the Deserialization of untrusted data which explains how to handle types.


PCI Compliance 8.2.1, 8.2.3, 8.2.4 - Which user passwords is this talking about?

That document version 3 aka 3.0 (and the corresponding DSS) is 5 years old, the current version of both DSS and (all) SAQs is v3.2.1 from 2018 (although a draft of the next major version, 4.0, is scheduled for comment soon); see https://www.pcisecuritystandards.org/document_library and select Filterby=SAQS. The actual standard which the various SAQs (and audits/ROCs) are designed to implement, PCI DSS (Data Security Standard), is under the default Filterby=PCIDSS, and it says at the beginning of section 8:

  Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used
  to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for
  example, for support or maintenance). These requirements do not apply to accounts used by consumers (e.g., cardholders).

  However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-ofsale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

See particularly the last sentence of the first paragraph. Since A and A-EP systems don't actually receive or store cardholder data, it's their ability to control access to it that matters.

SAQA-EP 3.2.1 reflects this, briefly, in item 8.1, emphasis added:

  Are policies and procedures for user identification
  management controls defined and in place for nonconsumer users and administrators on all system
  components, as follows:

but 3.0 did not (according to my saved copy), and even now it's not made obvious this applies throughout all of 8.1.* 8.2.* and 8.3.*. Also note A-EP 3.0 did not include DSS 8.2.2 but 3.2.1 does.

Neardupe To whom do the PCI DSS password requirements apply? which answers essentially the same for 3.2 in 2017, before 3.2.1 was published.


Is a VPN the only way to protect against rogue Wifi access points MITM attacks?

Connecting to a WiFi hotspot is no worse than connecting to the Internet in general. The error would be to assume that local communications (between two machines which are bound to the same hotspot) would benefit from protection from eavesdroppers. It is only in that sense that WiFi is "weak": it does not offer the kind of physical protection that we took for granted with wired ethernet (and, even then, thinking of wired ethernet as protected is a bit of wishful thinking).

The most glaring targets are local file sharing and printer access; these are features commonly activated in enterprise and home network, and for which some level of protection is clearly needed. But Web surfing ? No, nothing special with WiFi here. Regardless of WiFi, the Internet is a harsh place, and HTTPS will protect you (if you do not disregard the certificate warnings, of course).


Can other people monitor my internet activity in the same WiFi network?

If somebody else has control of the WiFi access point onward or you're using a shared authentication key then there's very little you can do to ensure that you're not subject to an eavesdropping attack. Somebody with the same credentials who catches the initial association packet will be able to read all further session traffic.

If in doubt, you can route everything via VPN to a remote host or always use SSL and check your certificates.


How safe is NAT in keeping my private network private

NAT as used in typical SoHo routers implicitly protects you from direct access from outside into your network. And that's about all it does.

Specifically it does not protect you against anything which is initiated from inside, like opening a mail or visiting some external web site. NAT will not protect against scanning the internal network if this scanning was initiated from inside - no matter if the script for scanning the local network was loaded when visiting an external web site. NAT will also not protect against loading some malware from outside which then can attack your network from inside or provide an attacker with a backdoor in your private network.

In other words: NAT does not help a lot in protecting the privacy of your network.

  I recently read ... that without an ACL set incoming ICMP echo request (ICMP type 8), ICMP time-exceeded (ICMP type 11) could reveal your intranet structure.

In case of NAT no access initiated from outside to the inside is possible and this includes ICMP. What you've read is not about NAT.


The concept you're referring is to is called red pill detection..  The bad guys have gotten wise to the fact that the good guys can easily put a malware in a virtual sandbox to do dynamic analysis, so some are building in red pill action.  For common hypervisors, doing a simple driver check will show whether the guest is running on vmware, xen, or other hypervisors.

This has little impact on forensics.  Any good forensics investigator will have resources to do analysis outside a VM environment.  Simply, using a VM guest (i.e. automation) to do malware analysis simplified forensics for the good guys.  Not all malware does detection today.  Considering the bad guys usually prefer to keep packages small, embedding additional functions like vm detection adds additional complexity to code.  Such detection may only be present when the bad guys are really concerned about being detected.  Since most malware packages target the lowest hanging fruit (which there are plenty of), additional features (i.e. encryption, vm detection, steganography, etc) really aren't necessary.  So, existing models of automating forensics are still effective.


Security while connecting to a MySQL database using PDO

Use include or include_once to include anything in PHP.

<?php
include_once("/etc/out-of-htdocs/password.php");
?>

The PHP code can access files, which are not accessible via an URL. That is the security benefit.

In case of a miss configuration of the PHP module it is possible that every PHP file gets delivered without evaluation, which means that the password is world readable for everybody. If the PHP file is not accessible via an URL a configuration problem of the PHP module does not have any impact in the password security.


Is it possible to make the back button work if we use one CSRF-token per request?

The solution used in my Web-Applications (JSF) is to tell the browser to make a new GET-Request on browser-back (or reopen tab). This is done with the following HTTP Response Header:

Cache-Control: no-store, no-cache, must-revalidate
Expires: [in the past]

The first line is for HTTP 1.1, the second line is for Proxy-Servers.
This should work (at least) in all major browsers.

For details see this answer over at StackOverflow


How might the U.K. Government's proposed internet surveillance equipment "bypass" encryption?

Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively).

Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity of the server, to make sure it's exchanging data confidentially with the party it expects: this is what certificates are used for.

An X.509 certificate is issued by a CA for a given server name. If the browser trusts this CA (there are a number of trust anchors provided by default with most browsers), it can trust its content: the binding between its public key and the name it contains. The browser also has to check that the server name it was looking for is one of the names in the certificate.

What the government can do is to ask you to trust its CA certificate (and/or have the big CAs give them an intermediate CA certificate) so that they can issue certificates for their surveillance device, thereby spoofing the real server certificate. This device would be a server and decipher the connection and then act as a client itself to the real server: you would then have 2 encrypted sections: one between the client and the surveillance device, and one between that device and the real server.

There exist appliances that do this (sometimes referred to as "MITM proxy servers"), typically used on a enterprise network.

Besides the fact that anyone in control of that CA's private key could see and alter any traffic the client makes to an HTTPS site (there are a number of non-technical problems here), there are a number of technical problems when doing this at the scale of a country:

These proxy servers may need to be explicitly configured in the browser (as an HTTP proxy).

Indeed, it's quite difficult to implement a MITM proxy transparently, because it can't always get the name it should put in the certificate it generates dynamically by just looking at the initial TCP packets. If Server Name Indication is not used (SNI is quite common nowadays, but not supported by all clients), all it can get is the IP address of the server, which may not necessarily resolve back to the expected name. For example, if you get the address for www.facebook.com and do a reverse DNS lookup, you'll get something like www-XYZ-XYZ.facebook.com. It could work with a wildcard here, but that pattern can't be expected in general.
This will make any service that uses client-certificate authentication break. Since during the SSL/TLS handshake, when a client certificate is used, the client signs the concatenation of all the handshake messages (including the server certificate) at the end, and the server compares it to what it has sent and received (including the real certificate). If there's something in the middle that inserts it own certificate, this is going to make this verification fail.
There will certainly be a delay in the establishment of the handshake, since the certificates may have to be generated dynamically. (Some could be cached.)
This expects users to "play nice" and use the ports that they are meant to do. Alternative ports might not be monitored or would have to be completely firewalled.
To track down Facebook/Google+/Gmail exchanges in a usable form, these devices will also need to be able to look through the structure of the pages (or JSON payload for AJAX) and be able to extract the relevant data (or to store everything it can't understand somewhere). Any slight change in the internal API of those services would require some costly adaptation.

Doing all this for all HTTPS communications will certainly require a large amount of computing power and yield a substantial electricity bill.

(It's possible that the reports that led the Home Office to make such plans were drafted before Facebook switched to HTTPS for everything, by the way.)


Need to protect passwords (or 1fa) in the context of 2fa

You've misunderstood the meaning of two factor authentication. If you remove one factor (by trivialising it), then you no longer have two factor authentication, you have one factor authentication (just with a different form of factor - something you have/are, instead of something you know).

You imply that the benefit of 2FA is the strength of the second factor. If that were the case, then you don't need 2FA - simply implement the second factor by itself. No, the benefit of 2FA is the redundancy of having two factors at the same time.

If a hacker breaks one of the factors, you are still protected by the other. E.g. if your internet banking security device gets stolen, you are safe because you still have a password. Alternatively, if someone sees you type your password, you are safe because you still have your device. You've reduced the attack vector to scenarios where the attacker manages to accomplish both tasks.

If you trivialise one of the factors, you might as well not bother with the scheme in the first place.


Why do the large majority of big organizations have "known bad" password policies?

[ "Why does someone else do something I consider dumb?" is always a very open-ended question subject to speculation (and is not a great fit for Stack Exchange.)  But because this problem is so prevalent among password policies, I believe it's worth exploring. ]

First, there is a lot of misinformation, superstition, confusing math, and technobabble around passwords.

Some security experts believe that a combination of special characters, numbers, and mixed case letters automatically make passwords unguessable, but they don't know or disagree what the optimal mix is.  The guidance also should be changed depending on the native language of the users, but many site administrators are unaware of the differences.
Some don't understand the massively parallel computing resources available to modern password attackers.  Hard drives containing rainbow tables of every possible 8 character string hashed with MD5 are sold online.  Cloud based computing clusters, purpose-built arrays of graphics cards, and thousands of botnet controlled computers are all being employed by people to crack passwords.  Databases of previously cracked passwords, dictionaries from every language, song lyrics, and movie quotes are all readily available to the enterprising hacker when it comes time to testing guesses.
People remember hearing things like "don't write passwords down", which was advice from 20 years ago when you could count on the secretary to write her boss's password on a post-it note stuck to her monitor, and the biggest threat was someone could walk by her desk when she was at lunch.  I have yet to disassemble a keystroke logger that is able to read a sheet of handwritten paper kept in my wallet. But some people still repeat this advice today.
And technical people don't help when they toss around terms like "entropy" and numbers like "7 to the 95th power" that mean nothing to an average person; at the same time they ignore the psychology of the average user who doesn't want to enter 12 cryptographically random characters, let alone be asked to remember them for each of a dozen web sites.

Next, good passwords are notoriously difficult to study.  If asked to enter a work password into a web site so they could study its complexity, most people would say "no".  Many studies involving people entering a made-up password don't have test conditions that reliably mimic memorization or usage in the real world.  So our primary sources of data on user-chosen passwords are the passwords and hashes published after (the increasingly frequent) data breaches.  But these are often from sites like "long-eared-rabbit-fanciers-forum.com", where people know they have little of value to lose from using a weak password.  They seem to be less often published from sites where the users are protecting their own credit cards, account balances, or other forms of digital valuables.  I'm unaware of any case where a bank's cleartext password database was published online.  And in many cases, the published databases are hashed and to analyze them means the researchers have to brute force attack them with a hashing algorithm before analysis can begin.

There is also education.  Web site administrators don't take classes in "choosing a good password complexity scheme," nor do they take classes in "securely storing passwords".  And a huge number of computer courses use an example of "create a sign-on screen" as an introductory program; but none of the many examples I've seen have ever demonstrated using pbkdf2() to hash the passwords before placing them in the database.  And with all that, if you do come up with effective rules on choosing a good password, you still have to convince users to pick secure more passwords than 'P@ssword1'.

All that said, there are many researchers who have done a lot of work on passwords.  You'll find hundreds of curated scholarly papers on the subject at http://www.passwordresearch.com.  There are presentations on passwords at many of the premier security conferences.  There is an annual International Conference on Passwords.  So there are bodies of knowledge being built up, but they haven't converged on a standardized set of conclusions or recommendations yet.  And this information has yet to be disseminated to many of the architects and engineers who build web sites.  There is simply no straight pipeline of solid information from the researchers into practice.  And that may be the biggest hurdle of all.


How does Android's security model differ from UNIX's?

Android essentially relies on the Linux Kernel's security theme's for its security model:

User based permissions
Process isolation
Mechanisms for inter-process communication
Modular kernel that can be customized (insecure modules removed/modified)

Bizarre seems like a strong word, but Android definitely went a little extreme by combining process isolation with user based permissions.  You're absolutely right, for each app a user is created.  It is independent of the author of the program.  If there are multiple apps from the same author then each app gets a user created for it.  The private data for each app is protected under this user's permissions, and so is the process space.  In this way only the app can access its private data, and it's process space can only be accessed by the app.

Apps can talk to each other through IPC, and the main addition to the kernel in this respect is the Binder class.  This addition allows a background service to interact with apps, and courier data between processes.  When created in this manner it does not live on indefinitely in the background, but is created with a specific purpose and is killed once it's fulfilled.

For more detailed information I'd suggest reading Android Security Overview.


Should I encode the {Name} and {Feedback} variables in the email?

Yes - for correctness, even if there is no practical threat. If the feedback-giver includes a less-than sign in their feedback, it should appear in the mail as a less-than-sign, and not get treated as part of a markup tag. Handle text context injection correctly, get the security piece for free.

Attacks using HTML injection are much more limited in mail than on a web page because it is assumed that there is no origin associated with the sender that can be usurped to get cross-site-scripting, if scripting executes at all.

However it's not just JavaScript: markup injection would still get you the ability to reformat the mail in general. For example you could inject a spoofed link into what looks like the sender-specified part of the mail, or some styled markup to overlay custom content over the whole mail body. Depending on who the Big Public Company are there might be an increased phishing risk here.


While the other answer describes the different types of reCAPTCHA that Google has, it does not address what I think may be the real issues. As I was wondering about this myself, I came across this article. I summarize what I think is relevant:

According to tech statistics website Built With, more than 650,000 websites are already using reCaptcha v3; overall, there are at least 4.5 million websites use reCaptcha, including 25% of the top 10,000 sites. (as the 27th of June, 2019)

The data is changing quickly, right now some 2,602,509 sites seem to be using v3.
Also relevant, v3 works better if its code is installed in all web pages of a site. This means less user privacy. Although Google states that:

reCaptcha’s API sends hardware and software information, including device and application data, back to Google for analysis, and that the service is only used to fight spam and abuse.

So:

Google reCAPTCHA v3 is easier for the users, but as more sites use v3, more will be the information that Google has about them, as tracking a user across sites that use v3 is technically possible.
Google reCAPTCHA v2 takes more work for the user, but seems to be less intrusive regarding privacy.
v3 seems to be gaining momentum quickly.
Google seems committed to maintain both v2 and v3 in the future.

Regarding safety, I can tell from experience that v2 does not stop all spam. This is probably due to spammers using CAPTCHA farms (real people solving the bot's problems.) I don't have that much experience with v3.
So IMHO, I would go for v3 (already widely adopted) unless maximum user privacy is a must. But if you are using Google Analytics to measure a site's traffic, using v2 for added privacy may be irrelevant.
Any comment regarding safety of v3 from a trusted source or site experience will be appreciated!