PCI-SAQ A-EP compliance for website developer?

tl;dr you should probably contact a QSA and get them to help you navigate this. It sounds like the merchant is big enough to have the attention of their acquiring bank, which means you need to be on your game.
I am not a QSA, nor am I your QSA, but I do deal with PCI quite a bit. Depending on how you've implemented Stripe the merchant may actually qualify for the SAQ A, which is much preferred to the A-EP from your perspective.
However, if you go forward with the A-EP, here is why they're asking for stuff from you and the hosting provider:

Requirement 6: Develop and maintain secure systems and applications

The merchant didn't develop any of the software, they relied on you. Therefore the bank is going to expect you to pick up your end of requirement 6 as well as probably some others (12 comes to mind).

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 8: Identify and authenticate access to system components
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 12: Maintain a policy that addresses information security for all personnel

These are all likely applicable in some fashion to the hosting provider, as well as some I am sure I missed. This doesn't mention the additional requirements for shared hosting providers. Now, many reputable hosting companies are already PCI assessed and can provide an AOC on request (like AWS, for example).
Now, since neither you nor the hosting provider are actually merchants in the banks eyes, you would be filling out the SAQ D for Service Providers. Most of the requirements you can mark as N/A unless they would apply (like requirement 6). Then an authorized officer of your company would sign the attestation of compliance. This lets the merchant mark those requirements as N/A on their SAQ A-EP because they rely on a service provider (you).
Disclosure: I work at Braintree, which competes with Stripe and is part of PayPal, but this same advice would apply there too, unless you do the SAQ A as I mentioned first.


Are we safe from infection of Bad Rabbit?

First of all inform/warn employees from your organization - not to click on fake flash installation pop-up windows.

Here is an example:

On welivesecurity.com it is said:

  One of the distribution method of Bad Rabbit is via drive-by download.
  Some popular websites are compromised and have JavaScript injected in
  their HTML body or in one of their .js file.

That's from user perspective, now take technical advice:

keep your software/OS up-to-date
use strong passwords
block traffic on SMB protocol (tcp/445)
use AntiVirus software
monitor scheduled tasks and service creation

And as @Royce Williams said, you can create following files:

c:\windows\infpub.dat && c:\windows\cscc.dat

and remove ALL PERMISSIONS (inheritance).

You can also block access to following compromised sites from this list - https://pastebin.com/raw/n7ExrTsJ

More info about badrabbit follow here.


How does the digital signature process work?

Encryption and (Digital)Signing are different applications of PKI.

First (only) the most relevant concepts:

Encryption (so that a 3rd party wouldn't see the content): Use the receiver's Public Key (B-PubKey). Encrypt the content. You know the content because it originated from you. The receiver can decrypt using their Private Key (B-PvtKey) and see the content.
Digital Signing (so that any party can check whether the document is exactly as it was, when you signed it; and that be sure that only you could've signed it): Use the sender's Private Key (A-PvtKey) to encrypt the hash. NOT the content.

In your example, one of the issues is that you combined both. A normal digital signature process involves

Hashing the Message Plain Text using a well-known (public) hashing algorithm.
Encrypting it with sender's (A-PvtKey) Private Key.
Appending the encrypted hash to the Message Plain Text and send/store/...
Receivers can be one/many/any. None of the receivers' keys are used.
Anyone wishing to verify the document just follows the reverse process. i.e.,
Separate the encrypted hash from the message
Decrypt with sender's public key (A-PubKey) (usually from a Digital Signature Certificate issued by a trustworthy / legally-acceptable CA).
Generate the hash from the Message Plain Text independently and compare with the decrypted hash from #7 above.

That B was able to decrypt the hash with A-PubKey establishes the technical aspect of non-repudiation. That (if) the hashes were the same establishes the document integrity.

You should be able to see illustrations of these in a number of articles / videos freely available on the web.


Is there any relationship in the output between SHA256 and SHA224?

From Wikipedia:

  SHA-224 is identical to SHA-256, except that:
  the initial hash values h0 through h7 are different, and
  the output is constructed by omitting h7.

So there's no exploitable relationship between m1 and m2, it's not easier to guess m from m1, m2 or both of them.

However, what you really want is a key derivation function. Do not roll your own crypto and do not reinvent the wheel.


How does a 'rainbow table' hacker obtain password hashes in the first place?

The news is full of examples of leaked databases (this is just the most recent results).
The How:
The vast majority of cases involve unsecured databases/backups (across pretty much all technologies: S3, mongodb, cassandra, mysql, etc....). These are usually due to configuration errors, bad defaults, or carelessness.
What data is leaked:
These generally provide at least read-only access to some or all of the data contained in the database, including usernames and hashed-and-salted passwords.
These dumps include a lot of private user records. Plaintext passwords (or using a simple hash such as md5) are even more problematic because that data can be used in credential stuffing attacks (by trying the same username/password combinations on different websites), potentially accessing even more data.
What to do with a password hash:
If an attacker has access to a hashed and salted password, they cannot just provide this to the server to authenticate. At login time, the server computes hash(salt + plaintext_password) and compares it with the value stored in the database. If the attacker attempts to use the hash, the server will just compute hash(salt + incoming_hash), resulting in a wrong value.
One scenario that could spell a lot of trouble is client-side-only password hashing. If the client computes and sends hash(salt + plaintext_password) into the login endpoint, then the stored hash can be used to login. This alone shows how dangerous that is to do. There are some algorithms that offload some of the work to the client (such as SCRAM) but they involve a more thorough client-server exchange to prevent exactly this scenario.
Password storage security is worried about attackers deriving the real password from the stored value. It is not concerned with other vectors of attack against the server.


How does the anchor tag () lets you do an Reflected XSS?

Sure it's possible as long as a site uses non-persistant data to construct an anchor tag without properly sanitizing the data.  A contrived example:

{or maybe here?}

That being said, the link that you posted has to do with URL string evasion and not reflected XSS.  Is it possible you are confused on what reflected XSS is?  Or possibly I just misunderstood your question :)


Finding out whether a website uses unsalted MD5 for password hashing

To my knowledge (but I might have missed some recent results), there is no known ASCII-compatible collision on MD5.

The main conceptual reason for that is that collision-finding works by introducing some small bit differences, and then trying to cancel out these differences with each other, before they spread too much in the algorithm. Namely, for a given input message m, you consider message m' which differs from m by a few bits. By comparing all the internal values in the computation of MD5 on m and m', you can see the differences propagate. Two differences on the same bit may cancel out, sometimes with probability 1 (if you flip the same bit twice, you get back to the same value), sometimes with a lower probability, i.e. it works only for some possible internal values. That's because operations in MD5 are not just XOR; there are also some bitwise non-linear functions, and a lot of additions. Additions imply carry propagation. A lot of MD5 cryptanalysis is about coping with carry propagation.

Thus, an MD5 collision attack is mostly about choosing a differential path, i.e. a difference between m and m', which has a non-negligible probability of being fulfilled throughout the algorithm and cancelling itself out, yielding a collision. Then you try a lot of pairs (m,m') which differ by that source difference, until you get lucky. Message modification techniques are ways to improve your chances by tweaking pairs of messages which do not work for the whole differential, but almost work. Regardless of such techniques, you still have to work with a differential path which has a not-too-low probability of fulfilment.

Since carry propagation is the main problem in designing a good differential path, the useful tool for that is to modify the upper bit of 32-bit words. Indeed, if 32-bit words u and v differ only by their most significant bit, then u+v will necessarily be equal to 0x80000000, for all values of (u,v): for that bit, there is no carry (the carry, if any, "falls off" the word because we are using a 32-bit addition which truncates the result to 32 bits). That's a one-bit input difference which yields a one-bit output difference with probability 1: a very useful tool. It turns out that most (all of ?) known differential paths which have a high enough probability to yield a practical attack rely, at some point, on such one-bit differences on upper bits.

However, playing with the upper bit of an input word means that there is at least one byte in the colliding pair such that one of the messages will include a byte value in the 128-255 range. I.e. a non-ASCII byte.

A lot of what I explained above is based on vague hand-waving, but it should show the gist of the idea: the "fast" known ways to obtain a MD5 collision imply playing with a few bits of a message, and, right now, this includes the high bit of some bytes, making one of the colliding messages non-ASCII.

The slow way of finding collisions is to try random messages until a collision is found, with no constraint -- so these messages could then be full-ASCII. If you generate a lot of 11-character passwords, with characters being uppercase and lowercase letters and digits, then you should reach a collision when you have hashed about 264 of them, i.e. about one third of all possible 11-character passwords. Unfortunately, while a 264 effort is technologically feasible, it is still very expensive, and nobody has run it. Yet. At least publicly.

From the outside, there is very little you can do to determine the way the password is stored. At best, if password verification appears to be very fast (server responds within a few milliseconds), then you can prove that the password hashing is insufficiently iterated (unless it uses a "pepper", in which case it might be fast and secure at the same time -- see this answer for terminology). Otherwise, to prove the use of a specific hash function, you need collisions, because that's all the information you can obtain: whether a given password works for a given user, or not.

If you can look at the database contents (and the whole point of hashing passwords is based on the idea of an attacker who can do exactly that), then you have a lot of extra information:

If two users with the same password obtain the same hash value, then there is no salt (that's bad).
If two users with the same password do not obtain the same hash value, but the same user, changing his password back to a previous password, gets his hash back to the old value as well, then there is no real salt; the user name is used as (part of) the salt (that's bad too, albeit less so).
You can try candidate hash functions directly.


How secure is bitlocker with a pin when whole machine is stolen?

The scenario I want to protect myself against: 1. A simple thief steals the notebook 2. They want to access the data by basic "googling around" hacking skills, like using a tool or typing in random passwords.

A 9 digit PIN should be sufficient to protect against an attacker of this level of sophistication for long enough for you to change the passwords on all your online services. A TPM will ensure that only a trusted computer can unseal it, in combination with your PIN. Since the attacker has the whole computer, all that is needed is the PIN. What matters now is several factors:

How motivated your attacker is (are you a random victim of this attacker, one of 100 others?).
How clever he is (one person's "basic Googling skills" is another person's advanced Google-fu).
How long it will take you to notice the theft and to change your passwords.

Both defenders and attackers need to do cost-benefit analysis. You have to determine how much of your time and effort your assets are worth, but the attacker has to do the same. If it takes them two weeks to gain access to your computer, that is two weeks of lost opportunities for theft. Why spend all that time on your computer if it would be more profitable to steal three more computers in that time?


Why does Microsoft use a digital signature catalog instead of a signature in the executable?

Catalog files have actually been around since Windows 2000/XP. They are an alternative to signing single binaries as you attach one signature to the catalog file rather than a signature to every single binary. You can use either one to the same effect, but catalog files are more efficient for a large collection of files.

Microsoft typically does not include hashes from third party binaries in their catalog files, unless they are including them as part of the OS or a Microsoft application and are willing to sign those files. The exception to this is kernel mode drivers for Windows 10 as explained in this post. It is unlikely that a third party would modify a Microsoft-signed file without having it signed again.


How to secure or (Ensuring Integrity) of Web Data in transit and in store?

Keep everything encrypted with SSL with a properly signed SSL certificate from a trusted CA.  Web servers/certificate authorities should not give away their private SSL keys, similarly web browsers should only trust a minimal set of respected certificate authorities.

This prevents eavesdroppers from decrypting/altering1 communications.

1 Well they could drop packets or randomly alter a packet, which with very high probability would result in the packet being undecryptable (equivalent to dropping a packet).

Tineye says your image is from: http://www.edecision4u.com/HTTPS-SSL.html, which has its online documentation at: http://www.edecision4u.com/data/DG-HTTPS.SW.Specs.2012.doc (beware doc file).  This documentation specifically states its limitation:

  Note: Certificate Error Warning will appear at target user Web Browser. This problem can be resolved by having own trusted Certificate Authority (CA). For more information, please contact Decision Group.

Hence, to use this product you have to have a trusted by your browser CA to sign a certificate for your MITM attack, which valid CA should not do; however invasive governments may be able to do (especially if your browser trusts all the default CAs).


Is captcha on nth login attempt is really stops bots?

Storing the number of failed logins in the session or in the cookie does not work. As you pointed out, the attacker can simply delete the cookie. A better way is to keep the number of failed login attempts on the server, corresponding to the user name or the IP address used. If someone enters the wrong credentials, you increment the counter for that IP address or for that username on the server. This way the client can not alter it.


Firefox tries to connect to the SOCKS proxy server normally, but your operating system is routing all the traffic through the VPN server. So what happens simply is:

  Browser -> VPN Server -> SOCKS Server -> Destination server

So, yes. You're behind both of them.


2-way SSL - is it possible to accept multiple client certs on one IIS site?

You can surely do this with open source. So I think it is possible with IIS as well. Assuming you mean ** TLS Client Authentication** (2-way SSL).

With Apache2 Client Authentication works by exposing the authenticated user's data to your web application. Here is a sample app I put together to demo TLS Client Authentication. Here are the relevant pieces.

Config to use TLS Client Auth (this works w/ a single root, but you can also use multiple CAs by specifying SSLCACertificatePath instead of SSLCACertificateFile):

<VirtualHost *:443>
    ...
        SSLVerifyClient optional
        SSLVerifyDepth 1
        SSLCACertificateFile "/etc/ssl/private/ca.crt"
        SSLOptions +StdEnvVars
    ...

</VirtualHost>

The SSLOptions +StdEnvVars exposes the client certificate's data as an environment variable to your PHP script. You can then access it like so.

<?php
  echo $_SERVER['SSL_CLIENT_S_DN'];
  echo $_SERVER['SSL_CLIENT_S_DN_CN'];
?>

This way you can verify which client is authenticating in your web application. I am not familiar with how IIS handles these cases, but I think it is supported in some way. The key is to have it configured in a way to use multiple CAs when authenticating the clients. This post should help.

Alternatively, you can check out other authentication methods that provide a similar level of protection that TLS Client Certificates do.


Capability-based security vs protection rings: in what sense are they diametrically opposite?

In capability-based security, programs follow the principle of least privilege as stated on Wikipedia. This means that each program has almost no permissions to begin with and permissions are then granted for only the parts that the program needs. This is generally done on a much higher level than hierarchical protection domains.

In hierarchical protection domains, there are essentially layers that each contain certain permissions. Programs in more privileged levels have more permissions. In this way, programs do not start off with no permissions and may be granted lots of permissions they don't actually need. This is often enforced by the CPU architecture instead of in pure software and is much less granular than capability-based security. This approach contradicts the principle of least privilege.

In the sense that both approaches are used for the provisioning of permissions to programs, they are different methods for the same purpose, but the tend to apply to different domains. The Android OS implements a kernel similar to Linux and uses hierarchical protection domains there, but then on top of that it adds the Android stack and then uses capability-based security for Apps.


Given that the code of the extension is open and no additional secrets are required to compute the proper response to a server request it is impossible to know if the answer was actually computed by the extension installed on server B, by the extension running somewhere else or by code reimplementing the relevant parts.


Validating the key used to encrypt data without sending the key

This seems to be an authentication and authorization question, unless I'm mistaken. You wish to both authenticate and authorize users using a single code/string/key.

Encryption keys are designed to kept secret, they are called "secret keys" for a reason. There is no reason for a middle man (the server) to store any form of it. This would ultimately increase the attack surface without need.

I would suggest using two alternative secrets, in which the hashes are stored on the server. The first would be of the data, so that only users who can prove knowledge of the data via a hash can be authorized. The second would be of the alternative secret, such that if it was compromised (such as reading the data from a file system), the attacker would still have no idea what the true secret is.

Not only would this have the benefit of higher security (revoke the alternative secret) but also adds a level of authorization, as only those authorized should know the hash of the data.


"Microsoft Warning Alert" on Ubuntu computer

Yes, but you should also purge all the browser's caches, clearing just a history is not enough. If you haven't used it from root user - this is OK, if you did - then chesk the new programs on your PC, some malware tries to drop a scripts on target PCs. If you're concerning about this kind of threats much - I'd like to advise you to use a simple but powerful open-source PC monitoring program called Osiris - it will help you to detect any changes happened after the popup appeared.


I don't know anything about Dropbox in particular, but my understanding of  API keys from other storage providers like Google Drive, Amazon S3, etc is that they allow users to log in either through their apps, or through 3rd party apps and they want to be able to track which is which. The quote in the question makes it sound like this is about privacy: letting end-users know which apps are accessing their data and be able to revoke permission on an app-by-app basis.

There is also often a billing angle: Google Drive, for example, offers a free service directly to end-users through their own apps, but charges some $/gb to developers who want to piggyback on their infrastructure inside another product. Whether that app developer charges that to their users through a subscription, or just swallows it as a cost of business, is up to them.

This is where API keys come in: without an API key, an incoming request to the Dropbox server is just a request; you know which end-user it is because they have logged in, but you have no way of telling whether they are using your app or some 3rd party app, and if so, who to bill the bandwidth to. By embedding an API key in your app, you are linking each request your app makes back to your developer's billing account.

Since Android .apk files are fairly easy to reverse engineer, an attacker could conceivably extract your API key, use it in their app, and you'd get the bill.

Is the effort of protecting the key worth the risk? That's up to you. If you monitor your usage frequently or have set some kind of usage cap / alarm and are confident you can revoke the key quickly if fishy things start happening, then you're probably fine.

UPDATE:
As @XiongChiamiov points out in comments, you should also consider the disruption to service if you do need to revoke your key. Let's say you start seeing abnormally high billing or hit your pre-set usage cap. Your response would probably be something like:

scramble to implement better API key protection in your app
publish a security update to the Play Store with a new API key
revoke the old one.

The Dropbox feature of your app will fail until users update their app through Google Play. This will certainly cause some confusion among your users. Whether this is a big enough risk to worry about at this point is up to you.


8.2 is not your problem, 8.1 is.  It's referenced in 8.2:

  In addition to assigning a unique ID...

8.1 states:

  Assign all users a unique ID before allowing them to access system
  components or cardholder data.

If you log directly in to the root account over the network, then there is no unique ID involved in accessing the system.  The system audit logs do not provide any correlation between the activities performed by root, and the employee who performed them.

Most QSAs interpret 8.1 as disallowing direct root login for this reason.

With that said, nothing in DSS requires sudo to require passwords for authorized users who have already authenticated themselves to the system.  Subject to your QSA's approval, you should be able to use NOPASSWD: to loosen the requirement for typing in passwords by authorized administrators.


Is sending token authentication information via cookie headers secure?

As you probably know already WebSockets does not implement any authentication or authorization methods by design, so the only possible way is to implement that on your own or use methods provided by frameworks like Django. Implementing secure authentication is hard.

From the technical point of view, you just have no other option but to send the authentication information with Cookies header. The only security requirement that comes in my mind for WebSockets you have to remember is to use secure connection, so "wss://" is a must.

Another thing is how you use the value send by cookie header on the server-side. The values included in cookie headers are considered as not safe as those are under the control of a user (sender). You should validate incoming values if it is not providing any malicious payload (SQL Injection, XSS), that could harm your backend. In your example, you are sending token value to a database so you should be aware of SQL injection (but not only) and provide correct mitigations into DB queries.

For input validation please refer to this OWASP Cheat sheet
For SQL injection mitigation refer to this SQL Injection Cheat Sheet

The next thing is more general, how you use the token. You are passing the token into the database and on behalf of this, you are returning the user. It looks like you are using the token like user ID (I cannot be sure). Using the JWT as an authentication info you should consider a couple of things:

data stored in the token are not changeable, if some data about the user will change, you have to generate a new token

you have to validate the JWT token on every call according to the standard
I would highly recommend to use encrypted JWT tokens, which is more secure but also adds additional overhead on cryptography operations.

You have to take those points into consideration and analyze the pros and cons regards to your use case from the perspective of usability, security, and possibly performance.

In regards JWT please refer to these links:
JWT Authentication Best Practices - please check also the links at the bottom of this article and articles comments.


There has to be a specific way of randomizing brk() as well, as there are some heap implementations other than glibc's default (ptmalloc) that might not rely on brk(), leaving direct use of brk() unprotected to predictable address space if only va_randomize_space = 1 is used.

This is also important because attackers could craft shellcodes using direct SYS_brk system calls to map memory with a predicted address space to work on.

A quick look into the Linux kernel source code suggests setting ASLR to mode 2 does only just that: randomizes the start of the dynamic memory mapping address space:

https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c#L1110-L1123

<!-- language: lang-c -->

    if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
        /*
         * For architectures with ELF randomization, when executing
         * a loader directly (i.e. no interpreter listed in ELF
         * headers), move the brk area out of the mmap region
         * (since it grows up, and may collide early with the stack
         * growing down), and into the unused ELF_ET_DYN_BASE region.
         */
        if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
            elf_ex->e_type == ET_DYN && !interpreter) {
            mm->brk = mm->start_brk = ELF_ET_DYN_BASE;
        }

        mm->brk = mm->start_brk = arch_randomize_brk(mm);
#ifdef compat_brk_randomized
        current->brk_randomized = 1;
#endif
    }

https://github.com/torvalds/linux/blob/master/mm/mmap.c#L212-L213

<!-- language: lang-c -->

    if (current->brk_randomized)
        min_brk = mm->start_brk;


Can passwords be brute-forced through RDP?

The lockout-on-failed-logon thing usually doesn't apply to local admin/etc. You can enable a setting that locks it out, but the default setting is that the lockout setting don't apply to admin accounts.

I'm not sure about the throttling you mention though, but it is a very common thing to see thousands of brute-force login attempts per hour on windows servers with RDP exposed to the public internet. These show up in the security event log as audit failures with event id 4625. Very often they cycle through common user names, so maybe that's how they bypass throttling ( if throttling applies to RDP).

Related: I put together a windows service a few years that firewall blocks the source IP if too many of those audit fails appear in the event log within a given time span with the same source IP. Here's a link to a short writeup on that: http://huagati.blogspot.com/2014/02/blocking-rdp-brute-force-logon-attacks.html


Problems with Chrome, Skype and Discord - possible MITM attack?

It sounds like your problem doesn't come from your machine but, most likely, some other component in your network. The prime suspect would be your router. From your description, it olooks very similar to what would happen if your router's DNS configuration has been changed (at the very least).


Evaluation of Linux disk encryption scenarios

The level of security is directly tied to the risks of not encrypting everything else but the home directories. If you put sensitive data outside of the home directories (or forget that sensitive data should only be in ~), then you have a problem.

The other risk is that someone could gain control of your hardware and implant code in the system directories then return it to you. But if that level of protection is not in your threat scenario, then you can omit this potential.


The only reasonable solution, as commented multiple times, is to protect against XSS on the very beginning. You don't want to focus on the password box.
A successful XSS can do any possible harm to the web page, not limited to sniffing the input box, but also to redirecting the login form to possibly anywhere else, social engineer an official endorsement (BofA detected a security flaw in your browser, hurry and download our extension is a very succesful malvertising).
The browser is software under the user's control, so Developer Tools exist to help the (advanced) user take full ownership of the HTML document which is run on their end.
I believe your approach is wrong for this reason. As soon as your login page cannot be contaminated by XSS, and as soon the user is not installing a keylogger/malware extension into their browser, you have no reason to protect the password box.
Protecting from XSS is a totally different topic.


Is whatsapp messenger encryption similar to tls without a trusted authority?

WhatsApp uses the Signal which is conceptually much closer to PGP than TLS (and it's use of certificate authorities).

The whatsapp website has a good overview and an in depth whitepaper if you'd like to understand it better.


Is that possible for Linux and windows machines to be infected with KeRanger ransomware?

No, but it's hard to say this because it's a new kind of ransomware.

Ransomware isn't currently spreading to other computers, it only stays on the infected computer.


Should veil framework produce packed and obfuscated binaries which bypass virustotal?

The commenter, paj28, is correct: don't submit these to VirusTotal. Test them against the HIPS and AV systems you are specifically targeting in a VM-guest environment. I prefer using Vagrant along with the Packer and Boxcutter tools to "mock up" things in a lab.

Hyperion is great, but don't combine it with Pescrambler necessarily. You only need one cryptor, not two. What you ideally need is one cryptor and one packer, e.g., Hyperion and UPX. Try the various UPX formats and options: one will work after crypting. That would be the most-efficient and under-the-radar. Two cryptors or two packers is too many and "over the threshold".

Another factor is Meterpreter (or whatever baseline implant you are working from). It's not the best implant (some give away too much), especially not on Win32. It calls too many sensitive functions from too many W32 dependencies that are obviously malware. What you need is a different implant, such as Cobalt Strike Beacon or Silent Break Security Throwback. My favorite script circa Q42014 and Q1-2 2015 is veil_evasion.cna. It's in the official sources and probably PowerSploit, etc, but it can be loaded with a few others via this specific project from its original author -- https://github.com/HarmJ0y/cortana


How to implement cross-domain, auto-login SSO without browser redirects for unlogged users?

It seems to me this OpenID Connect scheme should do it. Note though that I'm not a security expert, so don't use it without further confirmation.

User is unlogged to a.com, b.com, sso.com.
User goes to a.com, clicks "Login".
Redirect to sso.com, with return URL on a.com as param.
User provides valid credentials. sso.com accepts them, redirects to a.com with Authorization Code as param. There's also an SSO session cookie for sso.com on the redirect response.
Browser follows the redirect, queries a.com. a.com server sends Authorization Code to sso.com in backend, receives Access Token & ID Token, sets session cookie on a.com. User is now logged in on a.com.
User goes to b.com.
Javascript on b.com makes a silent CORS AJAX call to sso.com, to a custom endpoint (e.g. sso.com/has-sso-session). The endpoint responds with essentially true / false based on the presence of SSO cookie on the request.
If the response is:

true, Javascript redirects the browser to sso.com, with return URL on b.comas param. This triggers regular OpenID Connect authentication, which will be automatic because user has an SSO cookie. At the end of it, b.com server sends Authorization Code to sso.com in backend, receives Access Token & ID Token, sets session cookie on b.com. User is now logged in on b.com.
false, Javascript sets an SSO check failed session cookie on b.com. This prevents further checks when browsing b.com, unless the user clicks "Login".


How to detect zip file encryption algorithm

7Zip archiver (freeware) has an info button that among other useful things tell you the encryption type an archive is using.

As a general note, .Zips usually use something called "ZipCrypto Deflatte".


How does the same-origin policy apply between browser tabs?

Can A.js call a function from B.js?

No, the javascript need to be defined on your current page

  Can A.js modify the DOM of page B.html?

Yes, but you need a reference AND have the same origin.

If page A have a reference to page B, it is possible for A to modify the DOM in B.

Page A can have a reference to page B if page A opened page B and saved the reference. Also page B can access page A via the opener property. You can open a new tab/page in javascript with the following code :

// Open a new window
var myWindow = window.open("", "myWindow", "width=200, height=100");

// Write some text in the new window
myWindow.document.write("
This is 'myWindow'
");

// Write some text in the window that created the new window
myWindow.opener.document.write("
This is the source window!
");

Same Origin Policy Limitation

The same origin policy limit what you can access. If the 2 pages are on different domains, you will not be able to access the window.document property to read or write. Here is a list of what you can access when the other page is from a different domain.


Are Linux vendor-supplied security updates enough for PCI Compliance?

PCI DSS requires that "the latest vendor-supplied security patches installed". (PCI 6.1 pg. 38). This means that if PHP releases a security patch, then you need to apply it, even if your distro doesn't have it in their repo yet.

Your rule-of-thumb is to look to the product version number and what the vendor (PHP, Apache, etc) has released, security-wise. Scanners and distro repos can help, but are not what needs to be checked or audited. Know what you have installed, and check for security updates regularly. Double-check your scanner results on a regular basis to account for false negatives, and confirm the findings to account for false positives.


If it is a catch-all address, they don't need the actual address.  The entire point of a catch-all e-mail address is that it catches all mail that would otherwise be undeliverable.  If you have thisIsMySuperSecretEmail@my-domain.com set as the catch-all, then if I sent an e-mail to bob@my-domain.com, you would get the message in the super secret mailbox unless there happened to be a bob e-mail account.

Catch-all addresses generally shouldn't be used as your primary mail address.  The point of catch-all addresses is to see if people are trying to get ahold of you by some other address (good for finding people trying to connect to dead accounts for example), however they are also always flooded by spammers who will routinely spam common e-mail addresses at any registered domain name.

If they are sending to that address specifically, it is possible that your mail server is disclosing the catch-all address in the way it responds to the servers that are attempting to send mail.


SSH : Remote Host Identification Changed

If an attacker gets control over one of the routers between you and the machine you are connecting to, they can redirect your IP packets to some other machine, which would then claim to be the real target. It might forward both your authentication and the following traffic.

Obviously, that machine would learn your password if you use one, see what you are doing on the remote machine, and could alter all data sent in any directions. Everything a man in the middle attack allows to do (which is different from passively observing the traffic).


Improve RDP security: router with VPN or IP whitelist on firewall

First of all,

There are always risks when opening up ressources to the internet. A VPN seems to be a reasonable approach to minimize such risks.

Now, have you thought about segreation of networks to reduce the impact of a compromised VPN access?

Also, your two options are not mutually exclusive - why not use a VPN to allow for connectivity and at the same time use IP Whitelisting to restrict access to the VPN?

Additionally, identifying the actual vector of compromise is key - just guessing is not quite a good idea.

PS: changing the default port is making everyones lives harder for almost no benefit in security - it's called "security by obscurity" and supposed to not be neccessary if everything else is in order.


Best Practice: frequency to change IPSec pre-shared key

Changing the key will give you any benefit only if all following properties are met:

The old key has somehow leaked and an evil-minded outsider knows it.
Whatever method used to leak the old key will not be easily and promptly reproduced by that outsider.
The aforementioned outsider has not completely plundered your data, installed malware and backdoors on your machines, and generally plunged your network into utter chaos, making the point moot.

Now that we have computers and networks, these three properties are only very rarely met together. The habit of changing keys regularly comes from older times, before computers, and in military contexts. Armies know that they must deal with, at any time, a number of infiltrated agents; such agents can deal some harm, but need time and continued presence of that; and cryptographic algorithms from the 1930s were invariably somewhat weak, making gradual leaks unavoidable. In an army from that era, changing keys on a weekly or daily basis made a lot of sense. In 2014 with computers and networks, much less so. Algorithms and protocols used in IPsec can encrypt thousands of terabytes without leaking anything about the key; and if an intruder learns the key then he will enact his mischiefs in a matter of seconds, not weeks. We can thus say that changing pre-shared keys for IPsec is mostly useless.

You may still need to change keys, as a "best practice", not to prevent or contain attacks, but to ease the qualms of people who still think with a 1930s' mindset, and believe that "security" is some sort of commodity that you can obtain in bulk and accumulate through best practices. Since there is no real scientific base for a key renewal frequency, every organization that publishes "best practices" tends to make its own mix, with frequencies typically ranging between "once per week" and "every three months".

Making sure that each clients for your VPN has his own pre-shared key, distinct from other clients, is another matter. That is very useful, because it allows you to basically evict any client without having to trust him for no longer using his key, and without redistributing a new key to all other clients. So don't renew keys on a regular basis; instead, make sure that each client has its own key. This will be a lot more useful for security.


How can I check whether Notepad++ is using a version of the SciLexer.dll library that was modified by the CIA?

From the website of the editor, you can download an archive (zip or 7z) of the version installed on your computer. Check the signature of your archive. Then unpack the archive and compute the checksum of its DLL (using SHA-256 for example) and compare it to the checksum of the installed DLL. Both should be identical.

If the checksum differs, you should post a ticket on your company's helpdesk with your findings. Let the admin find the solution to his issue (replacing the DLL or updating the application).

In the meantime, a portable version of Notepad++ is available on portableapps.com. You should check its DLL too, but you don't need higher privileges to install it.


How does Windows know which part of memory is "intended to hold data only"?

The memory itself is agnositic.  The operating system defines what each area is used for.  So windows "knows" because it said it was so.


Is haveibeenpwned (HIBP) free and reliable?

The HaveIBeenPwned API is safe to check for leaked passwords as the password or the hash is never transmitted via API. Here is how the API works,

You hash the password to be checked
Send the first 5 characters of the hash to the HIBP API.
The API returns hashes of used passwords that matches the hash's starting characters.
You check locally in your server whether the password hash is among the list.

To address your other points,

The service is free.
Yes, there is a policy about accepted usage.
In the homepage of HIBP there is a section called recently Added Breaches. At the time of writing, the most recent breach added is Dec 2018, the data was leaked on internet on Feb 2019 and added into the site in Apr 2019. You can aslo find the details on the twitter account. On average it would seem that 10 data breachs is added per month.

Other options

Option 3 is more or less the same as it uses the same service in the background.

Among your options, I will choose either option 2 or 3 as they will be updated more regularly.


What are the requirements for the TrueCrypt privilege escalation?

The vulnerability exists in a situation where you have TrueCrypt or one of it's forks on a computer that is a "shared" machine. For example, imagine you as Alice installed TrueCrypt 7.1a on a supported Windows Server, created a TrueCrypt volume, and then mounted it. Bob, as another user on the same server could potentially inspect the configuration of that volume and/or manipulate that volume's drive letter. It does not appear that the unencrypted contents of the volume would be directly exposed by the vulnerability. I agree with the person that reported the issue that if you are mounting TrueCrypt volumes on a shared system with other users currently logged on (or really any un-trusted process running), you have other problems to be concerned with.

For more information see https://code.google.com/p/google-security-research/issues/detail?id=537


You're mixing stuff up. The Tor browser runs locally, on your machine, the machine with the network card that has the MAC address. So, that MAC address never by itself leaves the local network. The internet doesn't care you're using Ethernet locally.

As you said, this might have been done to strip people of anonymity. It doesn't matter that you can't be recognized on the internet by your internal network hardware address if all that's necessary is proof that you've been the one doing something via Tor.

Since you brought up the law enforcement aspect: Your MAC address might not be worth anything on the internet, but when it's used to prove that it was in fact you, and not your flatmate on the same LAN, who did something, it might make the difference between being sentenced and being let go due to lack of undeniable proof.

Consider the fact that one of the motivations to use Tor is to evade state surveillance. If you had to scare away people from doing so, how else than via a deliberate leaking of identification providing info would you do that?


Rainbow Tables: What is the Reduction Used for?

It's a way of making a compromise between storage and computational requirement.

It's an implementation of a hash table: instead of storing all possible unique values in the table (which will result in real problem for storing indexing and searching the result), you simply reduce the number of computation needed to find a valid hash.

Basically, when you build the rainbow table, you create a hash (here called a reduction function because it reduces the size of the key space) of the result for each entry you try. You then store the original value in a bucket that is labeled with the result of the reduce function.

When you use the rainbow table, you do the following: you take the hash value you want to reverse, pass it trough the reduce function and look what inside the bucket that has that tag: you then try to hash each of the elements in that bucket and see if it matches your original value.

As to how to pick a proper reduce function, you will want one that will let you regroup all the data you see in manageable chunks: you don't want to have just a few large buckets or too many small ones. That's where a balance must be found. Other than this, exactly how you select that reduce function is not really important: you should try to use something easy to compute, that will split your data in statistically equal buckets and that will be easy to handle for your environment so, if you'd rather pick the last 6 numbers instead of the 6 first, it wouldn't matter in the end.


To start with, on the Adobe page you are linking to, it says:

  An untrusted document that tries to invoke an URL via JS displays the
  YMB by default. The user is given the option to trust the document for
  such actions via the Options button on the YMB.

In practice, this "effort" IMHO is next to useless, as PDFs would possibly circulate through your organization, and, one could imagine that there will always be one, more or less careless person, who presses the button. And that could mean opening pandora's box.

You need to understand that passing a PDF around which contains any malicious code is like passing a parcel around that contains a bomb. Even worse if copies get made. Bombs don't replicate, PDFs do. And we cannot tell when and where it may explode. So it's better not to want to let it in at all.

This then boils down to the question you are asking already, is it reasonable not to accept PDFs with embedded JS? If we are talking only CVs, my initial intuition would be: "Absolutely". I cannot see why a CV would need any interactivity in the document which would be the only use case for embedded JS, that I can think of. Typically, embedded JS can be used for PDFs which contain forms that can be filled in by the reader where one could choose from options for example.

That leaves you with the question of either scanning and rejecting PDFs with embedded JS code or to remove the embedded JS code during the scan procedure. The latter, is not really a technical or security question but there may or may not be legal aspects to that.


Jamming is the radio equivalent of shouting. The jammer drowns your communications under a lot of noise. Defence against jamming usually is a combination of the following:

Power: speak louder. I.e. increase the power of your radio-emitting apparatus, so that it will take more noise to drown it. Of course, this increases energy consumption and heat dissipation, and it is not necessarily workable with your devices at hand.
Tightening: try to use directional radio beams. The sender will send a non-isotropic signal, much stronger in one direction than in any other; the receiver will also concentrate its reception ability on this specific direction. This has been used in aircraft navigation systems (see this). This kind of solution requires directional antennas, and, more importantly, proper orientation: the sending device must know the approximate direction of the receiving station, and vice versa.
Frequency hopping: switch frequencies over a large range of possible frequencies. Sender and receiver agree upon the sequence of frequencies that they will use. This relies on the idea that it is much harder to jam a large spectrum than a single well-defined frequency. GSM/3G signals already includes frequency hopping, and the sequence is nominally unpredictable by outsiders because it is agreed upon under the cover of the cryptographic layer (subject to possible weaknesses of the cryptography as used in GSM, of course). Note, though, that in normal marketable equipment, frequency ranges are legally constrained, and it is still relatively easy to jam all frequencies which have been allocated to GSM and 3G.
Retaliation: a jammer is an active attacker; it emits a strong signal. This allows for tracking the jammer, and send armed goons to shut it down and appropriately reward the jammer operators, e.g. with some free dentistry.

The bottom-line is that if there was a way to force communications to go through even in the presence of active jammers, then the Military would use it. But in the battle between jammers and defenders, the jammers are currently winning.


Go for AES.

AES is the successor of DES as standard symmetric encryption algorithm for US federal organizations. AES uses keys of 128, 192 or 256 bits, although, 128 bit keys provide sufficient strength today. It uses 128 bit blocks, and is efficient in both software and hardware implementations. It was selected through an open competition involving hundreds of cryptographers during several years.

DES is the previous "data encryption standard" from the seventies. Its key size is too short for proper security. The 56 effective bits can be brute-forced, and that has been done more than ten years ago. DES uses 64 bit blocks, which poses some potential issues when encrypting several gigabytes of data with the same key.

3DES is a way to reuse DES implementations, by chaining three instances of DES with different keys. 3DES is believed to still be secure because it requires 2112 operations which is not achievable with foreseeable technology. 3DES is very slow especially in software implementations because DES was designed for performance in hardware.

Resources:
http://www.differencebetween.net/technology/difference-between-aes-and-3des
http://www.icommcorp.com/downloads/Comparison%20AES%20vs%203DES.pdf (offline, still in the Web Archive)


What is the meaning of Triage in Cybersec world?

We just got reports that 4000 of our systems are infected with ransomeware.

3000 are end users, 800 are non-critical servers, 200 are critical servers.

Triage is looking at this mess and deciding which order to start restoring systems in. We can't tackle them all at once, so we have to look at some and say 'Sorry, little Inspiron that couldn't, you get to sit there and be useless for a while.'

It comes from the medical world, as you've stated. It's the same reasoning as an ER doctor looking at two patients and deciding to work on the one that they're more certain they can save. You let one go, as hard as it may be, so that the other might live. If you'd worked on the worse injured person, it's possible they both would have died.

The difference in the security world is that often it's dollars lost due to users being unable to work, rather than literal life and death. You work on the systems that you are most likely to be able to restore, and that will return the largest amount of productivity to the environment. You leave the individual laptops that only affect a single user to the side, for now.


Random number for HTTPS Message Authentication Code (MAC)

Modern browsers do the smart thing: they ask the operating system. The OS interacts with hardware all day long; that's its main purpose. So it is in the right place to gather randomness and mix it with a properly secure cryptographic random number generator. On Windows systems, this is made available to application though the CryptGenRandom() function. Linux has the special file /dev/urandom for that. Some programming languages offer their own API for that (which internally feeds on the OS), e.g. java.security.SecureRandom for Java.

The hardware sources that the OS may employ primarily includes the cycle-accurate time at which hardware events occur (e.g. the precise nanosecond at which you press a key, or a network packet is received). The OS can thus get "enough" true randomness to power a RNG, which will then yield good alea by the megabyte ("good" = "indistinguishable from true randomness, up to an overwhelming work factor" = "good for crypto").


Outlook rule to forward all emails - is that a common scam?

In my professional experience, this is not a common step from "hackers".  However, I don't have any hard numbers to back that up, so I wouldn't take that statement as anything more than anecdotal evidence.
However, it's worth stating the obvious about why the hacker did this.  What it really comes down to is that the attacker used this, effectively, as a hidden backdoor to continue to maintain access even after initial discovery.  Indeed, this is what happened, as the attacker continued to get copies of all emails even after you reset the password on the email account.  Working on the assumption that this attack scenario is less common, it suggest that this might be a more targeted attack, which is worth further scrutiny.
The fact that the hacker took this additional step means that they were interested not just in full access to the account, but that they were also interested in read-only access to incoming emails.  There are three main uses I can think of for read-only access to a user's email:
1. Compromising further accounts
As long as they receive a copy of all emails, they can reset the password for any third-party accounts that the affected email address is registered with.  After all it usually just takes that "reset" link to reset a password, and if they trigger a password reset they'll get a copy of the link too.  They will no longer be able to delete the reset email in the original inbox, which might cause suspicion, but that won't stop them from resetting account access anyway - it just might mean they get caught quicker.
If you found out about the hack because the attacker used their access to break into other accounts, then this forward rule may simply be an attempt to extend their access and allow further "damage" even after the initial discovery.  This is probably the least-painful scenario (for you).
2. Intercept business transactions (aka Mandate Fraud)
One scam I have heard of is attackers intercepting legitimate business transactions by having access to internal information from the billing team, typically for larger transactions.  To pick a random example, imagine you were a roofing company and the person who owns this email address is on the billing team.  They email a customer a $15,245.36 invoice and instruct them to send a check to your office.  The hacker sees the same email and follows up to the customer a couple hours later with a spoofed email from the same email address (but with a different reply-to) that says, "Oh wait, there was a mistake in my last email.  Please send that $15,245.36 to this address using this other payment method".  This can be a very effective scam.  By spoofing the same email address and injecting themselves into the conversation with full knowledge of the details of the transaction, it can be very easy to convince the person on the other end to simply do as instructed without even raising any red-flags.
If the email address belonged to someone on your accounting team, I might be worried about this kind of situation - such attacks definitely do happen.
3. Good old fashion snooping
It could be that the person wanted to have access to otherwise privileged information.  This might be the case if, for instance, the compromised account belonged to someone in upper management.  One example would be a lower level employee that had brief an unsupervised access to the managers computer.  If the machine was left unlocked they could easily launch outlook and setup a forwarding rule in (probably) 30 seconds with practice.
I mention an employee simply because they are probably someone more likely to be "generally" interested in someone's emails without necessarily having a specific goal.  While such an attack can generally be very easy to perform in an office environment, it's also obviously a bit risky, so it isn't on the top of my list of possibilities.
Summary
All this to say: personally I think this is less common, so I would be concerned that the attacker had a specific goal in mind for this particular account.  I could be overly paranoid though.  What this means is that it is worth considering exactly what an attacker might have to gain by continuing to have read-only access to this particular user's account.  If they are someone with access to sensitive information about your company, I would be more worried.


Technically, if the attacker is sitting between point (A: Your Device) and point (B: Server/ Another User/ ..etc). The attacker will be trying to sniff all the traffic between A and B in order to get access to sensitive information.

Now theoretically speaking, the attacker will be generating a larger amount of traffic since he is sniffing the traffic, maybe modifying it before relaying it to (B), on top of the network traffic it generates.

Now, just because of a attacker generates a large amount of traffic on your network, is not necessarily a correct indication that an MITM attack is taking place.  However, the device in question may be a likely candidate. Even then, it is not a valid indication.
Also, it is import to note that the attacker not necessarily needs to sniff of the traffic originating from (A), it is possible to regulate it, in this case, your hypothesis of double the traffic generating will fail.

I am not sure if you are understanding a MITM attack properly. Here is an Okayish guide that might be useful: https://www.wandera.com/mobile-security/man-in-the-middle/man-in-the-middle-attack/


What is the best way to generate a password/pin like string using brute force method?

Regardless of whether this is a reasonable thing to do, it is possible to enumerate a large set with a random order without having to store them all in RAM. Basically, you need a permutation over your source set (the 7-character strings, of size 367) such that the permutation "looks randomish" and can be evaluated efficiently on each element. Such a permutation would be known as a block cipher.

Usual block ciphers use large binary blocks, i.e. work on the set of sequences of 64 or 128 bits, not on the set of sequences of 7 characters; however, other constructions are known which can bring decent security for such "small", non-binary blocks. This field of research is called format-preserving encryption. Rogaway's Thorp shuffle is one of the rather easy to implement proposals, and has decent efficiency.


Why aren't TCP sockets encrypted by default?

Modern networking follows the Seven-layer OSI model which is successful due to the principle of separation of concerns.

  The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

TCP/IP is layer 4 ("Transport")

  The transport layer provides the functional and procedural means of transferring variable-length data sequences from a source to a destination host via one or more networks, while maintaining the quality of service functions.

SSL/TLS is layer 6 ("Presentation")

  This layer provides independence from data representation (e.g., encryption) by translating between application and network formats. The presentation layer transforms data into the form that the application accepts. This layer formats and encrypts data to be sent across a network. It is sometimes called the syntax layer.

In other words, it is a conscious design choice.

Also, TCP predates SSL by several decades.  To wit, SLL keeps changing because weaknesses are found; meanwhile, TCP has remained mostly the same.  The OSI model allows easier adoption of changes by keeping some things constant while varying others.  If we built encryption into TCP, then it would be a far less stable protocol.


control flow (buffer overflow) (introductory question)


Online Retailer asks for a copy of Credit Card and Drivers License

This is rational response. Better be safe than sorry.

Any goods purchase that contains the delivery address (software purchase may not have the info) that similar to your credit card is verifiable by the issuer.

Point 1 is not always true because it depends on the level of escalation, i.e. the middleman like Visa/Master/AMEX may have a delayed clearance issues with the bank. So the logical way to deal with this is calling the bank support.

Point 2 is valid, you should never send a copy of your credit card/ID to through email.  At minimum, the merchant should at least provide an encrypted web interface to let you upload it. If they cannot do it due to cost and commission issue (some payment gateways are pretty expensive), then they should ask you to contact your bank than performing such shady process, even it is legitimate request.


I don't recognise my DNS server's address: does this mean I am compromised?

Something in your environment has definitely been compromised. It seems more likely that your router has been compromised. You haven't provided much information, so I'm going to make some basic assumptions:

You're at home
You are behind a commercial router, provided by your ISP
You haven't done anything to secure your router
Your linux desktop is a DHCP client of the router.

These devices often have default passwords that users never change and critical firmware vulnerabilities that go unpatched. As a DHCP client of the router, your Linux desktop is going to pull DNS information as part of its DHCP request, and so will see the behavior you've described above. Configuring other DNS servers in resolv.conf is only a workaround. I strongly suggest that you try to log in to your router (probably @ 192.168.1.1, based on your screenshot). I bet you won't be able to. You'll probably have to reset it to factory defaults, then log in. You'll want to secure it better - update firmware, change default passwords, and hope that's enough.

For confirmation without logging into your router, check the DNS configuration on your Windows desktop. If it points to the same 46.161.40.29, then it's very likely the router.


Is recursively encrypting files inside containers of increasingly stronger or equivalent algorithm encryption worth it?

There really is no value in double or triple encrypting data in the manner you describe. First, as a non-cryptographer, you cannot know the level to which you may compromise the crypto process. You absolutely can do that when combining algorithms. A good example of this is 3DES, which is really 3 cipher rounds of DES with the 144 bit key being three 48 bit keys, is more secure doing ENC->DEC->ENC than doing ENC->ENC->ENC. How do I know this? Some crypto guy told me. How did he know? He understood the cryptanalysis.

Information protection does not layer up the same way physical protection does (fences, cameras, locked doors, armed guards, key swipes and passcode, etc.). Some solutions might work like physical protection, but us normal humans can't really tell.

Also, if it did work really well, why aren't cryptographers advocating for the types of layered crypto you describe? I suspect the answer is that the value add (if there is value) is not worth the effort or complexity.

Also, packing keys along with the cryptext (if I understood your proposal) sounds like one need only break the exterior cipher in order to peel back every layer of the onion and get the inside text.

You've inadvertently hit upon the most significant problem with encrypting data at rest (stored data crypto): what to do with the encryption key? A large crypto key makes the data safe. You can't memorize it and you certainly can't memorize a 2048 RSA private key sequence. Where do you put it? How do you protect? You could encrypt it, but then that becomes a recursive problem - what to do with the new key? Ultimately, some human needs to open a wallet or a key store of some type, which means that human has to memorize a long sequence of characters containing enough entropy (true randomness) to be worthy of the data and/or keys it's protecting. That's why people are enamored with USB fobs. Of course, that's a physical object, which is a PITA to carry around and, if lost, often results in loss of all keys and plaintext. In the end, the human may write down the passwords and put them behind a locked door or drawer.  So, back to physical security...


Network administrator knowing all user passwords

This means that the IT department is liable for the knowledge of those passwords. Anything that happens on the network can no longer be attributed to the user, but now it could be the user or anyone in the IT department or anyone with access to the password store.

IT should not want that responsibility.


How can I protect myself from Evercookies?

If you really are worried, build yourself a new virtual machine each time you want to use the Internet.

If may be that some websites take a signature from everyone who connects to them so if you are that worried you should also connect from a different physical location each time, use TOR etc. But this process will negatively impact your enjoyment of the delights the Internet has to offer.


Sign Your License File

You want to sign the data with your private key to create a signature.

Generate a license file
Sign the file with your private key.
Provide the public key with your application
In your program, verify the file contents have not changed with your public key.

The signature cannot be replaced since only you have the private key to sign the license.  If any piece of the license file has changed then the verification will fail, and you can stop execution of your program.  Notify the user as you see fit.  The important part to realize is that you're not stopping them from modifying it, but if they do then they invalidate the license.

Encryption is the wrong route to take because no matter what you would have to hard-code the encryption key somewhere in your application.  Signing the data is much more secure.

Here is a nice introduction to how signing data works (opens a PDF).

Signing Data w/ .NET

I believe this MSDN article will show you all you need to digitally sign an XML file in .NET.  There is a full code example at the bottom.

You'll need to create your own RsaCryptoServiceProvider, and setup properties to only contain public keys.  Then during installation you'll need to export your public key to the service provider using ExportCspBlob(false).  You can export your public key in a well known format like PEM and hard-code it.  Here's an example with lots example code for working with encoded strings, creating RsaCryptoServiceProviders, etc.

That last link includes an example that exports the private key as well as the public.  You don't want to include this!


How to check that an e-mail service provides encryption between the mail servers?

You can look at the raw email headers and see if they have pertinent information in there.

I've just looked at a few that came via Google and noticed Received: from XXXXXXXXXXXXX(XXXXXXXXXXXX. [x.x.x.x]) by mx.google.com with ESMTPS id xxxxxxxxxxxxx.73.2014.06.24.07.31.28 for version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128.  That suggest to me that Google received it via encrypted SMTP.

However, I believe that the messages that email servers place in the headers do not follow any mandatory standard and therefore it could be delivered via an encrypted SMTP connection even when the headers don't state that.  I suppose it's unlikely (but not impossible) that any service provider would claim that they received it via encrypted SMTP when they haven't, so it's a safe bet that if all your hops are encrypted then you're OK (but not guaranteed).


IIS won't forward the logged on user credential to webservice request?

This is a better question for Serverfault.

What you need to do for this to be workable is to configure Constrained Delegation. With a regular NTLM logon, your credentials aren't forwardable to another service.

With a Basic (you may need to change the LogonType value to allow it) logon, you could do this because the target server has your credentials; with NTLM, it's not able to make the second hop.


How do I restrict network access to LAN for visitors

The solution really depends on what your environment is, and what you're willing to put into place. There are a few solutions that come into mind, including the ones mentioned in other answers here:

Separate VLANs for public meeting spaces, and internal workstations. The downside of this is that a smart attacker can perform a VLAN hop (depending on the implementation), and end up in your workstation VLAN.
802.1X, which requires you to implement a RADIUS server, and a fair bit of management on user workstations to ensure that they have the right authentication profiles and certificates to talk to your network.
Network Access Control (or in Cisco language, Network Admission Control) which lets you authenticate users using LDAP, based on MAC address, or other mechanisms depending on your NAC implementation.

Of these three, VLAN is probably the cheapest in terms of effort on your part in configuring the environment - you don't have to do anything on user workstations, and you just have to ensure a proper segmentation of the network. 802.1x is more expensive in terms of effort and adoption, but still cheaper than a NAC solution. The NAC solution is probably going to be the most effective, and most expensive of the three, especially if you get a solution that doesn't need to deploy an agent on the workstations. It will still require some user training depending on how you implement it, but it is much harder to bypass a NAC control than it is to bypass VLAN restrictions.


There is a very helpful document on this from IBM that can enlighten you on your query.

  It is necessary to enable remote
  parties that have established trust in the initial environment
  to also establish trust in the vTPM environment at
  a later point in time.
  For example, the strong binding of TPM credentials
  to those of the hardware platform is important to challenging
  parties during remote attestation. The challenger
  must follow the trust chain from the target platform’s
  hardware TPM through a virtual TPM and into the runtime
  environment of the associated virtual machine.

Pay special attention to page 6.


Does password-protecting a server's BIOS help in securing sensitive data?

The most common thing protected by the BIOS administrator-level password is the boot process. Someone with admin-level access to the BIOS (either by it being unprotected, or via password compromise) can set the computer to boot from whatever media he likes. This will allow an attacker to bypass access restrictions you have in place on any non-encrypted data on your drives. With this, they can:

Read any data stored unencrypted on the drive.
Run cracking tools against local user credentials, or download the authenticator data for offline cracking.
Edit the Registry or password files to gain access within the native OS.
Upload malicious files and configure the system to run them on next boot-up.

Of course, access to the BIOS generally means that the attacker has physical access to the computer already. At this point, all bets are off anyway - many BIOS's (and their passwords) can be cleared by a simple jumper on the motherboard, or the attacker could just pull the hard drive and do what they like with it on their own system. That said, a lot of the recommendations in my post here (and other answers in that, and linked, threads) are still worth considering.

Encrypt the hard drive
Make sure the computer is physically secure (e.g.: locked room/cabinet/chassis)
Use strong passwords for encryption & BIOS

Password-protecting the BIOS is not entirely an effort in futility. However, it must not be a measure that is solely relied upon. For the password on your BIOS to be effective in its purpose, there must be other measures in place to prevent it from being bypassed.


When calling a process from another process, Is sending stdin password more secure than sending an ENV variable?

Neither. Both ways of providing the password can be bypassed (rather trivially) in the same way (replacing the target executable with your own or checking the child process state at runtime).


How does YubiKey protects it's secret key?

If it is plugged into an infected computer, wouldn't the secret key be compromised?

The yubikey stores the key on its internal storage media -- the exact mechanism varies depending on the type of key. When yubikey is plugged into a computer, it is recognized as a USB keyboard. Pressing the sole button on the yubikey will send a string of characters containing your one-time password, just as if they were typed via a USB keyboard. The manufacturer assures that the secret key used to generate one-time passwords can never be read off of the device, regardless of the software installed on the computer it's plugged into.

  Also, is it possible for a computer virus to "infect" a YubiKey?

Everything is possible, but would be very hard considering the limited functionality of a yubikey.


AES-256 is a specific algorithm, and it's the same algorithm whether you use the key 3e9e98e31ba18d8d18283aceb3c6e17016b729e1363afc5bea8bf7df295b03e9 every time, or derive a key with PBKDF2 from some password, or choose the key by flipping a coin 256 times.

So this is not a contradiction.  But that doesn't mean their system isn't full of red flags!

They're abusing the technical term ‘zero-knowledge’ from the cryptography literature, which suggests that their marketing department is better-funded than their cryptography department.
It's hard to imagine why they use a 128-bit master key and then expand it with PBKDF2.  If the 128-bit master key is actually a passphrase, then there is no reason to limit it to a 128-bit space; if it's chosen uniformly at random, it's hard to imagine that they can't afford the additional storage for a 256-bit key—especially if they're also storing a salt!—and there's no reason to use something expensive like PBKDF2 instead of (say) HKDF.
They're hiding their design, which suggests they are so embarrassed by it they don't want anyone to see how bad it is because it might hurt their business.  (But they will likely rationalize this to themselves by pretending that other businesses would copy their bad design, which would be foolish because there are obviously better public designs available, or that adversaries won't be able to figure it out, which would be foolish because designs are much harder to conceal than keys as Kerckhoffs' observed over a century ago.)


Confused about RFC 4492: difference between "ECDH-capable public key" and "ECDSA-capable public key"

That wording is an abbreviation; the key is (or keys are) actually the same, the difference is whether the certificate allows use of the key for the relevant purpose. See section 2:

  Note that there is no structural difference between ECDH and ECDSA
     keys.  A certificate issuer may use X.509 v3 keyUsage and
     extendedKeyUsage extensions to restrict the use of an ECC public key
     to certain computations [15].  This document refers to an ECC key as
     ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
     defined similarly.

[15] refers to rfc3280, which has been superseded by rfc5280. If the KeyUsage extension is present in the cert, it has the digitalSignature bit set to allow use of the subject key for ECDSA, and/or the keyAgreement bit set to allow use of the subject key for ECDH. If KeyUsage is not present, the key can be used for any purpose otherwise acceptable to the program(s) using the certificate.

In principle ExtendedKeyUsage can also be used, but I'm not aware of any EKU values defined -- and more to the point, implemented by common software -- for these specific usages. (There are lots of EKU values defined for other things, including distinguishing server SSL/TLS from client SSL/TLS.)


Secure (P2P) Client/Company File Sharing

A solution has been in place for many years. It's called SFTP. It's a direct client-to-server connection with an encrypted channel for upload. The technology is so old that many, many clients exists and even some browsers will allow you to connect to SFTP servers.

All you need to do is to set up a small server on your end with access to the Internet. You provide the login details to your clients and they can upload to their heart's content.


Why is it a bad idea to escape HTML before escaping SQL?

With regard to database security, it's irrelevant. SQL doesn't care if the string contains raw HTML or escaped HTML or whatever.

But as explained in the other question, this messes up the data. I would actually consider it a bug.


The only known way to ascertain the security of a cryptographic algorithm is to leave it under close scrutiny of hundreds of cryptographers for several years, and see what comes out. So the right perspective here is historical.

MD5 was published in 1992; it was actually designed the year before (1991). In 1993, first weaknesses were spotted, then bigger weaknesses in 1996 (collisions on the compression function, found by Dobbertin). It took 8 years for these weaknesses to be turned into actual collisions by Wang, in 2004. Seven years later, in 2011, we can create MD5 collisions at will (and much more efficiently than with Wang's original method), but preimage and second-preimage resistances of MD5 are still as good as ever.

From this we can infer that when weaknesses are found in hash function, they do not appear overnight: we have quite some time to react. Also, the first MD5 weaknesses were discovered only one year after its publication, and that was in the early 1990s when the public research in cryptography involved much fewer people than nowadays.

Let's see what this gives for SHA-256: first published in 2001; ten years later (2011), we still have no clue whatsoever on the slightest hint of a weakness. This would be suggestive that SHA-256 is indeed robust, and collisions for SHA-256 are not just right around the corner. Also, I have not looked in full details at the Bitcoin protocol, but it seems that collisions are not a real danger for Bitcoin -- it rather relies on preimage resistance, for which not only SHA-256 is rock solid, but even MD5 would still be reliable.

However, it is dangerous to make statistics on a single measure. In 2007, it was estimated that there was a relatively high risk that the attacks on MD5 could be transported to SHA-1 and then SHA-256/512 -- this prompted NIST to organize the SHA-3 competition. It turned out that attacks on SHA-1 have somehow stopped progressing, and there is no attack on SHA-2. Whether this is because SHA-2 is really robust, or because all the cryptographers are busy trying to break the SHA-3 candidates, is not known (but my opinion is the former: SHA-2 is a secure hash algorithm).


The documentation you cite means only that the "average" user which has no deeper understanding of cryptography should only use the higher level cryptographic functionality. The cryptographic primitives should only be used by somebody with a deeper understanding of cryptography. Without such understanding it is easy to make serious mistakes leading to insecure software and don't even realize that these are mistakes.


How to check for a key *and* store encrypted data?

Why don't you use Authenticated Encryption? If user gives right key, encryption succeeds and you can return data to the user. If key is wrong, encryption fails and you won't give the data.

Look at solution used in TrueCrypt. User's password is stored nowhere in encrypted container. It is verified by decrypting of TC volume header and verifying some data after decryption. More details here: Encryption Scheme

Solution used in TrueCrypt is not an Authentication Encryption, but it shows well that you don't have to store user key/password to know if password entered is correct.


The main advantage of a refresh token is that it is easier to detect if it is compromised.

Consider these two scenarios:

A single long-lasting auth token is used.
A short duration auth token is used, and a long-lasting refresh token periodically requests a new auth token once the previous one has expired.

In scenario 1, if the auth token is compromised it would be hard for anyone to detect this, and the unauthorized access could continue indefinitely.

In scenario 2, if only the auth token is compromised (refresh token is not compromised too), it could only continue until the token expires.

In scenario 2, if the refresh token is compromised, once the refresh token is invoked, all other auth tokens that were generated using that refresh token are invalidated, so only 1 party can use the api (per refresh token) at a time. This results in multiple users repeatedly invalidating each other's auth tokens by generating new ones. The api could detect the breach because refreshes are being made prior to the auth token expiration, and would know to immediately revoke the refresh token.


Is there any point in using PGP or S/MIME when your receipients mostly don't use it?

... company with sensitive customer relations

Given that many common mail clients support at least S/MIME by default, it actually makes sense to use it. This means that mails should at least be signed by S/MIME. Signing does not cause any problems when mail clients do not support it, but provides solid sender authentication for S/MIME capable clients and thus additional protection for customers against mail spoofing. To make it easy for customers the signing certificate should be issued by a public CA though, which is already trusted by the client.
One might argue that DKIM together with DMARC provide similar protection. But in practice support for these is less common in mail clients, which means that the client must rely on their mail server to properly check both - and most actually don't. Also DKIM+DMARC only cares about the sender domain and not the actual sender. But it makes sense to use DKIM+DMARC in addition to S/MIME signing.
Using PGP instead does not make that much sense. Contrary to S/MIME PGP does not rely on a central PKI and thus there is no easily established trust relationship to the sender. Instead each customer would need to be explicitly trust the senders key, a concept many customers will not properly understand.
For more sensitive B2B communication it makes also sense to not only sign the mails but also encrypt it. There are several mail gateway products which offer centralized automatic S/MIME handling for such use cases so that the whole process is mostly transparent to the employees.


Connecting to Oracle Database from VBScript - Hiding Credentials

Consider using a credential authenticated VB .NET TCP session to your database server as the secure interaction agent for your process. Microsoft has an example here.

If the first level support folks have the certificate for the VB transactions on their systems rather than the DB certificates you will not have to expose anything more than the capability your have already decided to delegate to them.  The DB certificates can remain on the database and be used to kick off the change in authorization needed once the secure VB request comes in from the help desk.


Azure Ad B2C Users access resources in other directory

Customers who need direct access to your key vault will need to be added as Guest users in your primary tenant (the one with key vault). B2C users cannot be granted access to resources in another tenant. Adding them as Guest users technically makes them "B2B" users. https://docs.microsoft.com/en-us/azure/active-directory/external-identities/b2b-quickstart-add-guest-users-portal
Your other option, depending on your architecture, is to have them access key vault through a lightweight proxy API and use the Graph API to access Key Vault SDK or Graph API to access key vault. This won't allow you to manage access directly in key vault though.
API Options
Authorize B2C users in Web API: https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-web-api-dotnet?tabs=app-reg-ga
Authorize B2C users in Functions App: https://codemilltech.com/adding-azure-ad-b2c-authentication-to-azure-functions/
Key Vault Access Options
C# Azure Key Vault SDK: https://docs.microsoft.com/en-us/azure/key-vault/secrets/quick-create-net
Graph API for Key Vault: https://docs.microsoft.com/en-us/rest/api/keyvault/
The last option of using Graph API also requires an app registration with key vault access in the primary tenant and you can get a token using the client credentials grant with Microsoft Graph as the scope as described in https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow)


You have a few misconceptions in your diagram.
The most important is that both your encrypt boxes are wrong, they should say sign. Following from that, the CSR sent to the CA includes the various fields (including Subject) and the subject's public key, there is no ciphertext involved just plain data and a signature.
RFC2986: PKCS#10: Certification Request Syntax details the steps to build a CSR:
The process by which a certification request is constructed involves the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

The subject's (in your case: applicant) public key is included verbatim in the CSR, as is the subject information. This is signed using the subject's public key and everything sent over to the CA.
Not in diagram form, but here are the steps to build the CSR and which data is included:
The correct steps to build the CSR (not in diagram form) are:

Build a CertificationRequestInfo using:

Subject Distinguished Name
Subject Public Key
Other attributes

Obtain Signature by signing the CertificationRequestInfo using Subject Public Key and a particular algorithm Signature Algorithm.
Construct a CSR object by including:

CertificationRequestInfo
Signature
Signature Algorithm

Send this CSR blob to the CA.

Note that the CSR still contains plaintext CertificationRequestInfo and Subject Public Key.
Upon receiving CSR, the CA will more or less do the following:

parse the CSR
verify that the signature matches the fields in the CSR by using the subject's public key
verify that the various fields match its requirements (eg: you can't ask for CN=google.com without proving that you own the domain)
craft a certificate using some fields from the CSR, some from itself
sign the certificate using its (the issuer) private key

The final certificate still contains the subject fields and the subject's public key.
To more specifically answer your two questions:

the subject's public key is one of the fields in the CSR. Nothing is encrypted, just signed.
The subject fields are copied into the final certificate, they are there for any client to see.

You can see list of certificate fields in RFC5280. There is no hash of the CSR because there's no need for it, all relevant information was copied into its own fields of the certificate.


Server protection measures from authorities

The most important factor here is that seizure of the server does not result in your identity as the server's owner being revealed. This must be accomplished by both purchasing the server anonymously, and by not keeping anything on the server which may be linked to you. This is important enough that, without knowing your specific threat model at least, I would consider buying a dedicated server from a company like Ecatel anonymously and forgoing the extensive physical security you have put in place. The reason is that, with enough effort, any physical deterrence measures can be bypassed. A few notes on your current setup, though:

  I have placed a thick resin to JTAG ports, PCIe ports and RAMs, in case of a cold boot attack.

Be aware that you would need to use tamper-resistant epoxy (and non-conductive and non-insulating at that), not just any thick resin, otherwise it may be possible to destroy it with various solvents. In addition, cold boot attacks do not always require physically removing memory. There have been instances where a server's BIOS was modified on the fly to trigger a low-memory footprint cold boot attack. Just because your RAM is epoxied down doesn't mean your RAM is safe.

  ESXi shuts down automatically when chasis intrusion is detected.

Chassis intrusion is often very easy to defeat.

  I have a CCTV installed in the server room and if it detects too much movement, it will cut power to the server.

There are many ways to defeat this. For example, gradually dimming (or increasing) the lights so no sudden change is detected. Eventually the lights will go beyond the camera's specifications and it will be effectively blind to any further motion. You can prevent this by using motion sensitive software which takes into account the risk of gradually changing ambient light levels to hide motion.

  What more can I do to be more safe?

There are other things you need to take into account. Before you decide to host something highly illegal, you need to really understand in detail both your adversary, and various ways your anonymity can be defeated. For example, when you SSH into a server, your public key is uploaded to it. Unless you explicitly disable this in the configuration, every server you SSH in to will be able to know you are the same person, even if you use a different IP. Additional things to keep in mind are keystroke biometrics, where your unique typing pattern (monitored either over the wire or on a compromised system) can be used to identify you. Anonymity is hard if you are going high-profile.

You must use remote attestation if you are going to be managing this server remotely. Setting up remote attestation can be complicated, but it is absolutely vital in this scenario. It will protect from firmware tampering as well as intercepting your LUKS password as you send it over the wire. Remote attestation is a technique using a device's TPM (yes, they are safe) to prove to a remote party that the software and firmware exists in a specific, known-good state. It will be able to send back to you a quote which cryptographically ensures that the server is in a good state.

But the most important thing of all... maintain your OPSEC!


Information on the specifics of how behavioral antiviruses work?

I will suggest you to look to https://www.clamav.net/, is an open source implementation, so you can check and see how works an AV in general. Of course, the commercial AVs will tell you how good they are, but basically all AVs found a similar approach, rules, syscall interception, behavior of open files and so on.


What is the best way to approach and generate apparmor profiles?

apparmor is to protect services... for example if "something" tries to change configuration files of a protected service...  Look at this.

To test it you must try to change any service... Not sure about how to test it with apache, but if the point is test if apparmor is working, you can doit with another service I know how it works:

If you install isc-dhcp-server package, by default I think ubuntu is protecting this service... then you can try to launch the dhcpd command setting a config file directly in the command (something like dhcpd -d -cf <yourPathToConfigFile> <yourInterface>)... you will see it doesn't work, even if your configuration file is good. It only works if the file is in /etc/dhcpd/.


How was the hacker able to get my Instagram tag through Facebook when they weren’t linked?

Mapping someone out on the internet is possible with OSINT. They would have used OSINT tools to find the various social media connections your gmail id would have. It's pretty interesting how much you can find out about someone with just an id or a full name.
And with respect to your phising, it's always important to be very cautious while opening links, always check the site address carefully the link is taking you to.