I use the exploit proftpd_133c_backdoor ...

From the documentation you can see that:

  This module exploits a malicious backdoor that was added to the ProFTPD download archive. This backdoor was present in the proftpd-1.3.3c.tar.[bz2|gz] archive between November 28th 2010 and 2nd December 2010

But you are obviously using a version of proftpd which is not affected by this backdoor:

  My victim virtual machine ... proftpd 1.3.4a

No wonder that it does not work. In fact, it is the expected behavior that it does not work.


Interesting question.
If i understand correctly: fake.php is the frontend to login.php on the main server, and you are spoofing both.

If i am, then:

I would record the user's internal IP, and credentials, then store it.
if the ip that visits login has been there before, forward the data to the real server. If the password is correct (check using some kind of regex kung-fu), great, step out of the equation. If it isn't, forward the incorrect password page and go back to fake.php, repeat the process and replace the incorrect credentials stored with the correct ones.

I would personally recommend using scapy or bettercap.


Dealing with spam with an unknown party harvesting the email address

In the United States the CAN-SPAM Act of 2003 regulates all commercial e-mail.  You can try e-mailing each company individually and telling them they don't have your permission to contact you and if they don't you will file a complaint with the FTC.  You can find out more information here:

http://www.fcc.gov/guides/spam-unwanted-text-messages-and-email

You can file a complaint here:

https://www.ftccomplaintassistant.gov

You could also look at complaining to their ISP.

in reality, though, once your e-mail is out it's OUT.  You will get more and more messages.  The easiest fix would be to switch e-mail addresses.  If this is not possible there are a range of spam filtering services from local programs you use on your computer to hosted solutions.  The latter are usually more expensive but also more effective.  One exception is that some commercial e-mail hosts such as google can take over hosting your e-mail for a very small fee (around $5 per address per month) and are VERY good at filtering spam.


Is there value in changing your password after failed (malicious) login attempts?

If the password was randomly chosen, then there's no reason to do so.

There might be a reason if someone is trying targeted password at you. ie: if they know you like horses, you are born on 1990, and you're from Alabama, then they might be trying all combinations of these words. Changing your password then could be useful, but not because someone is trying to break into your account, but because the password wasn't originally random.

Another reason could be that someone else found your password on a paper and it contains "0" and "O" and "o", so they are trying all combinations of these.

So for random passwords that were not printed, it's useless.

Knowing that users actually come up themselves with passwords instead of generating random ones, changing your password in such case would probably be less secure, because you'll quickly run out of ideas for your password, and chances are you'll come up with a simpler and simpler one every time you change it.


How to avoid session fixation (Login CSRF) by MitM attack without HSTS?

You can't. You need to have your site in the HSTS preloaded lists to avoid this type of MITM attack otherwise the attacker could MITM the first connection and set the session cookies to fixate it to the attacker's session.

  However, I cannot use HSTS because the same domain needs to serve some HTTP content for historical reasons. ...the historical HTTP content contains embedded IFRAMEs from domains that do not support HTTPS

This should not stop you from setting an HSTS policy.

For example, host your historical content on legacy.example.net. Note that this needs to be a different domain from your secure content (www.example.com), not a subdomain for submission onto Chrome's Preloaded list as the includeSubDomains flag needs to be set on the header. If your historical page was http://www.example.com/iframe.htm replace this with a redirect to http://legacy.example.net/iframe.htm. This will allow you to serve the historical HTTP content and embed an iFrame to a HTTP domain without any browser security warnings.

So a user navigating to some historical content with HSTS preloaded will get the following process.

User enters the normal URL for the content in their browser's address bar: http://www.example.com/iframe.htm.
Browser checks its own HSTS preloaded list and finds www.example.com.
Browser upgrades the connection to TLS by changing the URL to https://www.example.com/iframe.htm
Server receives request and issues a 301 redirect to http://legacy.example.net/iframe.htm
Server at legacy.example.net displays IFrame containing 3rd party HTTP content, and everybody is happy.

This will allow you to use HSTS for your application while allowing historical IFrame hosting content to function without issue. Also, you might find my other answer on protecting against login CSRF useful, as it also covers MITM attacks.


Is there any potential harm in opening up junk emails in Outlook in the browser?

TL;DR It's possible depending how your browser and email client handle files. Remote images are a potential risk with targeted attacks.

It depends on the security of your browser and other factors.

Risks of Remote Images
There is the possibility your browser will view remote images. These images could be unique to that specific email and be used to let a spammer, phisher, etc read your message. They could get your IP Address and try to get more information this could be used as part of a targeted attack against you. Remember databases with IP Addresses get leaked all the time. If your attacker is smart enough and has the right resources they could steal your identity all with only an IP Address.

Browser Security / Web Client Security
If you are using an outdated browser if your email provider does not properly strip malicious inline JavaScript (emails can use HTML therefore inline JavaScript) you could become infected if a security issue in your web browser exists.

Attachments
Many attachments such as .docx files could be infected to install malware on your computer. You shouldn't open unknown attachments. You can scan first with VirusTotal even then please only open them at your own risk.


why credentials are not shown in mitmproxy?

You can't see the credentials because the application required to have a valid certificate. If the certificate is not valid, then the application won't process the HTTPS connection.

If you use mitmproxy to perform MiTM attack, that means the application uses the mitmproxy certificate.

Maybe you can try the application to process the untrusted connection.


Google login 2 factor authentication sms -fake or real?

These appear to be valid Canadian numbers but are not Google numbers so not legit. Also not likely to actually be from the numbers listed. Far too easy to spoof caller ID's I'm afraid.

Scammers don't need your number, most operators have a range and auto-dialers can call huge numbers of phones in a short space of time.

Unfortunately there is little you can do though it may be worth reporting to your carrier, your local telecoms regulator and your local law enforcement organisation specialising in cyber crime if you have one (Action Fraud in the UK for example). Although you won't normally get much response, occasionally, when a large number of reports are received, something may be done about it.


Can one use IP-spoofing to anonymize DDOS attacks?

The other answers seemed wrong to me, so here is my attempt.

Yes.

This is very common, and has recently seem attacks in the rage of hundreds of gigabits per second. The idea is not to spoof your IP to the target machine, but to spoof your IP to an intermediary that returns data back to your spoofed IP (target).

It is generally not very easy to spoof source IP addresses, so having a direct distributed DOS against a target (i.e: SYN Flood) using all fake addresses would be very difficult. If you are able to spoof a few addresses, you would have the best luck abusing a service that would result in an amplification (DNS, NTP). So the purpose of spoofing the address here is not to hide your IP, but to make the intermediate think you are the victim, flooding them with unsolicited responses.

The attack would go something like this:

The attacker spoofs the victims IP address, and sends a 60 Byte DNS request to an open resolver.
The resolver responds to the victim's IP, a 4000 byte TXT record

Here is some more info on recent attacks:

https://www.watchguard.com/infocenter/editorial/41649.asp

http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack


The name is just a reference to the Hail Mary Pass:

  A Hail Mary pass or Hail Mary route in American football refers to any very long forward pass made in desperation with only a small chance of success, especially at or near the end of a half.

It's been used as a metaphor for anything desparate with little chance for success, which brute force attacks always are. If you read how it works it's sorta clever, for brute force, but each action is very low chance of working, which is why it needs a Cloud to work:

  Each attempt in theory has monumental odds against succeeding, but occasionally the guess will be right and they have scored a login.


Can any of your recognisable personal information be linked to your device fingerprint?

The device fingerprint is calculated using several technical parameters sent by the client, like the IP, the default language, the screen size, etc. and may also include data gathered with some "tricks" involving HTML canvas, etc. Normally people will not consider this to be "personal information", however the GDPR (European law on privacy) says that personal data is any data that can be used to identify you, even indirectly.
Here's a few relevant quotes from the GDPR:

Article 4 (1): [...] ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, [...]
Recital 26: [...] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. [...]
Recital 30: [...] Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them. [...]

So a device fingerprint is a piece of data that can be used to identify you indirectly. By definition, it does not contain personal data like your name or your phone number, but only technical information about your client (which on the web is your browser). The fingerprint alone won't identify you, it's just technical data.
Let's suppose YouTube uses fingerprinting. And for some reasons I actually suspect it does, but I'm not sure anyway. You watch some videos while logged in with your account, John Doe. Then you log out, clear the cache, turn off the computer, and go to bed. The next day you go to YouTube, you don't log it, and you will expect YouTube won't recognize you. But you are using the same browser, sending the same user agent, with the same viewport size, same language, same "whatever" coming from whatever trick can be done with HTML/JS/CSS. Plus, you are even watching videos at the usual time, clicking on stuff the same way as usual, searching stuff using your usual keywords... YouTube says: "Guess what, I'm pretty sure this is our friend John Doe. Let's try to suggest some videos that we know John Doe likes".
I hope the concept is clear. The fingerprint alone is pretty useless. It may become valuable once it gets liked to other data: at that point it can be used to identify you, or track you on the same site or cross-site. It's like a cookie that is hard to delete, and is not very reliable (lots of people may share the same fingerprint). Like a cookie, alone, it doesn't mean anything, it's just a random string, but it becomes useful once it's linked to other data for a purpose.


Despite the fact these guys claimed to be 'anonymous', they were not actually anonymous and happily communicated in open environments (even if they were, for the most part, behind proxies etc). They all had handles associated with their identified. As a result, it was possible to slowly build up a profile and identify the suspects. One they correctly identified sabu, they flipped him and convinced him to coerce the others into providing information that would reveal them.

Some key failings as highlighted here as well as a fairly detailed writeup about it all:

  reusing "anonymous" usernames and variations on them for many years resulting in "bleeding" of his identity elements (ie. usernames,
  e-mail addresses, domain registration information) between different,
  supposedly-unrelated social media and online accounts;
  giving out too much personal information about his political/national affiliations/ethnicity;
  accidentally logging once or twice into IRC chat channels without first anonymizing through VPN or Tor proxies;
  mentioning in a chatroom a domain name he owned, whose whois status—i.e. its domain ownership information—had not always been set
  to private, and which once listed his real name and address,
  subsequently preserved on the Internet;
  On an Internet that forgets nothing, once a document is made publicly available, even if only briefly, it may be archived in
  perpetuity. One old clue to even one element of a still-in-use
  identity can be enough to take down even the most careful hacker.

Another presentation worth viewing which provides evidence used in the trials as excerpts here


how does OpenSSL create X.509 certs from SPKACs?

A certificate request is "just" a token requesting that a CA issues a certificate with contents set as the CA sees fit. The CA is supposed to fill the certificate with information that it partially obtains from the requester, but also from other sources. In any case, even if a PKCS#10 request allows for specifying a complete DN, the CA is not bound to issue the certificate with exactly that DN. For instance, no sane CA will issue a certificate to me, with the DN "CN=Barack Obama,O=US Government,C=US". It may issue a certificate with a DN "CN=Thomas Pornin", but only because the CA "knows" my name by some out-of-band mechanism (e.g. the request has come through a SSL tunnel, in a session in which I was previously authenticated).

However, if the CA can verify the DN from a certificate request, then it already knows the name, and thus it does not really need the name from the request itself: the CA can put the correct name in the certificate by itself.

The SPKAC certificate request format is just an old barebone format which assumes that the CA already knows everything, except the public key. The "challenge" and the "signature" are extra security feature to prevent some attacks (e.g. the signature prevents me from requesting a certificate which contains the public key of someone else).


How does MariaDB's ed25519 auth scheme work?

What is stored on the server?

When setting password, the password is turned into bytes (don't know which encoding is used), then the password bytes are hashed with SHA-512 once, to produce the "left half" and the "right half" of an ed25519 private key. The "left half" (first 32 bytes of the hash output) (well, byte 0 and byte 31) is clamped to valid curve25519 private scalar "a", and this is multiplied by the curve generator to get group element "A", an ed25519 public key. The resulting value is serialized back to 32 bytes, and the value is then stored encoded with base64 (43 bytes without the final padding byte "=") as the user's hashed password.

This process is entirely deterministic - there is no salt.
Every user with the same password will have the same hashed password.
Every time a user changes their password back to a password they already used before, the hash of their password will be set to the hash used before. There is a unit test to verify this fact. Code, unit test.

What is sent during login?

When the client wants to login using this scheme, the server sends a 32 byte random nonce, the client asks user for password, generates the same ed25519 private key and performs what I'll trust is correct ed25519 signature of the nonce using the private key and send the signature back to the server. The server then does what I'll trust is correct ed25519 signature verification. If the signature is verified successfully then you're logged in.

This to me seems to be secure - performing an ed25519 signature of random 32 bytes should be secure and never reveal the private key itself, and the signed value is long so it won't repeat.

code: 1 2 3 4 5 6

Is the scheme secure without TLS?

Well, it won't trivially reveal your password to a network eavesdropper (though using mysql without TLS will reveal all your queries, all your data, and allow an active attacker to wait for you to login and then take over the connection and do whatever they want with it). I don't know how much better or worse this is than login by HMAC(password, random nonce), but I guess it's ok.

How resistant is it against password dumps?

Not at all. Since it's fully deterministic, it already fails. But can we crack the password hashes? curve25519 scalarmut on CPU is about 75,000 per second, but in 2013 it was about a million per second on GPU (source), so a modern password cracking rig can crack those passwords quite fast even without using a lookup table (which you can do because it's deterministic!). So it completely fails to be a decent password hash.

What is the name of this scheme?

No idea. "hash a password directly into a ed25519 private key"?

Is it used by anything else besides MariaDB?

I hope not.

Are there other implementations?

java , C#

Final words?

The MariaDB documentation strongly implies this is secure because it's exactly like what openssh does to authenticate by ed25519 keys, but shows examples which use human generated passwords, which never happen with ssh-keygen. This password hashing scheme is secure only when the "password" typed in by the human is a uniformly random value at least 256 bits long (64 hex bytes, 24 words chosen from a dictionary of 2048 words) - meaning a computer generated key, not a human generated password. This is completely insecure for human generated passwords!


If your metasploit console is not public accessible, the cellphone will never be able to connect. That happens if you are running the console on your computer on the local network.

Run metasploit from a VPS with a public and reachable IP, it must work.


When we talk about this sort of set-up (I do not claim knowledge of the specific product), its generally along the lines of PKI.

http://en.wikipedia.org/wiki/Public_key_infrastructure

You are correct, generally speaking.

Normally one buys a CA certificate, and thus do not have to distribute the CA certificate. When one have a 'local' CA, normally the user have to download the certificate (containing the public key) somehow and set it as trusted root locally to have various browsers or third-party software working properly.

Again I speculate from general experience, not specific experience in your product.

In the case of for example PGP, trust/certificates are distributed through specific public servers where you can search and publish.

PGP and similar can be used with Outlook through plugins.


How can I give users access to thier data without requiring any authentication?

It depends on what you think will be acceptable for the users. If you want to avoid usernames and passwords, so that they won't have to remember anything more to be able to access your system, then you might consider implementing some kind of email-based authentication.
You could make that a one-time link, sent via email to the user. The first time the user visits that link, a cookie is stored in their browser. After that, that link becomes invalid and visiting it will have no effect at all. The cookie might expire at the end of the session, or be persistent, depending on your needs. When the user drops or invalidates the cookie (by closing their browser, or deleting the cache, or clicking on a logout button, etc.), or when your server decides to invalidate the cookie (after a fixed time, etc.)., the user will then have to request another one-time link, which will be sent to their email address.
That way, user authentication will be based on either of these factors:

Access to the user's email account. This is something only the user is supposed to be able to do. Most websites with single-factor authentication actually rely on the security of the user's email account.
Access to the user's cookies, which basically means access to the user's browser or machine. This is usually an acceptable way to authenticate, unless you need to protect the users in situations where they might share their machines with others. Depending on your needs, you will have to decide whether you want to make cookies expire after a long time, or at the end of the session, or after a fixed short time even before the session is over.


Why do compromised web sites often take you through multiple URL redirections?

There are actually two cases here:

A site which is serving malicious ads (Malvertising)

In this case the attacker does not compromise the site itself but is misusing targeted ads to select the victim based on its specific capabilities (browser, OS, geolocation,...) and attack it. Due to the way targeted ad delivery works it uses a lot of redirect between various sites, i.e. the majority of redirects are not for malware delivery but part of the usual ad delivery process. See for example How real time ad serving works for more information. There might be some malware specific redirects at the last stages for the same reasons as described for the second case below.

A site which has been compromised by an attacker

In this case the visited site is compromised by an attacker. The attacker will usually only put some minimal redirect onto the compromised site for the following reasons:

Harder to detectIf only some redirect code is installed and not the malicious payload the chance is higher that the compromise will stay longer undetected by the owner.
Protect the malware from researchersThe malware is precious for the attacker. If some security company would get hands on all the malicious code when cleaning the compromised site and could analyze it and thus add protections for their customers, thus making the malware less valuable suddenly.
Increased flexibility in updating malware
If the malware gets detected by security systems the attacker needs to install the next version. Also, the malware might not be owned by the attacker itself but one attacker might just redirect the victim to another attacker which develops and hosts the (always up-to-date). Both attackers share then the profit (i.e. kind of franchising).
Protection against takedowns
By using redirects the attacker can build a more flexible infrastructure which is more robust against takedowns or blacklisting.


Metasploit command shell session died from EOFError

You should upgrade the session to a meterpreter session before the firefox session dies by using:

use post/multi/manage/shell_to_meterpreter

and set the session id of the firefox session:

set session <id>

and then run it:

run

That will upgrade the session to a meterpreter one. You interact with it by using the command

sessions -i <id>

Then if you want to come into the OS native shell, you can write
shell
from the meterpreter session

UPDATE

An easier solution to upgrade sessions to a meterpreter one is:

sessions -u <id>

where id is the firefox session id on your case


How Concerned should I be about VM Escapes?

TL;DR version: You should not be worried about VM-escaping malware if you do things right - the likelihood of that is pretty low.

Having said that, the internal networking scenario you described (common virtual between host and guest) is not sufficient to protect against VM escapes in the form of worms. Most host services would listen on any network interface, including the internal virtual interface that is common with your guest. This means that malware with worming capabilities looking to exploit vulnerabilities over the network (e.g. the good old WannaCry-wannabe's gunning for EternalBlue, the new kids with BlueKeep, etc.) executed on your guest may be able to reach your host via the shared network.

The answer is simple: isolate the two as much as possible, with no common network interfaces between the host and guest.

In my years of digging through harmful code, malware capable of escaping VMs has been extremely rare - threat actors are frequently staging their attacks, with multiple downloadable components, so they don't burn all of their tools early in the chain. VM escapes come really late in the game, when the threat actor has ascertained that they are not on a honeypot or a forensic station, they are certain they have not been detected, and then and there they would initiate a next-stage download.

Most of the time malware would run checks if they are in a "sandboxed" environment, e.g. it will check for Internet connection, presence of virtualization, and several other criteria (such as the presence of meaningful files in the user's profile) - these are usually the tell-tale signs that the code is executed in a sterile "forensics" environment, and the code will simply not run. So completely cutting the Internet may also not be feasible.

It's best that you do your experiments in a completely segregated environment, but that's not always feasible, especially for the novice - the investment may be substantial.

Hope this helps!


AWS Security - Dev Test Staging Production Environments

Based on our AWS DevSecOps oriented experience a mixture of 1, 2 and 3 would probably be the most effective solution.

1) Have separate AWS accounts for each environment and use consolidated billing?
Absolutely agree this was the official rec we've gotten from the AWS support at early 2017. The multi-account architecture segregating user-mgmt, security-audit-logging and shared-resources-services and project-app accounts will reduce the blast radius to the maximum possible.

Consider the following AWS official links as reference since the AWS Organization structure will depend on your specific requirements.

AWS Multiple Account Security Strategy: https://d0.awsstatic.com/aws-answers/AWS_Multi_Account_Security_Strategy.pdf
AWS Multiple Account Billing Strategy: https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/
Authentication and Access Control for AWS Organizations:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_permissions.html (keep in mind EC2 and other services can also use AWS IAM Roles to get secure cross-account access - Security Audit on AWS - question on findings)

For it's automation you'll have some alternatives like AWS python SDK + bash or terraform (consider that if your org has less than 10 accounts managing it from the AWS Web Console will be very straight forward). However keeping in id an IaC (InfraAsCode approach with Terraform or AWS Cloud Formation is almost a must do from our point of view).

How to Use AWS Organizations to Automate End-to-End Account Creation: https://aws.amazon.com/blogs/security/how-to-use-aws-organizations-to-automate-end-to-end-account-creation/
AWS Organization Terraform: https://github.com/binbashar/bb-devops-tf-aws-organizations

2) Create separate VPCs per environment? - keep in mind we'll likely want multiple regions/availability zones for High Availability
Since we assume we're going to implement multi-account AWS Org approach then will have at least 1 VCP per account x environment. In our case having one VPC in a certain region it's enough since for High-Availability, Self-healing, Redundancy and Resilience we use a multi-availability-zone (multi-az) configuration (eg: us-east-1a, us-east-1b and us-east-1c, will be extended in 3). Keep in mind choosing your region evaluation both network performance (latency - https://www.cloudping.info/) and costs (N.Virginia-us-east-1, Ohio-us-east-2, Orego-us-west-2 - https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/).

Post steps to have in mind:

VPC Peering: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Network ACLs: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-recommended-nacl-rules.html
RouteTables and Routes: https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations-partial-access.html
DNS Route53 private hosted zones association / sharing: https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/
VPN solution: https://pritunl.com/

Let's consider the following info to evaluate if multi-region is also needed.
As defined in the official doc -> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of Regions and Availability Zones. Each Region is a separate geographic area. Each Region has multiple, isolated locations known as Availability Zones

So for as hosting our HA Apps in a region but within isolated locations (datacenters) it's enough referening to the per region AWS SLA of:

AWS will use commercially reasonable efforts to make the Included Services each available for each AWS region with a Monthly Uptime Percentage of at least 99.99%
availability: 99.99%
durability: 99.999999999% (depends on the storage class)

If because of compliance frameworks you still need a Multi-Region active-active method: Then by architecting multi region applications and using DNS to balance between them in normal production status, you can adjust the DNS weighting and send all traffic to the AWS region that is available, this can even be performed automatically with Route53 or other DNS services that provide health check mechanisms as well as load balancing. For multi-region architecture please consider: https://aws.amazon.com/blogs/aws/latency-based-multi-region-routing-now-available-for-aws/

ref-sla-links:

https://aws.amazon.com/compute/sla/
https://aws.amazon.com/rds/sla/
https://aws.amazon.com/s3/sla/
https://aws.amazon.com/s3/storage-classes/

3) Separate subnets per environment. Or should we use separate subnets for web severs/database servers/management-administration type servers? To get the desired multi-az deploying for Production Grade environments at least 3 Private Subnets (through a redundant AWS Nat-GW - at least 2 of them in different az) and 3 Public Subnets (through Internet GW) of course each one in a separate AZ. And for Dev/Qa/Stg (can be consolidated in a single account for cost efficiency) and have at least 2 private and 2 public subnets in different AZs. This applies for EC2 & RDS (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html), for S3 versioning and multi-region replication it's recommended

Based on the before presented let's present our reference architecture.

AWS org multi-account architecture

user-mgmt-acct (centralized iam roles based cross-org approach - iam roles per accout to be assumed still needed).
security-audit-logging-acct (centralized account to have centralized logs like cloudtrail, vpc-flow-logs, alb and cloudfront access logs, among others, centralized firewall manager setup, or any other AWS service or sec&audit tool).
NOTE: To simplify the architecture the before mentioned accounts can be consolidated in only 1 account.
shared-resources-services-acct 1 x VPC + 2 prv-sub-nw + 2 public-sub-nw (multi-az) + 1 x nat-gw + VPC-Peering with project-X-app-accts (here you'll orchestrate your Software Development shared tools like, VPN Solution, Monitoring tools like prometheus and graphana, CI/CD server, maybe jenkins, drone, spinnaker, etc, multi-purpose infra K8s cluster, centralized logging solution like ELK or self hosted Splunk).
project-A-dev-stg-acct: 1 x VPC + 2 prv-sub-nw + 2 public-sub-nw (multi-az) + 1 x nat-gw + VPC-Peering with shared-resources-acct
project-A-prod-acct: 1 x VPC + 3 prv-sub-nw + 3 public-sub-nw (multi-az) + 2 x nat-gw + VPC-Peering with shared-resources-acct
project-B-dev-stg-acct: 1 x VPC + 2 prv-sub-nw + 2 public-sub-nw (multi-az) + 1 x nat-gw + VPC-Peering with shared-resources-acct
project-B-prod-acct: 1 x VPC + 3 prv-sub-nw + 3 public-sub-nw (multi-az) + 2 x nat-gw + VPC-Peering with shared-resources-acct

SECURITY - Miscellaneous

NOTE1: Remember to encrypt every service storage at rest at least with AWS encryption - https://docs.aws.amazon.com/aws-technical-content/latest/efs-encrypted-file-systems/encryption-of-data-at-rest.html

NOTE2: The 5 Pillars of the AWS Well-Architected Framework - https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/

NOTE3: AWS Tagging Strategies - https://aws.amazon.com/answers/account-management/aws-tagging-strategies/

NOTE4: Prevent AWS Secrets to git repository -  https://www.binbash.com.ar/archives/1038


User login credentials used for file encryption

Yes, this is a workable approach. A few issues string to my mind, though.

You should salt the bcrypt hash as well, not just the PBKDF2 function
You should not use the random 256 bits directly as an encryption key (unless you know exactly how your RNG works and always will work in all future versions). Use that random data as an input material to a proper key derivation function (like HKDF) instead.


Can't get dnschef to redirect my target computer to my attacking computer's setoolkit cloned site

Ended up using Ettercap. Don't know what the problem was, but I've had nothing but success with various ettercap experiments and starting the apache servers manually.


What are the differences between Session Ticket and Session ID based Session Resumption?

Update: Warning: my understanding of this is botchy. See Dave Thompson’s comment.
——————————————

Will only Session ID based Session Resumption update symmetric TLS session key ?

Neither method will do that.
To quote Adam Langley: (line breaks mine)

TLS offers two session resumption mechanisms: session IDs (where the server and client each store their own secret state) and session tickets (where the client stores the server's state, encrypted by the server).
If an attacker can obtain the session resumption information for a connection then they can decrypt the connection.
(This needn't be completely true, but it is for TLS because of the way that TLS is designed.)

Source: How to botch TLS forward secrecy (27 Jun 2013) (Archived here.)
Further reading

https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/
https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
TLS 1.2 has never provided any Forward Secrecy against a compromise of the Session Ticket key at all, so even with 0-RTT 1.3 is an improvement upon 1.2.
Added 2017-01-04: See section 2.2 "Session Resumption" here: Springall, Drew and Durumeric, Zakir and Halderman, J. Alex, 2016, Measuring the Security Harm of TLS Crypto Shortcuts


How to mitigate the risks of using new, third party imported electronic accessories?

The risks of buying compromised hardware to spy on a common user is grossly overestimated. By several orders of magnitude. The absolute majority of security personal on all the world will die before being able to see such a thing on his hands. Way more people will die by lightning hit than those hit by Lightning-of-the-death cables.

First: compromising hardware is expensive. Adding additional gear to spy on you while maintaining all original functionality takes time, skill and resources, so the creator of it will not dump crates full of compromised Lightning cables on Aliexpress to sell everyone.

Second: the exploits are precious. Very precious, and the value of any exploit decreases every time it is used. If someone abuses the exploit and uses lots and lots of compromised hardware, security solutions will start to detect and alert users, turning the compromise ineffective on the long run.

Third: there are easier ways. There are lots of cheaper and more effective ways to compromise our systems, so hardware modification is so down the list that we can care about all the other ways first: phishing, hole watering, drive-by downloads, DNS manipulation, vulnerable firmware, and the list goes on. Those attacks are way cheaper, and more effective.

How to mitigate such risks? Don't buy obviously fake hardware, or vastly cheaper versions, keep security systems updated, and take care of external devices connected to the network: tablets, cell phones, and so on. Common day-to-day security advice.


Detecting datasets that were affected by SQL injection

If you already experienced an sql injection attack:

MySQL by default doesn't log all queries[1], as it would impact performance significantly. It's also not enough to just consider the tables your webapplication directly accessed.

If you don't have logging or auditing enabled, determine what tables would be considered "high value" in the main database. Think: users, user_creditcards, oauth_keys. Anything that might yield a gain (financial gain, further access, passwords) for your attacker. Those are probably compromised.
Also consider any other databases the user used by the webapplication has access to.
Use replication? [2] Find the attack period of time in the access logs and inspect the MySQL Binlogs available for that time. This will only give you modifying queries (UPDATE/INSERT/DELETE/CREATE/ALTER/DROP).
Is your network monitored? Is the database on a different host and the connection unencrypted? Ask the network security guys if they have any captures of the network traffic. Investigate captures with Wireshark [3].
Determine if LOAD DATA INFILE / INTO OUTFILE [4] was available for the database user. If so, you should also further investigate the server hosting the database for further signs of compromise.

If you're trying to design an incident response procedure/defense tactics or config guidelines:

Consider using an audit plugin [5]. Determine your high value tables. Audit access to those tables by the relevant users. The resulting log may contain highly sensitive queries, protect accordingly. Implement retention policy.
Consider deploying a WAF to atleast catch indications of attacks. See if you can flag an IP as suspicious and logging all its traffic for a period. Again, this generates sensitive data. Protect accordingly.
Limit the database user on the webapplication to the absolute minimum it should be able to access. This also means looking at if you can limit the access patterns for the database user: does it have to be able to SELECT * FROM secrets or would it make sense to limit this application user to a stored procedure ala CALL findSecretByIdentifier('MySecretIdentifier');?

Resources:

[1] http://dev.mysql.com/doc/refman/5.7/en/query-log.html

[2] http://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog.html

[3] https://www.wireshark.org/docs/dfref/m/mysql.html

[4] http://dev.mysql.com/doc/refman/5.7/en/load-data-local.html

[5] https://github.com/mcafee/mysql-audit


How to get and use constantly changing cookie JSESSIONID values in Hydra?

You can keep the session ID in the http response in a variable in the python prox and you can also send this session key with http requests.

https://forums.kali.org/showthread.php?18055-Hydra-using-Proxy
https://null-byte.wonderhowto.com/how-to/sploit-make-proxy-server-python-0161232/


Banks storing credit card data in plain text?

(Some assumptions here for the lack of references)

According to this Visa page, issuing and acquiring banks are subject to the PCI DSS:

  All entities that store, process, or/and transmit cardholder data,
  such as merchants, service providers (e.g. payment gateways, IPSP,
  processors), issuers and acquirers, must comply with the PCI DSS

As such, they must keep copies of the PAN encrypted.  They may store the expiration date and cardholder name unencrypted.

The DSS prohibits storage (encrypted or unencrypted) of the CVV; however, by definition the issuing bank must know the CVV in order to validate it.  That means that either they store it, or they recalculate it (as per this excellent link that @WhiteWinterWolf provided in the comments).  It would not surprise me if there was some exception to allow the issuing bank to store the CVV, probably encrypted (it's arguably more secure to store many derived values than it is to expose the key to constant use) but that's pure speculation.

Update: @dave_thompson_085 pointed out in the comments that the PCI DSS explicitly permits issuers to store the CVV as per DSS section 3.2:

  It is permissible for issuers and companies that support issuing
  services to store sensitive authentication data if:

  There is a business justification and
  The data is stored securely.

On the other hand, I think it's fair to assume that the acquiring bank is not permitted to store the CVV of cards it processes.  There is no business driver for it and it would be out of line with the DSS's otherwise draconian approach to CVV handling.


What would be required to monitor Amazon Alexa traffic?

As you noticed, Alexa could record all the time and send it only after you say the wake word. You could notice it by larger upload size. But at the same time Alexa could analyse the recordings and only send interesting parts like when you mention the word "bomb" which reduces the upload size so you would only notice it if you look at the traffic in a very detailed way. You also cannot block it in a comfortable way because you would need to do a detailed analyses of the data before it is sent which most likely makes the use of Alexa meaningless because it is more work then doing the work Alexa should do yourself.

But you have 2 options:

Use a trusted client instead of the vendor provided (I don't know if one exists)
Use another trusted device that powers on Alexa when it hears the wake word and all the other time cuts the power line.


What are the methods to find hooked functions and APIs?

Hooks are implemented in a whole bunch of ways:

Modifying legitimate jump instructions to point at hooks instead of the normal code.
User call table (IAT) hooking - modifying the addresses of user-mode APIs in a process.
Kernel call table hooking (e.g. SSDT / GDT ) - replacing a call table pointer with the address of your hook.
WndProc hooks (e.g. PeekMessage) - hooking onto window notification messages.
Legitimate callbacks like PsSetCreateProcessNotifyRoutine.

I'm guessing you're most interested in the first two types.

Jump hooks can be created in a near-infinite number of ways. This makes it almost impossible to write a tool to identify the hooks. However, you can use integrity checking tricks, e.g. comparing code in the binary file (e.g. exe or dll) to the code in memory. You could also hook WriteProcessMemory and other such APIs to detect modification of process memory, though this only works against user-mode attacks.

IAT hooks are a little easier to check for. Take a snapshot of the IAT of a process when it starts (e.g. from the static binary) and compare the in-memory IAT to the real addresses of the functions that should be in there. For example, if you know IAT entry 4 points to user32.MessageBoxA, you can use GetProcAddress to find the real address of that function and compare the address in the IAT to that. If they don't match, you know it's been hooked.

For further reading, there's a great paper on the subject, and I highly recommend reading "The Rootkit Arsenal" by Bill Blunden.


How did I get hacked and what was accessed?

I believe I found the vulnerability. On my linux box's Desktop Sharing app I had enabled "Automatically configure UPnP router to open and forward ports" a long time ago without realizing it. My old router did not support UPnP so it hadn't been an issue. Not only does my new router support it, but it apparently is enabled by default (WTF TPLink thanks for that!). When I run a port scan against my IP address with my desktop computer off, no ports were open. When I run a port scan with my desktop computer connected, the default VNC port 5900 was open, and sure enough on the router a port forwarding rule had automatically been created via UPnP.

My suspicion was that a bot port scanner discovered my open VNC port and connected to it, then tried a bunch commands intended to install malware/ransomware on a windows machine. It probably opened my formerly-unlocked password file via a custom hotkey I have (SuperKey+P), and all my open folders to home were probably the SuperKey+E, and Cinnamon melange window was probably opened via SuperKey+L.

And the admin:admin user was actually not for the router but for USB sharing which I have disabled.

And indeed I plan to spend the rest of the day updating all my passwords.


How does the symmetric key get exchanged in SSL/TLS handshake?

As you already noted, there are two ways to exchange symmetric session keys: through key encipherment or through key agreement (which is based on Diffie-Hellman algorithm). Both algorithms are not used at the same time. For example, Microsoft SChannel client reads bits from server certificate's KeyUsages extension (which is a bit string) and depending on what bit is set, the key exchange algorithm is used.

When key encipherment is used:

client and server exchange supported cipher suites and agree on a common cipher (which is supported by both parties).
client uses selected algorithm and parameters to generate symmetric key and encrypts it with server's public key (asymmetric encryption, RSA or ECC, for example).
server uses its private key to decrypt the key and this key is used to protect session. No DH is involved here.

In the case of Diffie-Hellman (key agreement), there is no much difference on who starts, because parties share common prime number p and generator number g and both parties MUST agree on these values. These numbers can be agreed on in public. So, the agreement initiator is just a protocol's message syntax matter.

After that the following process occurs (which is well-defined):

Clients sends its DH public key to server.
Server computes the secret session key by using the information contained in its private key and client's public key.
Server sends its DH public key to client.
Client computes the secret session key by using the information contained in its private key and server's public key.
Both parties now have the same session key, which can be used for encrypting and decrypting data. The steps necessary for this are shown in the following procedure.

Detailed DH key exchange algorithm is described in RFC2631.


Diffie Hellman Group Matching to IPSec Encryption Algorithm

Update 21 Oct 2017. I found some useful info in RFC 5114 under Section 4 "Security Considerations". Based on this recommendation, we can consider DH Groups 14 and 24 as too weak to protect AES 128 Symmetric Keys - this leaves DH Groups 19 through 21 ECP as the minimum acceptable Diffie Hellman groups for generating AES symmetric keys (128 bit and higher).

  When secret keys of an appropriate size are used, an approximation of
     the strength of each of the Diffie-Hellman groups is provided in the
     table below.  For each group, the table contains an RSA key size and
     symmetric key size that provide roughly equivalent levels of
     security.  This data is based on the recommendations in [NIST80057].

GROUP                                      |  SYMMETRIC |   RSA
-------------------------------------------+------------+-------
1024-bit MODP with 160-bit Prime Subgroup  |        80  |   1024
2048-bit MODP with 224-bit Prime Subgroup  |       112  |   2048
2048-bit MODP with 256-bit Prime Subgroup  |       112  |   2048
192-bit Random ECP Group                   |        80  |   1024
224-bit Random ECP Group                   |       112  |   2048
256-bit Random ECP Group                   |       128  |   3072
384-bit Random ECP Group                   |       192  |   7680
521-bit Random ECP Group                   |       256  |  15360

Group Numbers mapped to DH algorithm names from RFC 5114 "IKE" Section.

NAME                                                    | NUMBER
--------------------------------------------------------+---------
1024-bit MODP Group with 160-bit Prime Order Subgroup   |   22
2048-bit MODP Group with 224-bit Prime Order Subgroup   |   23
2048-bit MODP Group with 256-bit Prime Order Subgroup   |   24
192-bit Random ECP Group                                |   25
224-bit Random ECP Group                                |   26
256-bit Random ECP Group                                |   19
384-bit Random ECP Group                                |   20
521-bit Random ECP Group                                |   21

I was able to find some pairing suggestions in the strongSwan Security Recommendations document under the "Cipher Selection" heading.

"aes128-sha256-modp3072 (AES-CBC-128, SHA-256 as HMAC and DH key exchange with 3072 bit key length)" DH-Group-15 (not available on my device)
"aes128gcm16-prfsha256-ecp256 (AES-GCM-128 AEAD, SHA-256 as PRF and ECDH key exchange with 256 bit key length)" DH-Group-19
"aes256gcm16-prfsha384-ecp384 (AES-GCM-256 AEAD, SHA-384 as PRF and ECDH key exchange with 384 bit key length)" DH-Group-20

It seems that the pairing recommendations may be loosely based on algorithm strength analysis listed on the Belgian BlueKrypt keylength.com site.

This is the closest I could get to a diffie-hellman algorithm pairing recommendation. Please post if you find other reputable sources for selecting well-matched diffie-hellman groups for use with IPSec encryption.


How can i store encryption key into Microsoft provided Key container?

I think the link you provided above is one off--check here instead, which covers key import (what you need to start with). In short, you'll invoke BCryptImportKey or BCryptImportKeyPair, depending on if you're dealing with symmetric or asymmetric keys.

Once imported, use the various functions provided in CNG, probably starting with BCryptDecrypt and BCryptEncrypt.


How can I execute a XSS with these conditions?

Besides Gumbo's nice and simple answer, another possibility would be to use the last replace() call to bypass the earlier ones, for example like this:

<scr"ipt>alert('XSS')</scr"ipt>

In fact, I suspect this might be the solution that the author of the challenge was expecting: there's not much point in stripping double quotes except to deliberately allow this particular attack, and the "just to make sure" comment even calls attention to it.

Of course, even if the code didn't strip double quotes, you could still do this:

<scr</script>ipt>alert('XSS')</scr</script>ipt>


How do I know if root account has been compromised?

Your computer has been rooted if an unauthorized user (how defined? becomes difficult on systems with many accounts) has gained access to it. If JoeUser is an account with little access to anything of importance (how defined? by whom? how is importance level tracked?) nothing much might be lost, but any unauthorized (ie, hostile) access has the potential for further breaches, given the way ordinary humans behave -- see the movie War Games for an entertaining and not too fantastic account with drama, or the Cuckoo's Egg by Cliff Stoll for a much more realistic, though still dramatic account from reality. Things have not improved much since Stoll's little adventure (and the browser / web / server / live database Internet has made things vastly more dangerous), and official (govt., corp., org., ...) resources are still pretty clueless.

On the other hand, if JoeUser is the local superuser account, any breach is more or less disastrous, as everything on the machine(s) is in principle completely lost. All data, all configuration information, and probably all connectivity information (topology, all passwords (if users have been foolish), ...). An attacker will likely want to continue to have access to the machine(s) and so will try to so configure the system as to perform normally, save that when the attacker wants access for further depredations, it is still available to him.

The techniques used for such things are as varied as people's imagination and low cunning.  They are usually called rootkits. Since very few people are really good at this sort of thing, and since many attackers are scriptkiddie level folks, techniques are often reused. There are several rootkit scan programs (some good, some not so good, ...) which can find the traces left by some (perhaps many) of these schemes. But if the rootkit scanner you choose is not aware of whichever rootkitting technique was used on your machine, you won't hear about it. Or, even worse, what about the situation in which the rootkitting attack on your machine isn't traceable by a looking for traces on your disk or machine memory, or is really new and none of the rootkit scanning programs have any provision for finding evidence of it?

In actual reality, you won't generally have the time, nor sufficient expertise on your particular machine (OS), to find rootkit traces that no scanner can find. Thus as a practical matter, the reformat / reinstall from trusted media / reconfigure / acceptance test / pray option is likely the only one with any real credibility.

In your case, you may not have been rootkitted. Depending on the configuration of your server software, root access may not have been required to do the spam distribution you report. IF that is so, you may be able to merely reformat the server's partition (if hat's how you had it setup) / reinstall / .... Inappropriate configuration of the server and its resources (files, access to executables, and other accounts' files (eg, read only for SSL operations, special configuration files, exec PATH setup in the environment, ...) may have been the entry point.

Make sure your server is correctly locked down to prevent such access, not an easy task. Requires considerable time and expertise in following the boards, books, conferences, ... to be sure you're up with the current best practice -- which, of course, may have hidden vulnerabilities no one currently is aware of.

There are no easy answers.  is not available and will not be until Internet standards are rather less porous than they are currently.


Can I tell Linux not to swap out the data space of a specific process?

You can use mlock, which were also mentioned in the question you referenced. From the man page:

  mlock() and mlockall() respectively lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area.

But, this might not be enough because in case of a crash your program might leave a core dump which still includes these data. To get a much more detailed answer read Protecting sensitive data in memory.


Time Based Authentication Verification Token

I would suggest making t a reduced-precision timestamp instead, where you set the precision to be half of the wish precision. The reason for this, is to both avoid having to send more data than neccessary to the client, which increases security, but also, to be able to filter the data on the server side more effecively, to avoid attacks that rise out of unsafe/tainted input.

So for example, if you want the token to alive for 10 minutes, you make a timestamp that will change roughtly once every 5 minutes.

Using a standard unix timestamp, divide this with the half number of seconds you want the token to be alive for, and strip off the decimal.

So 1466182513, which is current time. Divide it with 300 (5 minutes) and int() it. You get: 4887275

which will be valid from:

Fri, 17 Jun 2016 16:55:00 GMT

to

Fri, 17 Jun 2016 16:59:59 GMT

This decimal value can be included in the hash. So the value 4887275 is effectively a "clock" that "ticks" each 5'th minute.

Now to the trick:
When you verify the hash, you "try" with both the reduced-precision value for the CURRENT time, but also the reduced-precision value immediately before this. This effectively means that the client will be able to do "sensitive actions" anywhere between 5 to 10 minutes from the time when they input the password.

Don't misunderstand this now. What I mean, is that the token will expire anywhere between 5 to 10 minutes from issuance, and this expiry will depend on when, in the timeframe, they input the password.

Eg, in the above example, you try to validate the hash both with the value 4887275, which is from current time, and value 4887274, which is the value for about 1-5 minutes ago.

Of course, you can divide with other values to get other precision, for example 600 to gain a validity between 10 to 20 minutes.

The reason you should try also the timestamp immediately before, is that, lets say a person enter his password at Fri, 17 Jun 2016 16:54:59. Now he has 1 second to carry out his sensitive action, unless we also try the value immediately before.
Thats is why you should select a value half of the wish precision.

This means you don't need to send the timestamp to the client. You just send the hash, as you can easily reconstruct ALL of data in the hash.

A good idea is also to include the session ID in the hash, so the token is effectively invalidated as soon as the user logs out or the session is destroyed for some other reason. Also the password hash is a good idea to include, so if the user changes his password, any tokens become invalid.


Encryption & protecting data from myself (and hackers)!

The solutions you suggest can all be broken, given that they only move the trust somewhere else. You need a cryptographic solution that ensures the following:

Your server is able to accept and transmit encrypted material to the correct users.
The user has access to the encryption key.
The server has no access to the encryption key.

This requires in-browser JavaScript crypto, or a separate client-side program. Obviously, there is the possibility for a malicious admin to replace the JavaScript with a version that sends the key or original plaintext to the server, but this will always be a risk.

Depending on the type of data being stored, there is already a rather simple solution which is used by many paste websites like Zerobin and 0bin, as well as the popular Mega file host: client-side encryption. JavaScript in the browser creates a symmetric encryption key and appends it as the fragment (anything past the octothorpe) of the URL. The fragment is only visible to the browser, not the server. JavaScript in the browser encrypts data using this fragment and uploads the data to the server. The result is that you need the full URL in order to view the page, and the server is unable to decrypt.

A URL may thus be represented as example.com/path#fragment. Your ISP sees example.com, as this is what you send to the DNS server. Even with TLS being used, the domain is still sent in the clear as a result of SNI. /path is only visible to the server you are sending it to, assuming you are using TLS. This is what the server uses to determine what to send back to the client. The last part, #fragment, is only visible to your browser.

Take this example URL from Zerobin:

zerobin.net/?5cd884d7e1409f31#25LMCTnmrN3H/BPcebRjH6Gl05Sklj91CssV45YwQ/o=
|   host  |    identifier    |            base64 encoded key              |

In this example, the domain is, obviously, the address of the server. The identifier is the path which specifies what encrypted paste is being requested. When the page is retrieved, the fragment is never sent to the server. When fetching a file, all the server sees is this (in this example, using cURL rather than a web browser):

GET /?5cd884d7e1409f31 HTTP/1.1
Host: zerobin.net
User-Agent: curl/7.56.1
Accept: */*

This tells the server to retrieve the encrypted post and serve it, along with the JavaScript required to decrypt it. If the key is not correct, or the key is not present, the code on the page will be unable to decrypt it. This is intended to ensure that the plaintext is only visible to someone who has the URL. It is up to them to decide whether or not the URL should be distributed widely or kept relatively secret. This technique could be easily modified to use a password rather than a URL fragment, but if the issue is simply reducing PI, this should be plenty.

More information about this specific information is on the Zerobin project page.

With sufficient engineering, this can be made to store far more than just text pastes. Mega for example supports accessing storage like a filesystem. There is even a utility which mounts your online user directory as a filesystem using FUSE, allowing interaction using generic filesystem actions, all the while ensuring the server does not know what is being accessed. Your application could be made to do this if this fits your requirements.


How to validate the integrity of a back end?

While the differences between authenticity and integrity are difficult in practice, as your example of a compromised key set illustrates, as far as I understand it, this aims at the network level rather than the logic level. Thus, checking the integrity comes down to trusting the authenticity of the certificate and accepting only such cipher suites that provide ways to detect (possibly blind) modifications by a man in the middle.
Another way to satisfy this would be to allow for any ciphers that guarantee confidentiality and evaluate the integrity of the payload in the application logic, for example by restricting the payload to a fixed data format that itself provides integrity, for example JSON Web Signature.
As to your example of the server being compromised and thus the authenticity claim of the certificate holding but an attacker changing the data: that's not exactly true. While it might not look that way for a client, the authenticity goal as already been breached then: the answering party is no longer who they claim to be but rather the attacker.
Additionally: As the TR is currently in a Trial Use Status, for questions regarding compliance with the TR, the contact data of the document can be used.


Sounds like you were looking at the loopback (lo) interface. Without the output from your ifconfig command, it's impossible for us to tell.

One thing you may want to do before running airmon-ng start is

airmon-ng check kill

This terminates any network programs that might interfere with airmon-ng/airodump-ng. You are right though, nothing should be transmitted.


Is it useful to determine the name of the server software while doing a penetration test?

Like when doing car maintenance, when you know which constructor, you will take the right maintenance manual (Don't try to repair a Ford Granada with the manual of a Honda civic).

When trying to break a particular system, you will browse for known exploit that could help you for this particular system.

Every net servers (From Sendmail to Apache, with Samba, wuFTPd and all others) have a bunch of published exploits which let an attacker to execute arbitrary code by using previously discovered security failure. All critical failure are quickly patched and newer version are published...

If a server use Zebulorglub V2.0.1, don't try exploit concerning Zebulorglub V2.0.0 or older, but could try exploit working on V2.0.1 or higher...

(Nota: Zebulorglub is a dummy name;)


How is the TLS protected against length field of the header being modified?

An attacker who can modify TLS record headers can actually block packets altogether, thus making the receiver wait "indefinitely". There's nothing that the TLS protocol can do to prevent that.

TLS implementations can use time-out strategies, i.e. if no activity has been received from the peer for some time (e.g. 15 seconds) then the connection can be dropped automatically. This is needed anyway to handle the case of clients crashing: when a machine crashes, it ceases to send packets, but it won't tell that it can no longer send packet, since it is crashed.

It is a generic property of TLS. TLS does not try to recover from a transport failure; it just tries to reliably detect alterations. Attackers can always cut the wire or postpone traffic for arbitrary amount of times. For that matter, the TLS records are considered "transport" just like the underlying TCP connection. The MAC used in records is where detection occurs, and it covers the record payloads only.


How can I protect myself from false accusations when our company practices password escrow?

That's what the envelope is (or should be) for: In order to use your password, one needs to break the seal of the envelope you signed. When you think your password was abused, you can ask to see the envelope with your signature and check if it is still unopened.

All you need to do is that should your management ever require your password, change the password and hand in a new envelope. You might want to change your password in regular intervals anyway: It's common best practice.

By the way: In companies with a proper IT management this method is unnecessary, because system administrators can receive any necessary information from user accounts without having to know the passwords of the user. If an administrator really needs to log into a user account, they would reset the password (which would create a verifiable audit trail). And there is usually more than one system administrator, so the admin accounts do not require this method either.


Are the developers of WordPress avoiding security by obscurity or there some reason to expose plugin and login names?

Information Disclosure is a kind of vulnerability that different people have different views on. Usually, it boils down to two competing philosophies:

It's a vulnerability, because it gives an attacker an unnecessary advantage, however small, that they would not have, would I not have disclosed this information.
It's not a vulnerability, because knowledge of the installed plugins and version in itself is not a problem, as long as these plugins themselves are not vulnerable.

Both of these views are valid, but when first confronted with them, most people tend to be on the "better safe than sorry"-side, and want to prevent information disclosure at all cost. However, sometimes it may be beneficial to disclose information, such as when scanning for vulnerabilities. This may seem paradoxical at first, but if you run a WordPress instance with a number of different plugins, having an easy way to access the version for every plugin and checking that against a list of known vulnerable plugins can be helpful.

Could all of these have been concealed?

Yes, absolutely. WordPress could have been designed in a radically different way, which would have made plugin detection a lot harder. But then again, WordPress was made by developers who primarily focussed on making a system that is easy to work with and easily extensible. Avoiding information disclosure at all cost was likely not very high up on their priority list. If it was developed by developers with very little exposure to security topics - which is absolutely nothing abnormal back in 2003 - then they might just not have thought about it.

So why not change it now? Because changing the architecture of a system that is as widely deployed as WordPress is a very, very monumental task, and such a task requires a damn good reason to undertake. Preventing people from knowing you use ACME Corp's Best Plugin Ever in version 13.3.7 is really not such a big vulnerability - even for people who consider it one.

To Summarize

  Did the WordPress developers expose all this data on purpose?

Probably not, but I don't speak for them.

  Can this still be "fixed"?

Yes, in theory. But in practice, the impact is so low and it would break so much, that nobody bothers.


SSL does not prevent DNS spoofing itself but it prevents that it can be successfully used.

If the certificate of the site does not match the name given the URL the certificate validation will fail. It does not matter how an attacker redirected the client to the other server, that is no matter if DNS spoofing, changes of the routing or ARP cache poising were used the certificate validation will fail because the server is unable to present the expected certificate.

To mount a successful attack against SSL you must be able to use a certificate acceptable by the victim, i.e. matching the hostname from the URL and also be signed by a trusted CA (and even more restrictions if certificate/pubkey pinning is involved).


Generally speaking: yes, it should. The "salt" in ???-CTR steram ciphers is actually the IV/NONCE used to generate the XOR-stream. As indicated by the name (NONCE = Number used once), it should be unique and have a reasonable amount of entropy.

In a stream-cipher there are no messages. That means that the NONCE is theoretically unique per session / connection. But if that connection stays alive for a longer period of time (say several hours) and/or larger amounts of data are transferred with the same NONCE (e.g. 100MBs and more) the stream cipher may become suspectible to cryptoanalysis (depending on keysize, entropy of the NONCE and the Cipher algorithm in use).
Most SSL-like protocols (including the TLS standard) suggest to regenerate the NONCE every X minutes or every Y bytes transferred.

Here is an example that i would consider secure enought for sensitive data:

AES-192 or AES-256 CTR
NONCE genreated using a CSPRNG (see FIPS-140) with high-entropy seed (e.g. /dev/random)
Same goes for the Key-Exchange random numbers
Every 2 hours or every 200MB exchange a new key and a new NONCE.

Practically, you will have to choose these parameters yourself if you are not relying on a standard TLS connection.

openssl rand_bytes() does suffice for generating NONCEs.


What is the difference between a Gateway and a Firewall?

A gateway is simply a device that joins together two different networks. In the most common scenario, an internal network with the internet. A router is an example of a gateway device. A router is a device that does routing, deciding where packets are sent to based on its IP address.

A firewall is a filter that examines packets against a set of defined rules in order to decide whether to allow the packets through.

In many devices, the functionality of both a gateway and a firewall is present. Of course, there are dedicated versions of each for use in large enterprise networks.


If you look at the GCM specification, you will see on page 15 that when the IV has length exactly 96 bits, then the counter for the AES-CTR encryption is initialized at J0 = IV || 031 || 1, i.e. the 128-bit counter is built by appending 31 bits of value 0, then one bit of value 1. The successive increments when doing the CTR encryption will alter bits in these low 32 bits. Thus, there is no overlap as long as no ethernet frame is bigger than four billion blocks, i.e. 64 gigabytes... and an ethernet frame is indeed much shorter than that.

Alternative description: if a frame uses IV x, then the counter value for that frame begins at value 232x+1 and will go up to 232x+94 (for a 1500-byte ethernet frame, a bit less than 94 blocks). Next frame will use IV x+1, for a counter which starts at 232(x+1)+1 = 232x+232+1, incurring no overlap.

Note: this means that it would be quite unsafe to encrypt more than 64 gigabytes as a single run with GCM. This is stated explicitly in the specification, page 8: plaintext length shall not exceed 239-256 bits. This is more than enough because, by definition, an authenticated encryption mode is meant to provide some integrity guarantees; thus, it makes sense when the data could be altered by the attacker; correspondingly, the receiver of data shall not use it until it has verified the MAC, which entails buffering the whole "packet". Who wants to buffer 64 gigabytes of data before being able to begin its processing ? When GCM is used in TLS, the buffer size will not exceed 17 kilobytes; and, in your case, the maximum size will be that of an ethernet frame, which maxes out at 9000 bytes even with jumbo frames.


I'm not clear on what you're having trouble understanding. A cipher is function that takes a key and plaintext, and outputs a ciphertext. The key space is the set of everything that can be used as an input as the key. Generally, what's important is not precisely what is in the key space, but how many distinct  elements there are (depending on how the space is defined, you may have multiple keys that result in the same output, so by "distinct", I mean keys that don't always give the same output). This is because one method of breaking encryption is to simply try every key (this is known as "brute force"). The more keys there are, the longer this method takes.

A 56 bits key space has 256 different keys. Suppose you can try one billion keys per second. A billion is about 230, so that means that it will take 226 seconds, or about two years, to try all the possibilities.


Hacking/Sniffing/recording GSM like Karsten Nohl

A great link/thread, with nice informations to start. USRP's are indeed quite expensive and RTL-SDR could be really cheap, but not always reliable.I use the HackRF-One(30MHz–6GHz, half-duplex though), and it costs 344€.


How to do arp spoofing on the virtual machine? (Against host)

Maybe that is because your Kali machine in on "host-only" mode.

Have you configured the guest machine to be on "bridge " mode ?
This way, both your machines will be on the same network.
And the attack should work.
However,be aware that preforming the attack on virtual machine may effect the attack(specially when you preform ARP spoofing and DNS hijacking  with ettercap)


Rails File.open(#{Rails.root}) is vulnerable to LFI?

Rails.root appears to return the root directory of the Rails app. As this is not user controlled input, it is not/cannot be used for LFI of any sort.


How bad an idea is intentionally using short RSA keys for signing CloudFront private-content URLs?

Right now (July 2015), the current record for RSA key breaking is for a 768-bit modulus, and it took two years of computations with a lot of machines, and, importantly, with some very fine brains too. A notable point is that the best known RSA-breaking method (that was used for RSA-768) is integer factorization with the General Number Field Sieve; GNFS does not benefit from any kind of "precomputation". This means that the people who factored the 768-bit RSA key, if faced with another 768-bit RSA key to break, would again have to spend two years on the job.

As for 1024-bit RSA keys:

they are currently unbroken;
they could be broken with existing technology, but it would require throwing at the problem a non-negligible number of millions of dollars to build a dedicated machine that would be good only at breaking 1024-bit RSA;
... and even that machine, if it is ever built, would still need a lot of time (months, possibly years) to break a RSA key.

In your case, if signatures only need to resist for a few minutes, then you could generate a new RSA key every day, and this will defeat GNFS-based attackers as long as breaking a 1024-bit RSA key takes more than a day, a property which is quite likely to hold for the next few decades. A good point (for you) is that since your signatures become obsolete quickly, you "just" have to keep track of scientific and technological advances: the day some people succeed at breaking a 1024-bit RSA key, you can switch to 2048-bit keys; you do not have to do it in advance.


Why are there leading 0x00 bytes in the subjectPublicKey field of a DER X.509 cert?

ASN.1 BIT STRING can be any length, so the DER/BER encoding rounds up to a multiple of 8 (an integral number of octets) and prefixes one octet containing the count of added padding bits. Since this BIT STRING value is itself a DER encoding and thus already a multiple of 8 bits, the padding count is 00.

ASN.1 INTEGER is signed, and the DER/BER encoding is two's complement big-endian. Your N value 9BFC...5307 has a magnitude that is an exact multiple of 8 bits; this is common since most RSA moduli are deliberately chosen to make their size in bits a power of 2 higher than 23, or a small multiple thereof, in your case 512. For this to be represented as a signed number a 0-bit must be prefixed, and since the encoding must be integral octets in fact we prefix a full 00 octet.

Back in the 1990s when RSADSI established a series of Public Key Cryptographic Standards (PKCS) using a good deal of ASN.1, Burt Kaliski wrote a "Layman's Guide" that covered a lot of useful details about ASN.1 quickly; see especially 5.4 and 5.7 in this apparently definitive reference or this more convenient but uncertainly permanent one.


How to store derby database encryption key in HSM?

What some database engines do is to derive keys in the HSM and use different keys for different parts of the data. On top of that, they can also cycle keys (e.g. read/decrypt with key A, encrypt/write same block with key B). These operations are embedded in the database engine and I'm not sure Derby goes any close to that degree of sophistication.

On top of this, the benefit of database encryption is that if someone steals a harddrive (or a back up of your DB), they won't be able to access the data.

This changes completely in the case an attacker gets access to the server, as they will be able to connect to the database and extract the data, or alternatively they'll be able to scrap the key from memory.

My suggestion would be (similar to your first point): Use the HSM to derive a key (just getting the key our of an HSM feels dirty to me), and know that this is only to prevent the scenarios I mentioned above.


What countries have strong data protection laws?

I have found a website which list a overview of the key privacy and data protection laws and regulations across 77 different jurisdictions. Of course i haven't read the legislation of any of these countries and i'm not a lawyer so you should pick one of this countries and do a deep search to see if their laws suit your needs.

And laws can change at any time this should not be the end of your search but rather the start for a more deep and current search on the law.


VirusTotal detects threats in Python Anaconda Build 3.6 - is it Reliable?

Only 3 of 62 antivirus products detect this binary as malicious. And the MD5 and SHA-256 of the binary match the  officially published hashes. This suggests that these antivirus reports are false positives.


Storing passwords and other data for coworkers

Your current arrangement sounds like a shared password keystore.

Your problem is essentially the difference between centralised and decentralised access control:

When access control is per server or service, the maintenance of the access control is centralised per service and reflects an effort of O(N) where N = amount of services for the company.
When access control is per person, the maintenance of the access control is decentralised from the standpoint of ICT assets and reflects an effort of O(N) where N = amount of staff for the company.

It is likely that the amount of services you initially had grew faster than the amount of staff and hence the second option was more appealing.

But now the amount of staff or turnover of the staff is higher than the amount of services and is costing you more to maintain than server/service-based access control lists would. The tipping point being O(N).services + O(1).service versus O(N).people + O(1).people as the initial O(1) overhead of each new service or person would have masked the long term shift in effort.

So it becomes a question of security vs your company's shared work culture. You can shift across to the now possibly cheaper server and service access control approach, and you will gain additional auditing benefits in the process; but the shift will require a lot of migration effort and a hierarchical "unflattening" of your company's work culture.

If we go back to the days of physical keys and filing cabinets, the difference is between the team all sharing the same cabinet key versus just a couple of people having the cabinet key.

I don't think you have much of a choice regarding a shift towards to server/service ACLs once you have more staff or role volatility than servers - but you can reduce the ACL overhead through systematic use of client certificates:

Convert their RSA key pairs into self-signed client certificates.
Add or remove their public certificate from servers and services directly or from a centralised role-based LDAPS authentication service.
(Optional) Convert key pairs into certificates signed by the company private Root CA to enforce routine expiration and stop people from generating access credentials you are unaware of (i.e. breaking the audit chain).

Client certificates have the benefit of being more secure than passwords and having a wide range of embedded meta-data without needing real-time access to the LDAP server.


Password storage which avoids privileged insider attack

A common misconception about salts is that they are a secret. If implemented correctly, it's not very important for the salt to be secret. The point of a salt is to defeat precomputation attacks like rainbow tables, and to make the required time and computational cost of cracking a password as high as possible.

This is an effective mitigation against a malicious privileged insider. If you can make the average time required to break a single password longer than the age of the universe, that will be enough to prevent your insider from cracking a password unless they are astronomically (literally) lucky.

So if your aim is to prevent a malicious privileged insider from accessing any users password, storing a strong salt with the password hash, along with choosing a strong hash, is enough.


I think it is best to install Burp suite certificate into the Android test phone.

If your test phone is Nougat and above, you can refer to the link below.
https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/

If not, you can just refer to this Burp help page.
https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device

Hope this helps.


Specific character based policy for passwords

The fundamental issue is that entropy can only be estimated from the password itself, and that estimate can be very very wrong.  The entropy is determined by the password generation method.  You can't measure the entropy of the method from a single password.

Let's look at a practical example.  I find it easiest to memorize very long passwords generated from a small password space, so I'm going to use numbers only and make it very long.  Your algorithm looks at my password, sees that it only contains numbers (aka character set size is 10) and that it is 20 characters long.  This gives it an entropy of:

log2(10^20) = 66.4

It passes your test!  However let's stop and look at the password:

01234567890123456789

Hmmm... turns out that the actual entropy is pretty much zero.

I could get a lot more technical but in this case I think it's better to keep the answer simple.  I believe this example should provide a sufficient answer to your question.


I recommend you to check your browser extensions, you may have download an malicious extension. Another thing I would do is check your Start-Up folder in your OS. This is all I can think about. Next time don't download or install any 3d software/extension that looks suspicious, same for ads.
The Start-Up folder in Windows located in:
C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup


There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ʼ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such a string is used to build an SQL statement dynamically.

However, your validation is pretty strict (only characters from the Basic Latin Unicode block and Unicode whitespace characters) and I can’t think of any case where this would fail.


Would a predefined shared secret key be good here

With respect to your goals you need:

Data confidentiality->Encryption. The question is public one or secret one. I guess you need a secret one in which only the owner of the key can encrypt and decrypt. You don't want anyone to encrypt firmware.
That implies an integrity mechanism. If you use a secret key scheme then you want either an authenticated block cipher or a secure combination of MAC (message authentication code) and encryption. Encrypt-then-Mac approach tends to be the more secure for various reasons.

For your questions:

Secret key sharing is secure as long as the involved parties are trusted and as @Ricky mentioned if you can't define different key per device.
You deploy the secret key at your hardware devices and the server and then you use that with AES for encryption. For authentication unless you use an appropriate cipher that combines both you MUST use different keys for the MAC authentication.


Can attribute certificates be used with TLS / HTTPS?

RFC 5878 is experimental, and therefore not required to be compliance with TLS proper. As far as I can tell, based on cursory searches, OpenSSL has headers related to 5878 (e.g. TLSEXT_TYPE_client_authz, TLSEXT_TYPE_server_authz), but does not appear to be used in either Chrome or Firefox's source code. It's non-trivial to tell if other browsers support it (e.g. Opera, Safari, Internet Explorer) without actually testing it, which I do not have the time to do at the moment. Both Chrome and Firefox could easily support it through their related extension APIs, or could even easily be patched to support the extension if you wanted to use that internally for an organization. Finally, I suspect that if there was support for it, a cursory Google search would confirm it, but the lack of any documentation speaks volumes.


What is the recommended expiration for a password reset link?

It depends on how you’re communicating with the client. NIST recommends the following during the enrollment process when it’s considered a part of the authentication process; which I would consider equivalent to the password reset process. Also note these are maximum values, you may certainly use shorter intervals than these.

4.4.1.6 Address Confirmation

[ ... ]

e. Enrollment codes SHALL have the following maximum validities:

i. 10 days, when sent to a postal address of record within the contiguous
United States;

ii. 30 days, when sent to a postal address of record outside the contiguous
United States;

iii. 10 minutes, when sent to a telephone of record (SMS or voice);

iv. 24 hours, when sent to an email address of record.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf


What did the certificate authority do with my CSR?

A CSR is a file that contains your public key and the data that describes your server -- such as its hostname ("common name"),etc. A certificate authority (CA) is an intermediary that you and the parties you connect to mutually trust. A CA will review the CSR you submit and then issue a certificate, which is usually the same data as in the CSR plus CA's own digital signature. When you offer this certificate to servers you connect to, they check to make sure that the CA signature is valid and belongs to a CA they trust. This simplifies the procedure of assuring trust between parties by placing it into a "mutually trusted authority."

I suggest you search for terms like "what is a certificate signing request" and read some introductory articles on x509 public key infrastructure.


What does a MCSE need to learn to be proficient regarding *nix security?

He could cherry pick from the various security benchmark/checklists offered by:

  http://cisecurity.org/
  The Center for Internet Security (CIS) is a non-profit enterprise whose Benchmarking and Metrics Division helps organizations reduce the risk of business and e-commerce disruptions resulting from inadequate technical security controls. The Division provides enterprises with consensus best practice standards for security configurations, as well as resources for measuring information security status and for making rational decisions about security investments.

  http://iase.disa.mil/stigs/checklist/
  Defense Information Systems Agency (DISA)

  http://web.nvd.nist.gov/view/ncp/repository
  http://csrc.nist.gov/fdcc/faq-common_security_configurations.html
  The National Checklist Program (NCP), defined by the NIST SP 800-70 Rev. 1, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications.

Next, spin up a couple Unix based systems on Amazon EC2 or Linode (lots of distributions to choose from).

Then setup & install OSSEC and gain experience reading and understanding the alerts generated by OSSEC (host intrusion detection system).

Bonus:  Install and/or fire up a few services & applications (ssh/ftp/mail/dns/pop/http/etc.) and expose them to the public Internet.  The more the merrier (i.e. more logs will be generated and more OSSEC alerts will be triggered).


Security implications of using Bash script as a SSH login shell

This looks okay to me for now.

As you are passing arguments to the script, remember that you need to not pass the arguments directly into the executed statements, at least not if you not desire the monitoring machine/user to have an actual shell on the system.


Understanding 2048 bit SSL and 256 bit encryption

The 2048-bit is about the RSA key pair: RSA keys are mathematical objects which include a big integer, and a "2048-bit key" is a key such that the big integer is larger than 22047 but smaller than 22048.

The 256-bit is about SSL. In SSL, the server key is used only to transmit a random 256-bit key (that one does not have mathematical structure, it is just a bunch of bits); roughly speaking, the client generates a random 256-bit key, encrypts it with the server's RSA public key (the one which is in the server's certificate and is a "2048-bit key"), and sends the result to the server. The server uses its private RSA key to reverse the operation, and thus obtain the 256-bit key chosen by the client. Afterwards, client and server use the 256-bit to do symmetric encryption and integrity checks, and RSA is not used any further for that connection.

See this answer for some more details. This setup is often called "hybrid encryption". This is done because RSA is not appropriate for bulk encryption, but symmetric encryption cannot do the initial public/private business which is needed to get things started.

(SSL can do the key exchange with other algorithms than RSA so I have simplified description a bit in the text above, but that's the gist of the idea.)


No. It'd be trivial for them to just take each part and bruteforce it, even for strong passwords. You're falling into the same problem as NTLM did in the early days, where a long password ends up being two really short passwords which are easy to bruteforce independently.

Instead of having to crack one 10 character password (assuming a-z 0-9 that's a keyspace of 3.656×1013) they only have to crack two 5 character passwords (keyspace of 120,932,352 for the same password) making the problem several orders of magnitude easier for them.

If you're looking to hash passwords, use a strong key derivation algorithm such as bcrypt or PBKDF2.

I recommend having a read through these two questions over at IT Security:

Do any security experts recommend bcrypt for password storage?
How to store salt? (contains a detailed explanation of why key derivation and salting is necessary)


Has there ever been a known case of Bitlocker breach through lock screen?

A good introduction to the subject is Ivor Kollár (2010): Forensic RAM dump image analyser, and this answer is mainly based on his work. The chapter 2.1.1 describes OS independent methods that do apply to this case of a locked Windows computer:

Contrary to what you have understood, Direct Memory Access DMA attacks don't require powering off the computer. If you can dump the memory from the PCI BUS (or IEEE 1394, as the device is technically on the PCI BUS), it's possible to capture the keys even for the mounted VeraCrypt volumes. Cons: The computer may crash during the attempt.
Both cold boot and hot boot attacks are similar physical attacks where the goal is to dump as much of the memory as possible. Although the computer is restarted, the attack is based on the hope that the memory doesn't necessarily get emptied. Cons: These might not be practical in real forensic cases, and you also need some luck for these to be successful.

Extracting the cryptographic keys from the memory dump might not be easy and straighforward, but once you have got the contents of the memory using these methods you have unlimited time to investigate them without any fear of losing the keys, if they were there.


Bogus HostName Causing Suspicion of Man In The Middle

It is possible that is what is happening. Assuming this isn't a super sophisticated attack, let's take a basic overview of what to do:

First, check your Domain Name Server (DNS) to get a mapping of current IPs to Media Access Control (MAC) addresses.

Next, you need to log-in to your network switch(es).
Within your switch, you will be able to view the Content Addressable Memory (CAM) tables.
These tables map each MAC address to the physical port that they are plugged into on the switch.

Once you have the physical port, you can go to that location and look for a bad actor.
Additionally, unless the MITM is spoofing their MAC, you may also be tipped off as to what kind of device to look for by looking up their vendor code: Mac Vendor Lookup

This process can be further complicated by unsecure wireless access points.


Could ProtonMail find out a user's real location from inside Tor?

As mentionned by @schroeder, this is purely about Javascript, not about any specific app that involves Javascript.

One practical example of how Javascript can be used to de-cloak a tor user is by using WebRTC (see https://thehackernews.com/2015/02/webrtc-leaks-vpn-ip-address.html). Javascript is at issue because it is used to build the WebRTC connection (see https://hpbn.co/webrtc/ for a great overview of WebRTC).

Another is the use of GeoLocation APIs built into browsers, which again, are intended to be queried via Javascript (see for example https://www.w3schools.com/html/html5_geolocation.asp). That API would typically fallback to using IP based location as a last resort, but often prefers other sources (such as visible access points, GPS, etc).

There are other examples involving Flash, possibly Java, and no doubt a whole laundry list of other things.

You can (generally) profile javascript (via your browser's developper/debug mode - which you can typically access by hitting F12), and most browsers will also provide you a way of inspecting what connections are made by your browser when processing a page.

Generally, prevention is far preferrable to detection, so doing things like disallowing/restricting Javascript, disabling WebRTC globally, not, ever, under any circumstances allowing flash or java in your browser , are probably your best bet.


Non-validating DNSSEC aware client security implications

Yes, and yes.

DNSSEC is the first successful attempt to add a security standard to the light-weight DNS infrastructure protocol.  DNS must remain light-weight in order for the Internet infrastructure to operate efficiently and quickly serve requests to users.  DNSSEC is backwards compatible and remains light-weight enough that DNS is efficient.

DNSSEC can be performed by the DNS servers without the knowledge or participation of client computers.  The term DNSSEC aware is a bit redundant since DNSSEC is backwards compatible.  A DNS server that does the DNSSEC validation will deliver trusted responses to DNS queries.  Specifically, the DNSSEC standard means that at the time the response is sent by the DNS server, the DNS server must have cryptographic evidence that the response is correct and trusted, otherwise the DNS server sends nothing.

The main issue at hand is that DNSSEC is not fully implemented on the DNS servers.  Some servers implement it, some do not.  If a client is configured to require that the DNS servers do DNSSEC validation, then the AD flag you mention is redundant, particularily since a DNSSEC server should not sent untrusted information to clients.  Windows computers can be configured to rely only on authenticated DNS responses, and this is what Microsoft means when they discuss 'non-validating DNSSEC-aware computers'.  See their discussion, for details.

As you observe, since the DNS server is doing the authentication, and the client is not, it is possible for attacks to be inserted between the server and client.  Such attacks could include poisoning of the client's local DNS cache and spoofing of server responses.  From a security stand-point, one would want the client to validate the DNS response.  However, there are probably implementation and efficiency obstacles for creating such a system.


Remote Private Key for Certificate Authority

Many cryptographic APIs support network-attached Hardware Security Modules (HSMs), and using those APIs would already seem to qualify for your theoretical construct.

.NET Core has a CertificateRequest class. If you make a custom class which extends RSA to communicate with KeyVault (or use an existing one) then you can create certificates where the signing key lives in KeyVault.

X509SignatureGenerator generator =
    X509SignatureGenerator.CreateForRSA(keyVaultRsa, RSASignaturePadding.Pkcs1);

X509Certificate2 cert =
    request.Create(issuerCert.SubjectName, generator, notBefore, notAfter, serialNumber);

It can write CSRs, but not read them.  So that's only a partial answer, unless you don't actually have need for CSRs in your scenario.